DSL Tools: How to create the DLL as weak-named

Question

Hello,

I have a DSL Tools solution.

I need to add a weak-named reference to this project. Because the DSL Tools project DLL is strong-named i cannot used the weak-named DLL.

I cannot make the DLL strong-named because i cannot recompile it.

I tried to make my DSL Tools project DLL weak-named by going to the Dsl and DslPackage project properties and unchecked the option "Sign the assembly" in the Sigining tab.

Then i compile it. The error list gives the following error

"gacutil.exe" exited with code 1

Looking at the VS2005 output window i see gacutil is being called

C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\bin\gacutil.exe -nologo -i "C:\Academy\ResearchAndDevelopment\FrontendGenerator\DslPackage\bin\Debug\vantyx.FEGenerator.DslPackage.dll"

After that i used the command prompt and the gacutil.exe error displays as this:

Z:\>"C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\bin\gacutil.exe" -nologo -i "C:\Academy\ResearchAndDevelopment\FrontendGenerator\DslPackage\bin\Debug\vantyx.FEGenerator.DslPackage.dll"
Failure adding assembly to the cache: Attempt to install an assembly without a strong name

I don't know why and how gacutil.exe is being called. I looked at the project and solution properties and there is no option configured to call gacutil.exe. I even looked inside every file for "gacutil.exe" but i found nothing.

What i really want is to be able to use the weak-named DLL that i cannot make strong-named. As a result of this, i've been trying to make my DSL Tools DLL weak-named but i can't.

Any help on how i can workaround this?

Many thanks in advance, Luís Filipe

Answer 1

With the exception of the answer written above, All add-ins for Visual Studio must be strong-named.

One may workaround some of the issues by loading the assembly on run-time and using reflection to invoke methods.

Regards, Luís

Answer 2

Using runtime binding with reflexion is a good solution and works. The other solution I've implemented besides that one is to launch a separate AppDomain and have that AppDomain doing the loading of the assembly and running whatever methods you want. The downside of this approach is the extra complexity and performance. One really has to know what he is doing as he is in practice launching a separate .net application in Visual Studio's process space. The upside is that with some care, you can get type safety all the way.