Whilst re-compiling and re-deploying your entire .Net website application is the “safe” solution to avoid any nasty version conflicts etc its also slow (and a sledge-hammer to crack a nut).
If you are running a live website you often just want a quick patch to fix the issue at hand – often just a single assembly.
If you are lucky (like I was) you have a good build manager to do all this for you… but I have found that people are not always aware of the options available – they just use the Visual Studio GUI to re-compile the entire solution every time.
If you are using Visual Studio to do the build there is no requirement to re-build the entire solution (.sln) every time - you can just rebuild a project (.proj) within the solution so you get just the single assembly. Note that "Build" will only compile changes anyway, "rebuild" will re-compile everything whether it has changed or not.
It's worth moving away from using the GUI (if you haven't already) to using MSBuild.
MSBuild is a dark art to me but there is a lot of reference material out there (http://msdn.microsoft.com/en-us/library/ms171452.aspx , http://blogs.msdn.com/msbuild/ ).
There is also NANT, of course - http://nant.sourceforge.net/, http://social.msdn.microsoft.com/forums/en-US/msbuild/thread/994761a3-ea9d-40c7-8d4f-4c208b2023f6/ ,
Regardless of HOW you build you still need to ensure that you maintain the linkages between the different parts of you application.
There are a number of different ways of doing this to ensure that you maintain the linkages between assemblies.
Keeping a static version number
The “easiest way” is to just not change the assembly version number (AssemblyVersionInfo.cs) – to the rest of the site it still looks like the “same version”. You can change the AssemblyFileVersion if you want so the Operations people can distinguish between the two different version DLL’s on the server (assembly file version is that number you see when you look at the properties of a file in Window Explorer).
[assembly: AssemblyVersion("1.0.262.0")]
[assembly: AssemblyFileVersion("1.0.397.0")]
Using Publisher Policy Assembly Redirection
The better way is to use “policy redirection” i.e. use policy files to tell .Net to “give the application 1.1.1.2 even though it asked for 1.1.1.2”.
This is documented here - http://msdn.microsoft.com/en-us/library/7wd6ex19.aspx - but I have shown an example below of redirecting “all versions of ZZZ.Business.AdManager versions 1.0.*.* to version 1.0.262.0”.
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="ZZZ.Business.AdManager" publicKeyToken="6221fee78ae283c6" culture="neutral" />
<bindingRedirect oldVersion="1.0.0.0-1.0.65535.65535" newVersion="1.0.262.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Note that this can be done at different levels too – publisher policy for the assembly, application level and at machine level (machine.config).
There are some pre-requisites e.g. “strong names” but these are easily created as part of the assembly process and you need strong naming if you want to share stuff in the GAC anyway.
Further Information
.NET Framework Tutorials - Versioning Components
Managing Versions of an Application
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/managevers.asp
The Build Process
http://msdn.microsoft.com/en-us/library/ms998223.aspx
Simplifying Deployment and Solving DLL Hell with the .NET Framework
http://msdn.microsoft.com/en-us/library/ms973843.aspx
VS 2005 Web Deployment Projects
http://weblogs.asp.net/scottgu/archive/2005/11/06/429723.aspx
Web Deployment Tool (even better with IIS7!!!)
http://learn.iis.net/page.aspx/346/web-deployment-tool/
I hope this is information is useful to your build manager and that we will be able to transition to a more flexible deployment strategy in coming releases!
Comments