Sharing binary folders in Visual Studio

Question

For a long time i have tried to work out the best way to access certain site files which i don't wish to be apart of a project or to ease integration with multiple developers (and talents, e.g. designers) on a single project.

A lot of sites i have created have had folders with large amounts of images and other binary files which i have not wanted to include in a visual studio project and/or source control mainly due to the constant updating of their contents. I have seen some people use virtual directories however there is no way to use virtual directories if you are using visual studio's built in web server.

As far as i see it, ideally, folders containing binaries could be located on a central server and mapped to a project. Alernatively i have considered creating separate sub-domains for each project with which all images / binaries can be refereced via, e.g. http://project.client.customer.com/images

Any thoughts?

Answer 1

Images and other binaries should be in source control just like your code files. Especially since they are changing often.

That said, there is absolutely no harm in setting up a different project that only contains your binary files; and having it on a different deployment schedule.

Answer 2

i have come across this article Some Techniques for Better Managing Files in Visual Studio from Microsoft.

Answer 3

They should really be source controlled like everything else. If you use Subversion you could have them stored in a different repository and included as an svn-external on your main project repository if you didn't want them cluttering up your main repo. I'm sure other source control solutions offer similar functionality.

Answer 4

You really ought to keep them in source control. If you're using Subversion, as Beepcake says, you can use svn:externals to share the files between different projects.

Alternatively, you could have a custom build action that fetches the latest copy of the shared files from wherever you keep them. We do this in a variety of ways -- either we issue an "svn checkout" for a subdirectory (but svn:externals would work for this), or we do a "wget ..." to grab the output from the last successful build of another project (we use TeamCity for continuous integration, and it makes "artifacts" available over HTTP).