Thursday, May 29, 2003 10:55 AM Shawn A. Van Ness

In defense of regasm /codebase

It seems to me that regasm /codebase gets a bad rap. I guess that's to be expected -- it's a pretty self-deprecating little command line switch. This is what it has to say for itself, when run against an unsigned assembly: 

RegAsm warning: Registering an unsigned assembly with /codebase can cause 
your assembly to interfere with other applications that may be installed on the 
same computer. The /codebase switch is intended to be used only with signed 
assemblies. Please give your assembly a strong name and re-register it.

Adam Nathan also has some harsh things to say about regasm /codebase in his excellent COM Interop book... and lately some colleages of mine, both here and abroad, have been on my case about this, for some reason. (The guys who make our setups say that InstallShield just totally refuses to register an unsigned assembly for COM Interop.)

Maybe I just don't see what the problem is... I did the COM development thing for the better part of a decade, and none of my DLLs were ever signed with a strongname. In COM, we had GUIDs for strongnames. Well with COM Interop, we still have GUIDs! COM Interop is still COM.

Fundamentally, regasm /codebase is no different than regsvr32: they both register a path to a DLL under HKCR/CLSID/{some big number}/InprocServer32. The fact that regasm squeezes a virtual class factory in there -- forwarding to Assembly.LoadFrom from mscoree.dll!DllGetClassObject -- is an implementation detail.

The only good argument I can think of against regasm /codebase (one which I haven't seen mentioned anywhere) is perf. The codebase value in the registry is apparently the very last place the CLR looks, when loading a type for COM Interop (after the GAC, and after probing the apppath, etc -- note that these semantics differ from that of the <codebase> element in an app config file, which override probing).

But hey, no strongname means no signature to verify, thus saving a few cycles on that side of the equation. ;-) And CoCreateInstance is already such a big bloody monster, I doubt that the perf difference between GAC and codebase would be noticable to an end-user -- one certainly wouldn't want to call CoCreateInstance in a very tight loop, even in the best of circumstances!

So, what's the deal, folks?  Let regasm /codebase live!

 

Comments

# re: In defense of regasm /codebase

Tuesday, June 03, 2003 2:49 AM by Shawn A. Van Ness

Once again, the venerable Dr. Richard Grimes puts me in my place, with his latest .NET newsletter for Windows Developer Network... ah, if I only had a nickel.

Looks like the latest newsletter is not quite online yet. Stay tuned... although, quite frankly, he doesn't quite debunk regasm /codebase without also debunking non-sxs com interop, as well.

Summary: put your com interop assemblies in the gac. It's the best of all worlds: performance, security, and fusion-friendliness.

-S

# re: In defense of regasm /codebase

Tuesday, June 03, 2003 4:58 PM by Chris Sells

Amen, Shawn. I'm a big fan of regasm /codebase myself.

# re: In defense of regasm /codebase

Thursday, June 05, 2003 2:57 AM by Shawn A. Van Ness

Here's the aforementioned link to Dr. Grimes newsletter, which touches on regasm /codebase:

http://www.windevnet.com/documents/s=7446/win1054573103723/
(cookie required, I think... but probably worth the hassle)

# re: In defense of regasm /codebase

Monday, March 08, 2004 12:26 PM by Ricky white

Using Regasm for registering .net components seems to be more of a headache then COM was. Before you just had to be meticulous and organised when buliding components but now there's so many other things you need to do ie generate a type lib , create a strong name and there are so many options.

I'm beginning to see little benefit in .Net the more I do it and i'm starting to feel COM was'nt that bad after all