(UPDATE: See other Tiny Happy Features)
At some point soon lots of people are going to start writing these epic blog posts about Visual Studio 2012. They will include LOTS of screenshots (some good and some bad), some small code samples and minimal context. I can't speak for other teams; I can only talk about what we worked on. The <AngleBrackets/> folks in Azure Platform and Tools (ASP.NET, IIS, WCF, EF, Azure much and more) have been putting a lot of work into what I sometimes call "Death by a Thousand Tiny Cuts." It's the little irritants that are as frustrating (or more so) as the big missing features.
Rather than a giant super post (although I'll do that at some point) I thought I'd showcase some Tiny Happy Features that the team worked on just because it made life better. Some are large some are small, but all are tiny happy features.
Visual Studio added web.config transforms a while back so you can have a Web.config along with a Web.debug.config with the changes you want for debug time, and web.release.config for release time. You can add the free SlowCheetah add-on and get transform support for all your config files, not just web.config.
However, things fell down because Web Deploy and Visual Studio didn't have a way to easily represent Dev, Testing, Staging, Production, Whatever. You could have build configurations but they didn't relate to deployments, which doesn't reflect a developer's reality.
_thumb.png "Visual Studio 2012 adds deployment config transforms")
You can rename a profile whatever you like by changing the name. Here I've named my publish profile "Production." There's the coolest part.
I can make a Web.config file with the same name as my Publish Profile and that transform will be run after the build transform.
Even better you can right click on a Transform now and select Preview Transform and see not only the results, but a Diff of the results.
See right there, and in the large image above? It says "Transformed Web.config ( transforms applied: Web.Release.config, Web.Production.config)." Build transforms happen first, then Publish Transforms. Right now you need to create the file with the same name yourself but we'll be adding tooling for this.
This means I can do things in Web.debug.config like changing compilation options while Web.production.config is for changing connection strings, setting log levels, and adding specific Production settings.
If you have a untrusted certificate on the deployment server you haven't added to your local certs you'll need to add AllowUntrustedCertificate=true as an acknowledgement.
I just make a
Then I can just do
or
I've found these outwardly small but impactful changes have made it a lot easier for me to deploy sites. Deployment shouldn't be hard. I stand by my original statement: If you are using XCopy (or Windows Explorer or FileZilla) to deploy your website, you're doing it wrong.
If you are using Web Sites rather than Web Products, head over to the Web Team blog (and subscribe, too) and add your voice to the comments around our teams' plans regarding Website projects and Web Deployment Projects.
© 2012 Scott Hanselman. All rights reserved.
At some point soon lots of people are going to start writing these epic blog posts about Visual Studio 2012. They will include LOTS of screenshots (some good and some bad), some small code samples and minimal context. I can't speak for other teams; I can only talk about what we worked on. The <AngleBrackets/> folks in Azure Platform and Tools (ASP.NET, IIS, WCF, EF, Azure much and more) have been putting a lot of work into what I sometimes call "Death by a Thousand Tiny Cuts." It's the little irritants that are as frustrating (or more so) as the big missing features.Rather than a giant super post (although I'll do that at some point) I thought I'd showcase some Tiny Happy Features that the team worked on just because it made life better. Some are large some are small, but all are tiny happy features.
Publishing and Deployment Improvements
Visual Studio 2012 has a number of subtle but significant improvements to publishing. Of course you likely know you can push code to Azure or AppHarbor using Git. You can publish your web app with Web Deploy which I demonstrated at Mix in my talk Web Deployment Made Awesome: If You're Using XCopy, You're Doing It Wrong. You can see a quick closed-captioned video I did of Web Deployment to Azure in just 4 minutes over here.Visual Studio added web.config transforms a while back so you can have a Web.config along with a Web.debug.config with the changes you want for debug time, and web.release.config for release time. You can add the free SlowCheetah add-on and get transform support for all your config files, not just web.config.
However, things fell down because Web Deploy and Visual Studio didn't have a way to easily represent Dev, Testing, Staging, Production, Whatever. You could have build configurations but they didn't relate to deployments, which doesn't reflect a developer's reality.
Publishing with Environment-specific Configurations
Publish Profiles are either created manually, or now in VS2012 downloaded as .publishsettings from your host and imported into Visual Studio. In Visual Studio 2012 publish profiles are stored along with your code in the Properties folder so they can be checked in and used by others._2.png "Visual Studio 2012 adds deployment config transforms")
You can rename a profile whatever you like by changing the name. Here I've named my publish profile "Production." There's the coolest part.
I can make a Web.config file with the same name as my Publish Profile and that transform will be run after the build transform.
Even better you can right click on a Transform now and select Preview Transform and see not only the results, but a Diff of the results.
See right there, and in the large image above? It says "Transformed Web.config ( transforms applied: Web.Release.config, Web.Production.config)." Build transforms happen first, then Publish Transforms. Right now you need to create the file with the same name yourself but we'll be adding tooling for this.
This means I can do things in Web.debug.config like changing compilation options while Web.production.config is for changing connection strings, setting log levels, and adding specific Production settings.
Deploying from the Command Line
Deploying your web application from the command line has long been possible but it's been a pretty obscure and frustrating affair. Now that the Publish Profiles can live with the project and Web.config transforms can be chained in you can publish from the command line much easier.msbuild MySolution.sln /p:DeployOnBuild=true;PublishProfile=Production;Password=poo If you have a untrusted certificate on the deployment server you haven't added to your local certs you'll need to add AllowUntrustedCertificate=true as an acknowledgement.
I just make a
Deploy.bat that looks like this with a %1 for the Profile Name.msbuild MySolution.sln /p:DeployOnBuild=true;PublishProfile=%1;AllowUntrustedCertificate=true;Password=poo Then I can just do
Deploy Production or
Deploy Staging I've found these outwardly small but impactful changes have made it a lot easier for me to deploy sites. Deployment shouldn't be hard. I stand by my original statement: If you are using XCopy (or Windows Explorer or FileZilla) to deploy your website, you're doing it wrong.
If you are using Web Sites rather than Web Products, head over to the Web Team blog (and subscribe, too) and add your voice to the comments around our teams' plans regarding Website projects and Web Deployment Projects.
© 2012 Scott Hanselman. All rights reserved.
DIGITAL JUICE
No comments:
Post a Comment
Thank's!