views:

832

answers:

2

Hello,

We have several c# projects, libraries and solutions (a few asp.net applications, a few class libraries, windows applications like windows services and winform apps. etc.) which most of them depends each others output dlls. Some of our projects are grouped into solutions and they use project dependency. But some projects are not. We are (unfortunately) using VSS to manage source. When referencing assemblies to a project sometimes i see refresh files stored in vss but the actual dll never comes when you initially get the latest version, sometimes just the assemblies but not vss managed, sometimes just the assemblies and they seem to be managed by vss. As you can guess it is a nightmare to manage these files for us, especially when publishing the web apps. we are never sure that teh latest verisons of the library dlls are being published. Can you advice any best practices about managing this complexity ? Any articles are welcome too. Should we keep all libraries in a network folder and use refresh files ? So every developer in the team should copy his output file to that network share ?

Thanks, Umut

+2  A: 

What I do to solve this is to drop a copy of the referenced DLLs in my web apps' bin directory, and include them as part of the project, saved in source safe.

That way, if the DLL is ever updated, it is as simple as Check Out - Overwrite - Check In, and all members on the team can have the latest file.

And, in addition, it makes deployment easy, as the files are included during a publish. Just set the build type to content.

John Gietzen
+1  A: 

The simplest and most manual approach would be to have some sort of documentation somewhere which delineates your web application and indicates what its dependecies are, the version of them, and their location in source-safe. Add that as part of a build script.

A harder and less manual approach would be to implement some form of build automation. I would suggest taking a good look at MSBuild (http://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx), which uses XML files as a sort of scripting language. Download the Community Tasks package (http://msbuildtasks.tigris.org/) as well. With those two tools you should be able to generate a MSBuild file which gets your various solutions from sourcesafe and then builds them (note that you can call a MSBuild file from an MSBuild file. Also note that a Visual Studio Solution file is a MSBuild file - you can have your MSBuild script just run the build that your developers have been creating in Visual Studio). Once that's done you can then deploy the result wherever you want.

John Christensen