In Renaming ASP.NET 2.0 Assemblies Redux, I detail a way to handle renaming ASP.NET 2.0 assemblies without aspnet_merge. The release of Visual Studio 2005 Web Deployment Projects (Beta Preview) pretty much obviates the need for my solution (unless you need exact control over your per-folder assembly names). If you haven’t heard about the new add-in (and aspnet_merge), read this Scott Guthrie post for an overview: VS 2005 Web Deployment Projects.
All in all, it seems to work well — thanks to the ASP.NET 2.0 team for getting this together so quickly. I did come across the following (very minor) issues:
- If I happen to click on the VS IDE while building the deployment project, I get a “Microsoft Visual Studio is Busy” warning in a notification icon ballon.
- It is cool that you can open the build deployment project without unloading the project (as you do for other project types); however, it doesn’t warn you if you edit the project file and (without saving) then change the properties. It does detect the problem when you try to save the project file, but this is a bit late.
Also, I was looking forward to the ability to replace sections of the Web.config, but found that I basically wanted to replace something in nearly every section. I ended up going back to what I used to do: have two config files stored in my development project: Web.config and Web.release.config. The former is used during development and I copy the latter for use in deployment. An easy way to do this with Web Deployment Projects is by editing the project file and using the MSBuild Copy task:
<Target Name="AfterBuild">
<Copy
SourceFiles="$(SourceWebPhysicalPath)\\Web.release.config"
DestinationFiles="$(OutputPath)\\Web.config"
/>
</Target>
The functionality provided in this addin resolves the issues I had with the new ASP.NET 2.0 deployment model. We get many more choices including the old-style single assembly. Yes, this is more complex than ASP.NET 1.1, but the greater flexibility and benefits of the new model make it worth it to me.