Problems with registering
I received a few comments and a couple of emails regarding how to properly register the ActiveX Menustrip/Toolstrip. The problem is that even after registering the control with RegAsm, the developer gets either an error about the control not being registered or an error about a specified file not being found. The second of these error messages is closer to the truth, since the problem is that even though the control is registered the system can’t find the assembly. Now there are a few ways you can fix this, some are better than others.


First way (definitely a bad idea)
The first way to do this is to put it in the Global Assembly Cache (GAC) which has two problems, it’s a bad idea to be gunking up your (or your customers) GAC with a bunch of home-grown assemblies and since the original release I put out for download is not signed with a strong name it won’t work.


Second way (probably a bad idea)
The second way to do this is to use the /codebase switch with regasm.exe. To find out what the codebase switch does you can read about it at Assembly Registration Tool. The basic command line command to do this:


regasm /codebase dotnetcontrol.dll


Just in case you don’t know, you may need to include the full path to both regasm and the dotnetcontrol.dll in the command above. So for you it might be something more like:


C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\regasm.exe /codebase C:\DotNetControl\DotNetControl.dll


The problem with this approach is that since the assembly (dotnetcontrol.dll) isn’t signed with a strong name you’ll get a scarey message like the following when you run register the assembly with the /codebase switch:


RegAsm : warning RA0000 : Registering an unsigned assembly with /codebase can ca
use 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.
Types registered successfully


Now, I personally think the warning message is a little overblown, but if they say that the /codebase switch should only be used for assemblies with a strong name then let’s move on to the third way to do this.


Third way
Download the assembly I’ve rebuilt. It is signed with a strong name so you can use the /codebase switch without getting that scarey message above. If you’ve already registered the one from my previous blog entry then unregister it. Then register this new one using the same steps given in the second way I presented above.


How to sign an assembly with a strong name
For those of you that are working with the C# project and would like to know how to sign your assembly with a strong name, you can read about it in Signing an Assembly with a Strong Name. Basically the easiest way to do it is to use sn.exe (comes in the SDK) to create a strong name key file (.SNK). Then put that strong name key file in your project somewhere. Finally open up the AssemblyInfo.cs file in your project and put the following line at the bottom of it (you need either the fullpath or relative path to the key file inside the quotes):

[assembly:AssemblyKeyFileAttribute(@”sgKey.snk”)]


Now you can rebuild your assembly and it will be signed with a strong name.


Parting thoughts
When creating controls or examples with .NET whether it be an FLL, an ActiveX control, or whatever it pays to take the time to map out the steps for properly installing the runtimes or registering the control. A few extra minutes on my part could have saved some of you precious time. You have my apologies and I think I’ve learned my lesson this time. Special thanks to Bernard Bout and Gary Williams for being the first two developers to bring this issue to my attention.