none
VS2010 Project Install: GAC 4.0, 3rd party reference does not have a strong name

    Question

  • Target Framework: .NET Framework 4

    I have built a dll (c#) which has to be in the GAC on the target machine (AppServer), to be seen by a 3rd party scripting Engine. The third party scripting Engine is dependent on .NET Framework 4.0 but not in the GAC.

    I am trying to create a setup project in VS2010 to install the my dll (my.dll) in the GAC. My.dll is a signed assembly with a strong name key. The third party dll which is referenced (third.dll) does not have a strong name.

    The third party scripting engine is part of an Appserver deployment. My.DLL can be 'hooked' by users (through the GAC listing) and the my.dll interface recieves an application object defined in the third party dll. The use of this application object requires me to reference the third party dll in my build.

    The problem is that the Setup project will not compile (even when the third.dll is excluded). I recieve an error;

    Error 1 Assembly generation failed -- Referenced assembly 'third.dll' does not have a strong name

    I did not have this issue with 3.5\vs2008. I used GacUtil to put my dll in the GAC. It appears the preferred approach now is to generate a setup program.

    How can I get my.dll into the GAC on a 2008 production server using .Net4\VS2010 ? I do not care how(GACUtil, Setup, manual) as long as I can get it there.


    djw

    Tuesday, April 10, 2012 12:22 AM

Answers

  • The AssemblyLinker program al.exe has a /key option to strong-name assemblies - if that works on that 3rd party assembly that looks like a solution.

    Phil Wilson

    Wednesday, April 11, 2012 4:49 PM
  • I ended up breaking the third party code references into a 'toolkit' which doea not reside in the GAC. My.dll resides in the GAC and provides lower level function to the toolkit. This resolves the issue.


    djw

    • Marked as answer by DanJWentworth Tuesday, April 17, 2012 11:48 AM
    Tuesday, April 17, 2012 11:48 AM

All replies

  • Target Framework: .NET Framework 4

    I have built a dll (c#) which has to be in the GAC on the target machine (AppServer), to be seen by a 3rd party scripting Engine. The third party scripting Engine is dependent on .NET Framework 4.0 but not in the GAC.

    I am trying to create a setup project in VS2010 to install the my dll (my.dll) in the GAC. My.dll is a signed assembly with a strong name key. The third party dll which is referenced (third.dll) does not have a strong name. It is installed on the target machine by a seperate process.

    The problem is that the Setup project will not compile (even when the third.dll is excluded). I recieve an error;

    Error 1 Assembly generation failed -- Referenced assembly 'third.dll' does not have a strong name

    How can I get my.dll into the GAC? I do not care how(GACUtil, Setup, manual) as long as I can get it there.



    djw

    Monday, April 09, 2012 6:27 PM
  • The issue isn't really the setup. You can't bind to unsigned assemblies from the GAC, so it's not letting the build work.

    I don't understand your scenario. That assembly is installed by another setup to some location (can't be the GAC) so I don't see how your assembly can load into an executable because it won't know how to find that 3rd party assembly. If a client program running out of Program Files loads your assembly, your assembly will try to load 3rd party Dll from where? On the other hand if the 3rd party assembly is COM based, then you don't need a reference to it from your assembly.

    Anyway I don't think is strictly a setup issue - you could ask in a NET forum how to install an assembly in the GAC that has a reference to an unsigned assembly because I'm pretty sure GacUtil will tell you the same error.


    Phil Wilson

    Monday, April 09, 2012 9:39 PM
  • I have written an extension to a third party c#.Net scripting engine (the extension was built and works under 3.5). The script Engine runs as anAppServer under IIS. It is not in the GAC.

    Within the Extension I am using an application object passed in by the extension interface call. All the work is done within the context of this application object The definition of the application object is the reason for my reference to the unsigned assembly.  Does this clarify the scenario?  (There is no executable involved)

    After Deployment  the only choice the end user has to reference (using the third party tool) my extension (dll) has to be in the GAC. I cannot control this third party behaviour.  This is my motivation to install my dll in the GAC.

    With 3.5 \ VS2008 build it was a simple issue to put the same extension dll in the GAC. The unsigned reference  was not an issue.

    I ported the project to 4.0 \ VS2010 then this issue developed.


    djw

    Monday, April 09, 2012 11:44 PM
  • Hi Djw,

    Welcome to the MSDN Forum.

    The assembly need a strong name to be cached in GAC.

    So how about generating a Strong name: http://msdn.microsoft.com/en-us/library/xc31ft41.aspx 

    Or giving up to add it into GAC, just reference the local file: Change the "Copy Local" property to True.

    I hope this will be helpful. If anything is unclear, please feel free to follow up.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Tuesday, April 10, 2012 9:24 AM
  • Those are not options when dealing with the third party scenario described.

    My assembly does have a strong name. It is the third party reference that does not have a strong name.


    djw

    Tuesday, April 10, 2012 10:48 AM
  • Those are not options when dealing with the third party scenario described.

    My assembly does have a strong name. It is the third party reference that does not have a strong name.


    djw

    Hi Djw,

    Because the third party reference does not have a strong name, I suggest you don't add it into GAC.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, April 11, 2012 3:27 AM
  • Open your project in Visual Studio & Set the 'Copy Local' property of the third party DLL to 'FALSE'. Then try creating the setup.


    Please mark this post as answer if it solved your problem. Happy Programming!

    Wednesday, April 11, 2012 4:24 AM
  • Those are not options when dealing with the third party scenario described.

    My assembly does have a strong name. It is the third party reference that does not have a strong name.


    djw

    Hi Djw,

    Because the third party reference does not have a strong name, I suggest you don't add it into GAC.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Thanks for the feedback.

    This is not an option. The end user (developer) only has access to the GAC to use the extension.


    djw

    Wednesday, April 11, 2012 12:37 PM
  • Open your project in Visual Studio & Set the 'Copy Local' property of the third party DLL to 'FALSE'. Then try creating the setup.


    Please mark this post as answer if it solved your problem. Happy Programming!

    Thanks for the feedback.

    I tried this. The setup compiler still throws an error regarding the strongly named assembly.


    djw

    Wednesday, April 11, 2012 12:39 PM
  • Those are not options when dealing with the third party scenario described.

    My assembly does have a strong name. It is the third party reference that does not have a strong name.


    djw

    Hi Djw,

    Because the third party reference does not have a strong name, I suggest you don't add it into GAC.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Thanks for the feedback.

    This is not an option. The end user (developer) only has access to the GAC to use the extension.


    djw

    Thanks again.

    To clarify; There is no attempt to add the Third party DLL to the GAC, Just my DLL. 

    My extension is being called wih an application Object. The third party DLL contains the definition of the application object. All I require is the definition to execute methods in the refenced application object. I am not executing or loading the third file DLL. Just executing methods on the Object that has already been loade. This is similar to "Explicit Linking" in the C++ world.


    djw

    Wednesday, April 11, 2012 12:47 PM
  • Thank You all for your responses. This issue has been bounced thru several forums.

    I believe this issue is related to changes made in .Net 4 described in this article.

    Migrating an APTCA Assembly to the .NET Framework 4

    http://msdn.microsoft.com/en-us/magazine/ee336023.aspx

    I am tempted to create something akin to an IDL file to define the third party interface to satisfy the compiler for method calls into the Object reference passed in. This would be a lot of work. 

    Is there an approved approach in the .Net world?


    djw

    Wednesday, April 11, 2012 12:56 PM
  • The AssemblyLinker program al.exe has a /key option to strong-name assemblies - if that works on that 3rd party assembly that looks like a solution.

    Phil Wilson

    Wednesday, April 11, 2012 4:49 PM
  • I ended up breaking the third party code references into a 'toolkit' which doea not reside in the GAC. My.dll resides in the GAC and provides lower level function to the toolkit. This resolves the issue.


    djw

    • Marked as answer by DanJWentworth Tuesday, April 17, 2012 11:48 AM
    Tuesday, April 17, 2012 11:48 AM
  • You can use ILMerge for assigning Strong name to third party Dll

    or u can merge third party Dll in a single dll then you can make that single dll as signed dll e.g

    C:\Program Files\Microsoft\ILMerge>ilmerge /out:myGeneratedSinlgeDll.dll /keyfile:Myk ey.snk Primary.dll thirdPartyUnsigned.dll


    Friday, April 27, 2012 8:22 AM