I am somewhat new to using the Global Assembly Cache in .NET, and have a question regarding how it works since I haven't been able to find anything online.
My msi(created using Visual Studio Installer extension (using Visual Studio 2015)) installs a number of assemblies into the GAC and my application(the assemblies need to be in the GAC because 3rd party application need to access them too). After running the installer and starting the application, I noticed that when I start my application, copies of the dlls from the GAC are made in the application execution directory.
My question is, is this how using assemblies from GAC normally works? I assumed that the assemblies would just be loaded from the GAC without making local copies. Or is this some error on my part and how I built my application(CopyLocal is set to true but from what I understand, this only matters for Visual Studio and has no effect on actual execution after deployment).
Based on Hans' input, the issue is with my msi and is not GAC related. While msi installs the assemblies to GAC and not the execution directory, when the application is run it is msi "self-healing" that creates the files, they are not copied from GAC.
Related
I wrote an application that work with Git using the library LibGit2Sharp, everything works properly.
After finishing development, we publish to a common folder from which everyone works.
I want to create an installation for the application and that everyone will install it.
To create an installation for the application, I added a new Setup Project to Solution and referenced all the projects in Solution to it.
I installed the app and it runs, but crashes when trying to work with Git.
The error I get:
DllNotFoundException: Unable to load DLL 'git2-106a5f2' or one of its dependencies: The specified module could not be found.
The point is that the Dll file described exists in the installation folder as it exists in the Publish folder.
Is there anything I should have taken into account during the installation process?
what am I missing?
This error can occur if the required dependencies of the "git2-106a5f2" DLL are not installed or are not located in the PATH. If the necessary dependencies are installed and found in the PATH, you may check for them. If not, you may do so when installing by adding them to the PATH.
Another choice is to deliver your program along with the installation package that contains the necessary dependencies.
By doing this, regardless of the user's environment, you can make sure that your application always has access to the necessary dependencies.
Make sure you are using the appropriate version of the "git2-106a5f2" DLL for your program by checking to see if it is an x86 or x64 DLL. Use the x86 version of the DLL if your program was created for that architecture, and the x64 version if it was.
i have an issue with the old setup projects in VS2010. please don't blame me for using that. it's a company decision which cannot be changed. poor enough i HAVE to deal with it.
i think it's quite usual what we got: a solution with some projects. the projects reference assemblies. some of them are 3rd party components. they are ALL referenced to/from the SAME individual folder (NOT the GAC or something like C:\Programs...). we just don't reference the installed versions. we want to keep them all in one place.
here comes the point... the project itself points to the folder we want. building and running is fine.
when i examine the setup project, SOME of the 3rd party assemblies are taken from our specific folder, others are taken from C:\Programs...
i just don't know why. i cannot influence this as it seems. even manually editing the .vdproj file ( were "GAC:FALSE" can be set) doesn't help! we need to reference the specific *.dlls in our folder.
has anyone an idea on this? i haven't found something so far...
cheers!
jens
This is how VS behaves. Even though you told him to search for your 3rd party dlls in your own folder, if it finds the same dll in GAC, it will reference it from there. On computers that do not have the dll in the GAC, it will reference it from your folder. In other words, if the computer you deploy your application has all the 3rd party assemblies in the folder that you referenced them from, and the folder exists on the target machine, the application will not crash, even if the dlls are not in the destination you see on your own machine, and will use the assemblies from the folder.
Maybe somebody fiddled with the default reference paths in Visual Studio. If you look at this article, about half-way through it explains the registry keys that are used to locate referenced assemblies:
http://msdn.microsoft.com/en-us/library/wkze6zky(v=vs.100).aspx
I think that the VS search mechanism will go through this list at build time, and you may end up with a rather strange combination, especially if some assemblies have dependencies on others and the assembly versions are different. So if you start with a certain assembly that requires others with a particular version it will chase that list of directories until it finds them.
I don't believe it is correct that VS will get assemblies from the GAC by default for reference purposes. The .NET runtime will do this when you run the program, but at dev time all the MS assemblies, for example, are referenced from the SDK install, not from the GAC. The GAC is a repository for running programs that require those assemblies, not a reference for dev builds.
The C# application that I'm trying to deploy has two critical references, A.dll and B.dll.
First, I used InstallShield LE which includes everything (.dll's and .pdb's) in release folder into application files, application is deployed to different computers without problem. The app is about 6M after installation.
Then, I started to use VS installer, including "primary output" into application folder. I can see both A.dll and B.dll are included. After install the app on another computer, A and B exist in the installation directory too. When I run the application, it gives me "could not load file or assembly "B.dll" or one of its dependencies" error. B.dll only depends on .NET framework. The app is only 3M after installation because the installation directory has only the .dll's (no .pdb's).
Did I miss anything here? Any idea would be helpful, Thank you.
Edit:
The difference between A.dll and B.dll is that B.dll is compiled from a C++/cli program while A.dll is from C#. Does this make them different in deployment?
I would suggest using Fusion log viewer on the target machine to determine why the DLL is not found.
http://msdn.microsoft.com/en-us/library/e74a18c4.aspx
Sometimes Fuslogvw can be a pain to get working, if so try restarting the machine, or see any of the blog posts about it
https://www.google.ca/search?q=fuslogvw.exe&oq=fuslog
I'm sure once you find the reason (in the logs) it will be obvious what the problem is with the MSI, but if not post your findings.
So I made a C# project in visual studio with 3 class library projects. Everything works fine when debugging but When I try to deploy. Database and Program installs just fine but when I try to open the Application, I get an Assembly or File not Found Exception. The DLL he can't find is a class library in my project.
On the File System Editor, VS automatically detected the dependencies and included the 3 dll files in to application directory. I tried excluding these dll's and just adding the class library projects's primary output's (Same dll) but still the same error.
I used a Custom Installer class for creating my database on installation. But I don't think that is relevant.
If you have verified that your 3 assemblies are indeed deployed to your destination folder,
it could very well be an another dependency that you have not included in your setup project.
Please double check that you indeed have the right number of assemblies included.
You can also right click the setup project and refresh dependencies.
Have you checked that dependencies in the setup project aren't excluded (by mistake)?
Furthermore, it may also be a .NET profile issue. Do you depend on assemblies that are only available in the full .NET profile, and your destination only has the client profile installed?
In worst case, run the SysInternals process monitor and that way figure out which assembly is missing.
you need to include all dll's that are not part of the .net framework with your deployable. Your custom installer will copy these files to the location of the executable on install.
i usually create a folder called /deploy and copy all my needed dlls in there. I also change my projects settings to output to the /deploy-directory (instead of bin/). after you build, this directory will contain all dll's and other resources needed to run the application.
I believe that I am dealing with some DLL hell.
I have a reference to Microsoft.TeamFoundations.VersionControl.Client in my application and 'copy local' is set to true. The application runs as expected on my development machine.
When I deploy this application I get an exception when trying to execute Microsoft.TeamFoundations.VersionControl.Client.DownloadFile()
Method not found: 'System.IO.Stream Microsoft.TeamFoundation.VersionControl.Client.Item.DownloadFile()'.
The version that gets deployed to my bin directory is version 9.0.3. The method exists. I noticed that a previous version of this dll does live in
C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies
How come my application does not appear to be using the assembly that I referenced within my solution and ends up in bin? How can I force this to happen?
Thanks!
I'm not sure if this is it, when I was trying to use TFS 2008, I had to target the x86 processor instead of Any CPU in the project settings. Without doing that, I was finding wierdness when my app deployed to other peoples machines.
Also, I deploy a number of dll's with my app, maybe you've missed deploying something that VersionControl.Client.dll depends on, and it's trying to use another dll of which it's getting the wrong version. I distribute the following (not sure if they're all needed, but you could try distributing more to see if that solved it):
Microsoft.Build.Framework.dll
Microsoft.TeamFoundation.Build.Client.dll
Microsoft.TeamFoundation.Client.dll
Microsoft.TeamFoundation.Collaboration.dll
Microsoft.TeamFoundation.Common.dll
Microsoft.TeamFoundation.Common.Library.dll
Microsoft.TeamFoundation.dll
Microsoft.TeamFoundation.VersionControl.Client.dll
Microsoft.TeamFoundation.VersionControl.Common.dll
Microsoft.TeamFoundation.VersionControl.Controls.dll
Microsoft.TeamFoundation.WorkItemTracking.Controls.dll
Microsoft.VisualStudio.TeamFoundation.Client.dll
Microsoft.VisualStudio.TeamFoundation.dll
Microsoft.VisualStudio.TeamFoundation.WorkItemTracking.dll
It appears from this link Microsoft.TeamFoundation.VersionControl.Client.Item.DownloadFile() is missing that there are other (and presumably safer) way to do this with other methods.
The application insisted on referencing these dlls from the GAC. I ended up installing VS 2010 on the development environment and referencing the Microsoft.TeamFoundation dlls from the GAC. VS 2010 installed version 10 of the Team Foundation dlls into the development GAC.