I'm working with an addin using C#. I don't think it matters for this question, but in this case it's an addin for Autodesk Inventor 2009 - a little toolbar with a button that launches a small program. My problem is more related to the registration of my .Net assembly DLL-file. The addin is a DLL and the small program is an external C# project added into my Visual Studio 2005 solution. This small program is not an addin itself so it's an EXE-file that is copied into the addin debug folder on solution build. My addin calls the main form in the small program when clicking the launch button.

When registering the DLL-file with RegAsm.exe with /codebase I get warnings that this could affect other programs and that I should only use /codebase with strong name DLL files. If I register without /codebase it gives me no warning, but in both cases everything fails. I guess that's because I loose some kind of dependency between the DLL and the EXE.

I managed to solve this by signing both the addin and the small program in Visual Studio as strong name. I get that strong name key file (.SNK) and the registration works without warning and the addin works perfeclty fine. So I found a solution to my problem and I was happy until tried to lock this program with our companys locking and encryption tool - PC Guard for .Net. When protecting either the DLL- or the EXE-file I get this error message: "Strong name signature verification detected in application. Please turn OFF strong name signature verification in your compiler and re-protect application." And if I do that I'm back with the addin that won't work. It seems PC Guard cannot handle strong name, so I guess my question is if there is another solution to this without strong name? Or can I not use PC Guard for addin applications like this?

Don't know what PC-Guard is but hope this helps anyway.

You are trying to register a COM component that can be used by other programs.

The problems you are describing is not related to the signing. I'm pretty sure the problem is the location of the files.

If you don't use /codebase, the path to your dll is not stored in the COM registry. This means that any application using your dll need to able to locate your dll without the path. i.e. you need to put your dll in the main application's program directory.
My recommendation is to use /codebase and ignore the warning (at least to get it working).

Second problem is that a managed dll can't be executed like any exe file. To run your code, windows need to host your dll in another application. Don't remember right now what the hosting application is called but it is not important. The point is that when your dll is running, the working directory is the hosting application's working directory, i.e. windows\system32. If you try to execute your .exe without supplying the full path, windows will look for it in windows\system32.

The easiest way to solve it is to start your exe with the full path. You can also register a COM+ application to host your component. In the COM+ application properties you can specify a working directory for your component. (Use dcomcnfg to create the COM+ application).

Another tips is to use the process monitor and see where the system is looking for the different files.


(And last, why not put the COM component in an exe file instead of a dll? It will not solve the file location problems but there are other benfits: 1. Your component runs in its own process. A crash in your component will not crash the main application. 2. You can stop your component and replace it with an updated version without taking down the main application)