When adding either 3rd party libraries or internally developed ones to a C# project, I usually just add the reference in the Visual Studio solution browser. However, this creates an absolute path reference to the library. When another developer on a different computer checks out the code, they probably won't have those libraries in those exact folder locations.
Where do you put your 3rd party libraries? suggests that 3rd party libraries should be kept in a folder inside the solution folder (i.e. the repository folder). This makes sense to me. However, when I add the references they are still absolute path references. Changing C# .dll references from absolute to relative offers a solution to this, however, is manually editing the .csproj file really the way to go? I've read that it is not recommended to mess around with the .csproj file. Also, I see in the comments to that question that if your library is not above the project folder (so in my case I created a dependencies folder inside the project folder, not the solution folder), then VS should make the path reference relative by default but that did not happen in my case.
Then there is the question about internally developed libraries. In my case I have a utilities project that has functions I need to use across multiple solutions. I would prefer not to have to manually update the library in each project that relies on it. This is not a problem if I use absolute paths to the reference but then what happens with using version control? In the first question I linked to, one of the lower down answers suggests using a program called Sync Toy to make sure that the library gets copied into all the projects that reference it's dependencies folder. Is that a sensible way to go?
Lastly, and this last point may be too unrelated to fit in the same question, when I add the reference, but default it coies the library to the output directory on building. But that means when I deploy the project I have to copy all those additional dll files. Is there a way to avoid this and embed the library into the output .exe?
In the Project Designer, click the References tab. Click the Add button to open the Add Reference dialog box. In the Add Reference dialog box, select the tab indicating the type of component you want to reference. Select the components you want to reference, and then click OK.
If you're using Visual Basic, select the References page, and then click the Reference Paths button. In the Reference Paths dialog box, type the path of the folder that contains the item you want to reference in the Folder field, and then click the Add Folder button.
To add a reference in Visual Studio, right click the "references" folder > choose "add reference" and then "Browse" to you DLL.
When you add a reference through References > Add Reference > Browse > Browse… Visual Studio will save the relative path to the library in the .csproj
.
However, if you look at the reference properties in the Properties window Visual Studio will show you the absolute path to the library (I don't know why someone thought it would be a good idea to do it):
This has been tested in Visual Studio 2008 and 2015.
If you have a common library you need to share between solutions (not projects) I recommend, if possible, to create your own NuGet feed and leverage that.
You probably want a Remote Feed, not a Local Feed; there are many tools to create and maintain one (e.g. TeamCity).
The library is updated? Push it to your internal NuGet server and enjoy the updates.
when I add the reference, but default it coies the library to the output directory on building
Well, that's how it works in .NET.
that means when I deploy the project I have to copy all those additional dll files. Is there a way to avoid this and embed the library into the output .exe?
While merging everything is possible (check ILMerge), I don't recommend it, it's not worth the hassle, because:
If you have to manually copy things around to deploy, you're doing it wrong. You should create a script or an installer (depending on the project type and what you have to do) to move the deployed application around as a whole.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With