Where to store component DLLs?

Question

I'm currently migrating a VB.NET website to a VB.NET Web Application. Previously I would store all the component DLLs (3rd party class libraries) in the bin folder and they would get compiled at run time. I've manually added the references to the DLLs in my new application, however is the bin folder the ideal place to store these additional DLLs? Is this considered best practice and will it interfere with the DLL generated by the application when I create a new build?

Sorry if this is quite a basic question, I'm new to the concept of Web Apps in Visual Studio.

Answer 1

No it will not interfere with the dlls generated by the application.

If these are dlls you use in a lot of your applications you may consider registering them in the GAC.

Having them in the bin makes for easy deployment (by simply copying the web app folder) and this may be your only option if you are in a shared hosting environment where you don't have access to install your dlls in the GAC

Answer 2

As a general rule, I never directly put anything in the bin folder. I always allow the build process to copy the dll's or other files to the bin folder.

If you add a reference, and make sure that "copy local" is set to true, then the dll will be copied during build. This has a number of advantages, particularly when using version control.

As for where you should put these files, I usually create a folder at the solution level and place the dll's there, then I add them as references from that location. This allows them to be checked into version control easily (and marked as read-only, as many version control systems do).

When checking files into version control in the bin folder, then you run into lots of problems. Another issue is when you need to "clean" the bin folder, having files in there can cause problems. You can always just delete all files in the bin folder if you use the method I have described.

An even better approach is to use NuGet packages. If the files you want are not part of an existing NuGet package, then you can create your own and run your own local NuGet Server.