locked
Installing GAC without using MSI RRS feed

  • Question

  • Hi Everyone,

    I have to deploy a 3<sup>rd</sup> party application on user pc thru my application.

    I have an application which helps the user (of my client company) to deploy 3<sup>rd</sup> party applications on their machine without using the application’s MSI or setup. I distribute the applications files/folder, and all necessary registry entries thru my application, previously I use to restrict the applications to use their local DLL by implementing exe.local mechanism. Recently, I came across an application which is using GAC for its DLL. After a bit of research over the internet, I came down to few options regarding the deployment of such application without MSI.

    1. Extracting DLLs from GAC (by unregistering shfusion.dll) and then distributing them in application’s local folder along with exe.local. The issue I observed in this implementation was that the application looks for the DLL in GAC location and then tries to access from local folder (observed the behavior using process Monitoring tool).
    2. Another option could be to install the assemblies thru my application on user’s machine. To achieve this approach the only option which I think I can do is thru GACUtil.exe (as I cannot make MSI to install assemblies using windows installer).  One of the issues regarding this implementation is that the users may not have GACUtil.exe already placed on their machines. Moreover, while going thru msdn documentation, it states that using GACTUtil.exe for assembly installation is not recommended for deployment. Can you please guide me the differences which end user can face between installing an assembly thru windows installer or by GACUtil.

    Please guide me in this regard that what would be that best approach to deploy the application in my scenario. If you can suggest other options achieving the functionality (e.g. using manifest file etc.) please advice.

    Thanks & Regards,

    Maverick.

    Thursday, December 20, 2012 12:34 PM

Answers

  • Thank you Kornad,

    I found an other way to install the assemblies in GAC thru code by using Publish.GacInstall() method of System.EnterpriseServices.Internal. What's your opinion regarding this solution?

    Thanks & Regards,

    Maverick.

    • Proposed as answer by Konrad Neitzel Monday, December 24, 2012 12:11 PM
    • Marked as answer by Haroon Rafiq Wednesday, February 13, 2013 12:39 PM
    Monday, December 24, 2012 11:41 AM

All replies

  • Hi,

    I understood that you want to register / unregister DLLs into the GAC from your code, is that correct?

    In such a case, the following thread might be usefull for you:
    http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/7d3165cf-ca3b-43cc-8f77-a46dbf38f13d/

    But be aware that your application needs to run with administrative rights to do so. And our best practice that we (the team I am working in) is doing:

    - When we install a 3rd party DLL inside the GAC we always use the vendor installer to install the whole 3rd party product.

    - When we just want to distribut parts or we / the customer does not want to take care of the maintanence of the 3rd party product, we only deliver the required DLLs/files with your application and we do not install them to GAC. (At the moment all our products does not install anything inside the GAC. Even the COM component that we provide in one product just gets the 32bit/64bit COM registration and is not installed inside the GAC.)

    And when the application is linked to a specific version of the 3rd party dll, then it should not do any harm if the DLL is searched inside the GAC first.

    If the 3rd party vendor is a little bit lazy and is not really handling versions in an acceptable way (e.g. giving out different DLLs with the same version / localisation / signature, then we would merge the DLL into one of our assemblies. (ILMerge is quite nice!)

    I hope that was helpfull for you.

    With kind regards,

    Konrad

    Thursday, December 20, 2012 3:35 PM
  • Thank you Konrad,

    You are correct, I meant register/ unregister DLL into GAC folder. But my more concern is that is this the best way?

    Another thing that I feels like I didn't communicated clearly is that the DLLs I want to register are not used by my application instead the DLL vendor's application will use those DLLs, the role of my application is to facilitate the user to deploy 3rd party application without using MSI.

    One more thing that I m concerned about is that what difference would it be between my application registering a DLL thru GACUtil and a windows installer registering it? I understand that DLL registered using GACUtil wont get uninstalled when my application is uninstalled. Is it so? I also understand that GACUtil is a tool primarily meant for developer therefore I would need to dispatch GACUtil.exe with my application to end user.

    Regarding ILMerge, I think it will work only if my application needs to access 3rd party DLLs, which is not in my case, as in my case only the 3rd party application will use its DLLs.

    Hope I clear my points.

    Thanks & Regards,

    Maverick.

    Friday, December 21, 2012 6:53 AM
  • Hi Maverick,

    thank you for the additional informations.

    I am just wondering: Why is MSI outside of the possibilities? What I understood now is, that you build a component that someone else wants to use. And the standard installation method on windows systems is through MSI files. (But if that is a fixed requirement that you cannot change we do not have to discuss this point in detail.)

    Your understanding is more or less correct: A MSI file that is build propperly will uninstall completly. So when deinstalling, the DLL will be gone from the GAC. If you install an assembly manually, you have to remove it manually, too.

    I would prefer the code-way to register a DLL inside the gac. I am not sure about the redistribution licens of GACUtil - but as far as I know, Microsoft offers redistributable packages but does not allow to redistribute just a single part. And I doubt that you want to redistribute the full windows sdk with your application.

    You understood the ILMerge correctly. It is used to include dependencies so it is not really useable in your case.

    And your main question: If others are using your component and do not distribute it with their application, then it should be placed inside the GAC.

    With kind regards,

    Konrad

    Friday, December 21, 2012 5:49 PM
  • Thank you Kornad,

    I found an other way to install the assemblies in GAC thru code by using Publish.GacInstall() method of System.EnterpriseServices.Internal. What's your opinion regarding this solution?

    Thanks & Regards,

    Maverick.

    • Proposed as answer by Konrad Neitzel Monday, December 24, 2012 12:11 PM
    • Marked as answer by Haroon Rafiq Wednesday, February 13, 2013 12:39 PM
    Monday, December 24, 2012 11:41 AM
  • Hi Maverick,

    in my eyes that is also an acceptable solution. The Namespace suggests that a use is not intended ("Internal") but I looked at the verbose descriptions of the namespace and the class and there is no explicit note that the classes, methods, whatever should not be used directly.

    So I think you found a quite nice solution. (And it is for use by unamanged COM components if I understood everything correctly. So it seems to be an official interface that is quite unlikely to be changed. Pure internal stuff might be changed even in a hotfix and break your solution. But I wouldn't expect something like that in this case!)

    But this is of course my personal view only (I am also just a community member like you and can only guess what microsoft intended or not intended).

    With kind regards,

    Konrad

    Monday, December 24, 2012 12:10 PM