Any ideas how to force a GAC DLL into referenced?
Here is my issue, I constantly use a 3rd party DLL that registers itself into the GAC, and when I use it in my project, it reads it from the gac, and when I deploy, I'm always forgetting to add the DLLs since it is not located in the Bin/Referenced folder.
Anyway to force Visual Studio to add the DLL instead of from GAC?
Copy Local only works if the GAC'd assembly if one reference level deep. For instance, if you have a project that references the GAC'd assembly, and that project if referenced by your web project, then while yes, the GAC'd assembly will be copied to the first project's bin folder, but it won't be copied to your web project's bin folder.
The solution, then, is to directly set a reference in the web project to the GAC'd assembly, and specify Copy Local. Even though the web project doesn't directly use the reference in this case, it will copy it to the web application's bin folder.
Right click on the assembly reference, select properties, and change "Copy Local" to true. That will cause it to copy the assembly into the deployment directory
Select the dll in your references and set CopyLocal=true in the properties window.
Select the reference and set the Copy Local property to True
Related
I am using Visual Studio 2010 with MCV4 (Installed separately).
Some dlls are linked to the orignal path, and some are copied to the project.
I don't want them to be copied to the project.
i.e when building Web project (MCV4 -> Web API), I see several dlls, that automatically created:
Antlr3.Runtime.dll - created on project folder (and path is not the original folder).
also: EntityFramework.dll, System.Web.Optimization.dll and some more,
where system.web is on C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\System.Web.dll folder.
Why the above dlls are copied to the project folder, and how can I enforce that they would be on the original one?
Thanks :)
If you rightclick each references assembly in your project there is a propery "Copy Local". For each reference you set Copy Local=true it will be copied into your output folder (\bin).
Unless the DLL is in the GAC (Global Assembly Cache), you will want to copy it locally as the application will not know where to load these DLLs from. By default when you add a reference, Copy Local will be true when the DLL is not in the GAC.
If the application can not find the DLL's it needs it will fail when the DLL is needed.
A .Net application can only load DLLs from the GAC or from your application path and subdirectories unless you employ your own Assembly.Load() code to do this.
I have a solution in VS 2010 containing 5 C# projects, 1 C++ project and 1 VB project. My solution has a solution folder "Dependencies" that replicates a file-system folder with the same name. The solution folder has a number of .dll files and some .xml files in it.
When I build my solution, all but one of the .dll files are copied from that folder to my output directory. I've looked at the file in Visual Studio for Copy Local property that is referenced here, the property is not there for any of that files in that folder.
I've looked at all the projects in my solution, and none of them are actually referencing that dll directly which I'm assuming is why it's not being copied. The problem lies in that one of the dlls that IS referenced by one of my projects depends on the dll not being copied.
I tried to add the problem dll as a reference in my projects and I get the following error
A reference to "dll" could not be added, Please make sure that the file is accessible, and that it is a valid assembly or COM component.
I don't really care if it's a COM component or that it's valid etc... because I need it to output.
My question is: How can I beat Visual Studio into submission and force it to copy the dll?
No need to beat anything, just add the DLL to one of the projects with Project + Add Existing Item. Any will do but you'd normally favor the one that has the dependency on this DLL. Your EXE project if you are not sure. it isn't clear if it matters, but use the arrow on the Add button to select "Add as Link" so the file doesn't get copied to the project directory. Afterwards, select it and change its Copy to Output Directory property to "Copy if Newer".
Do keep an eye on source control, this DLL probably needs to be checked-in. So having it in the dependent project directory is actually a good place for it.
Using xcopy.exe in a Post-Build event is otherwise a general way to copy dependent files that the build system doesn't know about or puts in the wrong place.
All external libraries I use in my solutions are in the Lib folder of respective projects within a solution and all have their Build Action property set to 'Content' and Copy to Output Directory property set to 'Copy if newer'.
When I check in my solution into TFS, some dll files are copied to TFS and checked in with a blue lock appearing next to them, and some are not, prompting my team members to ask me for copies of these dll files in order to be able to build the solution...
If File Properties of all these dll files are the same and these are all .NET assemblies, what is it that determines if a dll will be checked in or not, and just what is the most appropriate Build Action for a dll library?
When you add a project or a folder to your source control, dolls and executables are ignored by default. you need to go to the exclusion tab and select the dlls you want to check in explicitly. that's why you have the seemingly random behavior.
What I discovered is that it depends on how you add the dll files to your solution.
If the dll file is first copied to your Lib folder and added to your project from there (copy/paste into Lib folder in Solution Explorer), it is not checked in and copied to the TFS.
If the dll file is added to your project (copy/paste into Lib folder in Solution Explorer) from its original location VS will copy the file to your Lib folder and check it into TFS.
Im setting up a svn repository and wondering where i should put the dll files.
What Ive currently done is put them in the /bin/debug folder and then link them in my project file in visual studio.
is this the way to do it?
I presume you are asking about third party dll files, because the output (exe/dll) files generated by the project are better left unmanaged by SVN, because they are regenerated on each and every build.
What I usualy do is create a Lib folder, that is on the top level of my source tree, and put all needed references there, usually in additional folder divided by tool or by functionality (logging, emailing, apis, etc, etc...)
You should not put anything from the bin/Debug or bin/Release in your source control. If you do that, you will lose them when you clean your solution or your projects.
What you have to do is create a folder, within the solution folder for example, and reference the dlls in your projects. Any third-party dll that is in the references of a project will be copied to the bin/Debug or bin/Release folder when the project is compiled.
We typically have a seperate folder called dlls or something where we keep all 3rd party dlls/assemblies
Dlls are only needed at runtime. For a quick fix, you may copy your dlls in the Debug folder where your .exe file is. This Debug folder is at the same level as the solution .sln file in Visual Studio. Which thing you will have to do each time you start a new project... Debug folder
A better solution would be to copy all third party dlls, plus all the corresponding .h and .lib files, in 2 folders, say C:\dev\include and C:\dev\lib, and then add these 2 folders to your path environment variable once for all. This way, you'll be able to access them from all your projects, without having to copy them over and over.
Now, if you want someone to be able to run your project on another computer, you'll need to copy all needed .h, .lib and .dll files in your project in a separate folders that you create, say include and lib again, in your project directory where your own program files are, as mentioned in the previous posts. Project folder
PS. Sorry, it would not let me upload the 2 screenshots, so click on links.
I typically put it in a Lib folder within my Visual Studio project solution folder. I would also create sub folders all the way to indicate whether the dll is for a 32 bit or 64 bit build and also which version of Visual Studio was used to build it. So something like this: Lib\WIN32\VC2015\ . Then in the Project Properties of the project, under the Debugging Configuration Property, I set Environment to
PATH=$(SolutionDir)Lib\WIN32\VC2015;%PATH%
By doing this, I can have separate dll folders for different project configurations if I want to and also the dll files are in a good place to check into source control as well.
As an example, I'm trying to add a reference to WatiN in Visual Studio 2008. I download WatiN and I have a folder on my desktop containing 5 files:
WatiN.Core.dll
WatiN.Core.xml
Interop.SHDocVw.dll
Microsoft.mshtml.dll
WatiN.Core.UnitTests.dll
WatiN.Core.UnitTests.dll.config
I can add my reference to WatiN.Core.dll and start coding in Visual Studio. But I have some questions:
Can I now delete the folder on my desktop? Were the files copied to the project bin?
What happens when I check my project into source code and another developer checks it out? Does he/she have to have the same folder on their desktop.
My thought was to create a lib folder in the project and reference the files in the lib folder. This folder will get added to source control so that everything should work for the next developer. But I have some questions about this solution:
Do I need all 6 of those files?
I believe the .config files have something to do with intellisense, but the project will build and run without them right?
How do I know what files to include apart from the WatiN.Core.dll. The project builds and runs with only WatiN.Core.dll and Interop.SHDocVw.dll. How am I meant to know what the dependencies are?
Any insight is much appreciated.
Adding a reference does just that. It adds a reference, so if the reference is to your desktop folder other developers will not be able to see the files. Also, if you delete the files you will have dangling references in your project. In general, don't reference files on your desktop.
Making a lib folder in the same source control tree as the project as you have suggested is a much better solution. Visual Studio will store the references as relative paths enabling other developers to compile the project.
You will have to study the documentation for the WatiN library to know which files are required by your application. You should not delete the .config file as it is not related to intellisense.
I would create a developement tree with all source files, library files, tools, docs, resources so that any developer can get a working project straight from source control without having to search for references.
Having referenced DLLs in a lib folder means that projectA is able to use version 1.0 of the DLL and projectB is able to user version 2.0 of the DLL.
When the solution builds it will get the DLLs from where they are referenced. If it cant find them the project wont build.
Have a look at the following articles.
http://www.codeplex.com/treesurgeon
As for which dlls you need to reference, you can go the way of only referencing what you need.
WATiN needs the WATiN.Core.dll and the Interop.SHDocVw.dll in order to run. As others have suggested, it's best to have a lib folder in your source control tree for external libraries so everyone can use relative references.
TreeSurgeon, mentioned above, is a good tool or you can at least use their folder structure as a model.
The Watin.Core.xml file should give you intellisense if you put it in the bin with the dll.
I believe you can only delete the folder if you are referencing the file directly from the bin folder (cut and pasted it there). If you are referencing the file from the folder than I believe you need to keep it there.
You may run into problems deleting the other files if the dll your referencing, references the classes in the other dll's.