i have an updater program, the pulled files from server has mixed vb6 dll and .net dll in one directory. how to determine if a dll is a COM one? (so i can invoke regsvr32 to it from the updater program)
+2
A:
I guess one way to do it would be to try load the file with System.Reflection.Assembly.LoadFile(). If you get a BadImageFormatException, it's not a valid .NET assembly. There's probably a neater way of doing this, but this should work.
Daniel15
2010-06-10 03:13:16
This seems like a lot of work to write an installer that does this rather than carefully tracking which DLLs need to be registered. But +1 anyway
Tim
2010-06-10 03:46:08
+3
A:
Why not just call regsvr on all of them. If they register then ok, if not no big deal.
It is probably best though to write an installer that has the knowledge of which ones are which and does the right thing for each.
EDIT
If you are worried about "emitting errors", don't fret.
You can suppress messages. (/s)
Tim
2010-06-10 03:20:37
[@Hao](http://stackoverflow.com/users/55327/hao) - despite my alternative answer, I agree with Tim.
AJ
2010-06-10 03:23:13
@AJ: the problem with blindly regsvring them, if the DLL is of .NET type, the regsvr32 emits an error
Hao
2010-06-10 03:34:46
i already use /S. it suppress error messages on XP, but on Vista it shows the error
Hao
2010-06-10 04:31:41
@Hao - check to make sure you are running the command as an administrator. If the UAC permissions are not correct the /s flag will not work because the OS will never let you get that far.
AJ
2010-06-10 14:16:00
+4
A:
To do this formally you could inspect the PE to find out more about what type of stuff each dll is exporting. There is a pretty interesting article on MSDN which talks about the structure. If you understand the setup, you can identify links to .Net (and thereby the lack indicating a pure COM dll).
AJ
2010-06-10 03:22:17
I ran out of votes today. I will come back and vote this one up. It is a good technical answer.
Tim
2010-06-10 03:45:00
@ [Tim](http://stackoverflow.com/users/26177/tim) - thanks :) This is not for the faint of heart, but with a bit of effort it could provide a pretty solid solution. If the scenario is anything higher level than assembly this approach should be reliable (read: not too many "optimized" PE's to deal with).
AJ
2010-06-10 03:49:26