.NET deployment for dll assemblies and added to the GAC...
I have come across a major issue that I cannot seem to resolve...we have to come up with a way to deploy a bunch of dll files to a persons desktop with little to no interaction. Can here is that you need to register them in the GAC for them to work and be used.
From what I understand through my testing:
PowerShell can accomplish this but is very complicated and there is not guarantee that it will be installed on the client box.
XCOPY cannot register things in the GAC in say using a bat file to copy from a network location
MSI installers are not longer an option in .NET 2012 but you can use the InstallShield, which doesn't register in the GAC
You can copy the gacutil.exe to the client box but that will create issues with license agreements, versioning, etc...
So here I am, an MVC/ASP.NET Webforms and WPF developer trying to figure out how to get this to work. Surely it cannot be that complicated and I am missing something I would think...
For the project there isn't an "app" so to speak, just dll files that are being transferred ti the client box and then referenced in Excel...
Can someone that has experience in this topic please tell me what I am missing here?
Thanks in advance!
CII
From what I understand through my testing:
PowerShell can accomplish this but is very complicated and there is not guarantee that it will be installed on the client box.
XCOPY cannot register things in the GAC in say using a bat file to copy from a network location
MSI installers are not longer an option in .NET 2012 but you can use the InstallShield, which doesn't register in the GAC
You can copy the gacutil.exe to the client box but that will create issues with license agreements, versioning, etc...
So here I am, an MVC/ASP.NET Webforms and WPF developer trying to figure out how to get this to work. Surely it cannot be that complicated and I am missing something I would think...
For the project there isn't an "app" so to speak, just dll files that are being transferred ti the client box and then referenced in Excel...
Can someone that has experience in this topic please tell me what I am missing here?
Thanks in advance!
CII
...yet another way is to install WiX add-on into Visual Studio, and create the installation in it. The article "Installing Assemblies for Runtime and Design-time Use" has the details.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Not sure I get what you're saying:
NoteNote
Gacutil.exe is only for development purposes and should not be used to install production assemblies into the global assembly cache.
It must be in the GAC and this will not do the job:
It does, see http://msdn.microsoft.com/en-us/library/dkkx7f79(v=vs.110).aspx
NoteNote
Gacutil.exe is only for development purposes and should not be used to install production assemblies into the global assembly cache.
It must be in the GAC and this will not do the job:
It does, see http://msdn.microsoft.com/en-us/library/dkkx7f79(v=vs.110).aspx
Can here is that you need to register them in the GAC for them to work and be used.OK, so I'm very curious: Why would this be?
ASKER
Don't register them in the GAC and it doesn't work. Register them and it works.
Not sure the reason why and we don't have time to evaluate the why but only time for the HURRY UP AND GET THIS DONE!!! lol
Not sure the reason why and we don't have time to evaluate the why but only time for the HURRY UP AND GET THIS DONE!!! lol
Something that nobody seems to have stated in this thread is that you need to be an administrator to install something in the GAC. It also requires that the dlls be signed. And if you install a new version of a dll in the GAC, the older applications won't use it, they will still use the old version unless a redirection is defined somewhere in the .NET loading system.
This gives you a little more control about updates, but make them more complicated to manage unless you understand all the little intricacies. This is thus usually not a very good place to store your own dlls. The application directory is usually better.
The main reason for using the GAC if for companies who really know how to use it and want to be able to update a dll used by many applications without having to know where they are installed on the computer.
This gives you a little more control about updates, but make them more complicated to manage unless you understand all the little intricacies. This is thus usually not a very good place to store your own dlls. The application directory is usually better.
The main reason for using the GAC if for companies who really know how to use it and want to be able to update a dll used by many applications without having to know where they are installed on the computer.
I don't think it would.
> but you can use the InstallShield, which doesn't register in the GAC
It does, see http://msdn.microsoft.com/en-us/library/dkkx7f79(v=vs.110).aspx
Also, depending on the purpose, maybe it's not necessary to put them in GAC. If they are going to be used by one application, xcopy to the app directory will do it.