41

I want to have a library folder that stores all my dlls. What I'm currently doing is as suggested here. Have physical folder, create solution folder, copy the files.

If I'm using SVN, I'll have to use tortoise on the file explorer to add the library. Not sure if I'm going to have to do the same thing in TFS.

In vs 2010, is there any easier way to do this? I want to be able to just drag a dll into the library folder inside visual studio and have it physically put the dll in the folder.

Community
  • 1
  • 1
Shawn Mclean
  • 56,733
  • 95
  • 279
  • 406

1 Answers1

79

This is how I do it. Not sure if there is any other better way:

  1. Right-click on your solution from the Solution Explorer. Hover over "Add" and select "New Solution Folder". It's not really a folder and does not point to any Physical Folder. It's an abstract construct for grouping projects within a solution, but we'll use it for something else.
  2. Call it something like "Referenced Assemblies".
  3. Next, Right-click on your solution again and click on "Open Folder in Windows Explorer". In the windows explorer window that pops up add a new "Physical Folder" (this will be located right underneath the Solution's root folder).
  4. You can call it "Referenced Assemblies" so that the Solution Folder and Physical Folder share the same name so as to avoid confusion.
  5. Grab all those DLL's lurking everywhere (i.e. the AjaxControlToolkit.dll or the DocumentFormat.OpenXml.dll buried in program files) and copy (DO NOT DRAG - keep the originals where they are) them into the "Referenced Assemblies" folder in Windows Explorer (NOT IN THE SOLUTION).
  6. Now you can drag those copied dll's from the "Referenced Assemblies" Physical Folder in Windows Explorer into the "Referenced Assemblies" Solution Folder in Visual Studio's Solution Explorer.
  7. Go through each project in your solution and remove all references to the assemblies you will be referencing from the "Referenced Assemblies" folder.
  8. Add the references back in, but this time (under the project) right-click on "References", click "Add Reference...", select the "Browse" tab, click the folder icon with the green arrow (says "Up One Level" when hovering over it), double-click the "Reference Assemblies" folder, select all the dll's you wanna reference and click "OK".

You're done. Now that your solution knows of these dll's and where to find them, when you check in your code (via SVN, TFS, or whatever) it will push them up and copy them down for others to use.

If your using TortiseSVN you don't have to do anything if you're also using the AnkhSVN plug-in for Visual Studio. It studies your solution file (just like TFS does) to find files referenced by the solution. In this case it will pick up on the new dll's being referenced by the "Referenced Assemblies" Solution Folder and automatically add source-control tracking before committing them (that is if you commit your solution changes from the Solution Explorer in Visual Studio like I do).

Hope this helps.

MikeTeeVee
  • 18,543
  • 7
  • 76
  • 70
  • 3
    This is how I currently do mine too. 50 bucks they add a better way to do this feature in like vs2020... (x_x) – Shawn Mclean Oct 25 '11 at 01:17
  • 2
    Note that you can't simply drag folders into a solution folder. So you should create a tree structure (with sub solution folders) that reflects the file system folders. This is a bit uncomfortable, but that's a built in limitation of VS. – Ron Klein Mar 08 '12 at 11:56
  • 1
    @RonKlein Not sure what you mean. I never say to drag folders into the solution folder. My process works and it is probably the same method you use. – MikeTeeVee Mar 19 '12 at 20:18
  • @MikeTeeVee, what I meant is that this method works only for files. And of course, it's a VS limitation. If, for some reason, the external dll files have their own tree structure, then you can't drag and drop their sub folders. You should reflect their tree structure in (sub) solution folders. – Ron Klein Mar 20 '12 at 09:34
  • 2
    Another solution is to setup an internal NuGet server, and allow NuGet to manage the solution's depedencies, but that takes quite a bit more work, and is not as portable. If you know you will only be working internally, though, it is a good idea. – crush Apr 25 '14 at 13:00
  • 1
    @MikeTeeVee What's the purpose of the Referenced Assemblies solution folder in VS? If the References point to the physical folder, why create this extra solution folder in VS when it is just a view of the physical folder? Seems unnecessary to me. If you want to view the folder contents, just open windows explorer. – Fuyu Persimmon Jun 25 '14 at 01:32
  • Is it a good idea to include PDB files as well when available, to allow for debugging? – Erwin Mayer Jun 06 '15 at 09:43
  • I found this answer a bit more helpful. http://stackoverflow.com/a/18242604/2901207 – CularBytes Dec 19 '15 at 15:43
  • The problem with the internal NuGet server is that you create a dependency on it. Lets say you put this project in TFS and after a time period of lets say a year you have to maintain it on a clean machine where is your internal NuGet server then. You will really have to make sure that internal NuGet server has to be available in the same state/configuration as when you left the project in TFS, otherwise it won't work. – Herman Van Der Blom Feb 08 '18 at 09:11
  • @FuyuPersimmon I think it was so that the integrated source control would identify those files are needing to be tracked.. – StayOnTarget May 13 '19 at 19:01