I’ve been a long time supporter of Visual Studio Web Deployment projects. Not because I built ASP.Net websites and wanted to compile them, but more because they held so much unadulterated power from the simplicity of just being an MSBUILD file inside your solution. With the launch of Visual Studio 2012 Microsoft has made the call to no longer support WDP moving forward. This made me sad; but I was just being naive. Visual Studio 2012’s Publishing profiles are even more powerful, and they bring all your old friends along for the ride.
Blinded by the light…
A couple of weeks ago I attempted to rally some troops to fight the good fight.
“… Who took my cheese?…”
- WDP Lovers everywhere
I’ve been using Web Deployment projects to power the Continuous Integration of every project that my work has built in the last 3 years. I work in an agency where we release up to 10 sites a month. This is a lot of projects. And they all rely on Visual Studio Web Deployment projects to be deployed reliably from day one.
The removal of Web Deployment projects from Visual Studio 2012 worried me. Not “ get your pitch forks” level of worry, but more a “wow what a real shame”.
This is where you may say:
“…Hey guy, why use WDP when Web Deploy has been around for years. I thought WDP were just for ASP.Net “website” n00bs living in the past?”
- Web Deploy user
You may wonder why I love Web Deployment Projects so much? Well its quite simple really;
They sit nicely inside your Visual Studio IDE and were easily saved your deployment config to your source control.
Web Deployment projects are really just MSBUILD files, and therefore you can do anything inside them using the already outlined build tasks.
<Target Name="BeforeBuild"> <!-- // MAGIC UNICORNS ARE BORN HERE!! --> </Target> <Target Name="BeforeMerge"> <!-- // MAGIC UNICORNS ARE BORN HERE!! --> </Target> <Target Name="AfterMerge"> <!-- // MAGIC UNICORNS ARE BORN HERE!! --> </Target> <Target Name="AfterBuild"> <!-- // MAGIC UNICORNS ARE BORN HERE!! --> </Target>
As they’re just MSBUILD they are supported nearly everywhere by everything, and can use all MSBUILD extensions inside them.
<!-- Import the oober cool MSBUILD community tasks from https://github.com/loresoft/msbuildtasks --> <Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" />
It’s also really easy to build different configurations for different environments simply through different Configuration Manager Solution profiles.
And you could script the entire deployment, including calling Web Deploy from inside the web deployment project, to avoid having configuration mixed into your build server’s config.
All of this is testable on the local dev machine.
But guess what?
I was worried about nothing. The new publishing profiles are really the exact same thing as Web Deployment projects, but actually more powerful.
It’s time to move on… Publishing Profiles are actually better
The new publishing profiles in Visual Studio allow us to do all of the above, without really giving up anything at all.
They site nicely inside the IDE and are easily saved to your source control:
Publishing profiles are really just MSBUILD files, and therefore you can do anything inside them you just by using the same build target names.
<!-- OMG WTF BBQ THESE STILL WORK INSIDE A PUBLISHING PROFILE PUBXML!!!-->
<TargetName="BeforeBuild">
<!--// MAGIC UNICORNS ARE _STILL_ BORN HERE!!-->
</Target>
<TargetName="BeforeMerge">
<!--// MAGIC UNICORNS ARE _STILL_ BORN HERE!!-->
</Target>
<TargetName="AfterMerge">
<!--// MAGIC UNICORNS ARE _STILL_ BORN HERE!!-->
</Target>
<TargetName="AfterBuild">
<!--// MAGIC UNICORNS ARE _STILL_ BORN HERE!!-->
</Target>
Because of the above, you can still user all your MSBUILD extensions.
<!-- Import the oober cool MSBUILD community tasks from https://github.com/loresoft/msbuildtasks --> <Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" />
And its still just as easy to build different configurations using the IDE and test locally.
You can also call these publishing profiles from the command line!
C:\Code\MyWebsite>msbuild MySolution.sln /p:DeployOnBuild=true;PublishProfile=Deploy-Production;
Awesome things that get to join the party
As I mentioned above, publishing profiles actually add more power to this story, as they have a number of features that Web Deployment Projects missed.
They have native IDE support for building your publishing settings.
These get saved into your profile without touching anything you’ve put inside your profile such as custom build targets.
You can leverage all of MS Deploy to plug in at any step of the deployment.
This allow you to do things like customise app_offline.htm files during deployment, and anything else you have in mind. Package a deployment package and check it into your source control? easy.
You can also run tiered web.config transforms
This allows you to run a transform for “debug” builds that maybe does things like turning custom errors pages off and then another transform for your “Staging” environment that sets your database connection strings up correctly. This is powerful. I used to have to do this level of granularity manually in an “AfterBuild” target in my web deployment projects. Now it’s there out of the box.
The future looks bright
If you were like me and were worried about Sayed’s post it’s time to calm down. There is no fire – in fact publishing profiles actually are more integrated, more powerful, and are going to be more widely used than web deployment projects ever were. This will mean great things for developers wanting to get into using Continuous Integration with ASP.Net as there will be lots of documentation floating around from different people’s take on what works for them.
If Continuous Integration and Deployment are your pot of gold, Publishing Profiles just might be the rainbow that’ll help lead you there. Well done Visual Studio team.