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.
Related
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.
How can we set up the PATH environment variable in Visual Studio 2010 for the entire solution/project?
When I want to refer to a reference .dll, it has worked for me to set up a Solution Explorer level folder, and add the DLL file to that folder. Then in the filesystem, I add a matching folder (since the Solution folder is logical and not a real folder) at the solution level. There I put the physical DLL file, and if you are using source control, check-in that directory.
Once that's all done, for any project that needs to reference that DLL file, I can browse to it on the Solution level, add the reference, and make sure that the properties are set to 'Copy Local,' so that the DLL file shows in the appropriate /bin folder.
I would try something like that to get your dependencies better organized.
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.
This has to do with source control, I'm using VSS and the Visual Studio 2008 plugin. When the DLL of a referenced project gets included in a project (and checked into VSS), on the next build it will fail because those files aren't checked out as part of the build process and will be read only.
I could exclude the entire bin folder and all dlls, but that is where I put my static dlls (ie. the ones that aren't rebuilt as part of the solution) and interestingly, Visual Studio treats dlls other than outputs of other products as excluded files just fine.
In VS2005, the VSS plug in didn't automatically add the output of referenced projects as files pending check in, but in VS2008, it does.
Anyone run into this issue or find a work around?
It's better to not check in the bin folders at all. Move the dependencies to a common lib folder, and reference them from there. That will make sure they're copied into the bin folder. You can then explicitly check in this lib folder.
Other files/folders to avoid checking are the obj directory and the ncb file. I'm not sure how "smart" the VSS integration is in this case.