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.
Related
Currently through Azure Devops, I'm setting up a .Net Desktop type with pipe-line that includes assembly libraries. In my understanding this should've work if the scenario was TFS is on-premise and I can just install any 3rd party non-nuget libraries in that server and make the build work. Right now I was able to make this work by literally copying the .dlls but I felt its more of a hack than actually letting the build know that I'm referencing assembly / non-nuget package libraries.
I'm pretty sure i've missed something, is there a way to properly set this up?
Even though it's not a recommend way, but you could check in these libraries/dlls in source control. TFS could download them from server to your build agent and refer them.
First, make sure your local build is successful and if just the TFS build is failing then it is usually due to dll reference path issue. Make sure that the Dll is referenced as a relative path in the project file (.csproj).
To add a relative reference in a separate directory, such as C:\tfs_get\Sources\assembly\abc.dll, do the following:
Add the reference in Visual Studio by right clicking the project in Solution Explorer and selecting Add Reference.
Find the *.csproj where this reference exist and open it in a text editor. Lets say your .csproj location is c:\tfs_get\sources\myfolder\myproject\myproj.csproj
Edit the < HintPath > to be equal to
..\\..\assembly\abc.dll
This build will work properly with the assumption that the folders ( assembly, myfolder) under the sources folder exist in TFS.
Update
Have a folder named "libs", or "libraries", for example, that contains all the assemblies required by your projects to compile and run.
Reference these assembly by right click the reference folder of project and browser to these assemblies files.
For build, in Source Settings (XAML, Build Agent Folder)/Repository, keep the similar structure.
More details please take a look at this similar question : How to properly check in DLLs/assemblies to TFS/Visual Studio Team Services (was VSO)
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.
I have about 15 projects in a solution, and all of them have some broken third-party dll references. How do I configure VS to look for dlls in one specific directory? I am trying to compile and link my project, but it doesn't work because projects have broken references to existing third-party dlls. My solution consists of C# class library projects and an ASP.NET web site.
If they are project references (and they probably should be), you should not need to (unles you have moved the projects)
Otherwise, create a third-party Lib folder (under source control) at the solution root folder, place your third-party DLLs in it and reference from there.
If you need to fix up references, download and install VSCommands 2010 which has a very useful copy and paste references feature (among others). [Fix up for one project, and then simply copy and paste to other projects. Failing that, you would need to manually edit the .proj files, using Powershell for instance.]
You go from one project to the other and update the references to point to the new location.
If this is a third party DLL, you can record a macro the first time you do this and replay it for each project.
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.
This is a problem that has been eating at me for a while, and I just haven't found a good solution (no pun intended) for it.
I'm using Visual Studio 2010 with Subversion and Ankhsvn. It works very well, however, my biggest problem with it is that it only retrieves and manages files that are "included in the project". This is great in many situations, but kind of sucks when you want a folder with objects that you want to include in the solution, but do not want to have in the project itself (in this case a web project).
In this case, I want to include some 3rd party DLL's into source control (so they can be kept up to date when syncronizing with version control). I don't want the developers to have to install the 3rd party dll's seperately. What normally happens is that you reference the DLL's from some other location and they get copied into your bin folder at compile time.
I do not wish to include them in the project because i don't wan them copied to the web server when I publish the site (other than via the bin directory where they should be). I thought of creating a seperate project for these, but that would create a useless dll with no purpose that would then get copied to the bin folder because it's referenced.
I've also tried to check them in from the bin folder, but this has caused a number of problems where files did not syncronize prolerly, with subversion saying things about an already version folder being present etc.. This seems to be a subversion or ankhsvn problem rather than a visual studio one. As such, i try to keep the bin folder untouched by version control.
How have you solved this problem in your projects?
This is how we do it in our project.
We have a SourceCode folder which has the subfolders for the projects which contain the code.
Additionally this has a folder called Library which has the correct version of any 3rd party dll's that we use. This folder in in version control and hence everyone always has the correct version of the 3rd party dll's
All references in the projects to 3rd party dll's are relative from this Library folder.
Since everyone has the SourceCode folder on their machine, it works fine with no issues.
EDIT:
Added image of Solution Folder with library contents to it