I am using Visual Studio and Windows environment.
The situation is like this:
On the first environment "A" I am building the application.
In bin directory of that project I have my own dll.
Same dll, but different version (old version with an error in code) I have in GAC of this environment.
So running this application on that environment would produce an error because my application would use this dll from GAC, so old dll, bugged version.
The question is what would be if I build this application on the first environment "A" (with wrong dll in GAC) and test this application on the second environment "B" where there is no dll in GAC.
Would Visual Studio take dll from GAC or from dll while building the project ?
If the question is not clear please ask the question.
Regards
Related
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.
I have a main project A, with multiple subprojects. Among these subprojects, the project B includes Dlls which are required for the applicatioin to run. So I can select these Dlls and set them to be copied after the generation, which works fine.
The problem is, these Dlls are NOT copied when I deploy my project. How can I put these Dlls in the system32/ folder of the destination computer on deployment?
Working on Windows XP with Visual Studio 2008 SP1.
The application will only be installed on XPs.
Simplest way preferred.
Thanks a lot.
This is my first time trying to use a dll file in visual studio (2012) so I am not sure what I am doing wrong. I am trying to get sqlite into my project following this tutorial
I right click on the project in the Solution Explorer and click Add References
I then click on the browse tab and find where I have the dll file,click ok then ok in visual studio and I get an error saying Reference to *dll path* could not be added. Please make sure the file is accessible and that is it a valid assembly or COM component.
did I miss a step here or something?
The file is located in my dropbox folder (where my whole project is) and the project is a windows store application is that matters
Not a direct answer but instead of referencing the dll directly, you should install the Visual Studio extension for SQLite. The extension includes the dlls for all platforms (x86, x64, ARM). It also makes sure that the right dll is used for the platform that you are building for.
After you install the extension, it will appear in the references dialog under Windows -> Extensions. Also, when you use the extension, you must change all your project build configurations to be x86 or x64 (on the desktop) or Arm (for Arm devices). It will fail to build if you use AnyCPU.
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.
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.