Question: Fast question
=============

How to correctly add a reference to an external / third-party .NET DLL (which is not a NuGet package and not in GAC) and force it to be shipped as a part of solution (which is under version control) in Visual Studio?

Long story
==========

I have a Visual Studio 2013 solution, which contains a couple of .NET projects. The solution is under source control. There is a lot of installed NuGet packages that are used by the projects, of course. But one of the projects need to reference an external / third-party .NET DLL that is not available as a NuGet package and doesn't reside in GAC. If I just add a reference to that DLL in the project, it will work fine for the moment. But after I check-in a changeset with such modification, anyone who will get the latest version of the solution will encounter a problem with building it, because the one does not have the referenced .NET DLL on his machine.

Answer: 
I see two possible solutions to your problem 

1. You can add the dll on the TFS. Create a folder under your solution called lib, for example and put your dll in there. Then reference the dll from that folder. When you check the changes in , include the lib folder with the dll. Once someone else will get latest, they will get both your changes and the new dll. Do note that dlls referenced under the solution's folder use a relative path, so anyone else who has that folder and the dll in the solution's folder won't need to do anything else
2. Make a nuget package with that dll and host it on your very own nuget feed. You can get a feed and host it on iis on a dedicated machine or you can use a network share :). Nuget works with "folder sources" too. The Nuget feed is just a fancy ui over a folder repository. This adds the advantage taht you won't have dlls under source control

Good luck
You may consider checking-in the external DLL in the source control as well. Create an "Externals" folder within the project folder and place external DLLs there. Use this path to reference the external DLL. This should work with other developers as well as when they checkout they will have the DLL and proper relative path in csproj.