What tool to use to automate building & publishing content in VS2010?

I've done this exact thing just with MSBuild. The steps involved in my case were: TFS performed a build using a custom MSBuild project, not a solution file. Any CI build system would work, nothing special about TFS in this instance In the custom build project, in addition to building all the projects, I copied a bunch of web.

Config "template" files to a special folder under the $(OutDir) folder. These would end up in the build drop from TFS. In my case, the built in configuration file transformations were nowhere close to being sophisticated enough, but if that can work for you it is simpler by far The web.

Config files actually contained references to other config files, one for each configurable feature. This used a custom configuration provider. This technique would also work if you just had a single web.

Config file though I enabled automated deployment (Publish) from the command line, as a new MSBuild target in the same custom MSBuild project that was driving the build It was then easy to automate the Publish step in the main build to a VM or QA machine, as well as make it possible to manually deploy to other servers (eventually the staging servers) from the command line The web. Config templates had stuff like this: In the connection string: "Data Source=${SQLINSTANCE};Initial Catalog=${SQLDATABASENAME} It is significant that the delimiters for the replacable tokens is ${ } and not $( ), since MSBuild won't mess with the curly brackets In the Publish step, use an MSBuild property function to replace bits in the config files, the following is taken from MSDN's description of MSBuild inline tasks: UsingTask TaskName="ReplaceToken" TaskFactory="CodeTaskFactory" AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks. V4.0.

Dll"> $(PROGRAMFILES)\IIS\Microsoft Web Deploy\msdeploy -source:contentpath="$(_BuildDropFolder)" -dest:contentpath=\\$(_RemoteComputerName)\DropFolder.

I've done this exact thing just with MSBuild. The steps involved in my case were: TFS performed a build using a custom MSBuild project, not a solution file. Any CI build system would work, nothing special about TFS in this instance.In the custom build project, in addition to building all the projects, I copied a bunch of web.

Config "template" files to a special folder under the $(OutDir) folder. These would end up in the build drop from TFS.In my case, the built in configuration file transformations were nowhere close to being sophisticated enough, but if that can work for you it is simpler by far. The web.

Config files actually contained references to other config files, one for each configurable feature. This used a custom configuration provider. This technique would also work if you just had a single web.

Config file though. I enabled automated deployment (Publish) from the command line, as a new MSBuild target in the same custom MSBuild project that was driving the build. It was then easy to automate the Publish step in the main build to a VM or QA machine, as well as make it possible to manually deploy to other servers (eventually the staging servers) from the command line.

The web. Config templates had stuff like this: In the connection string: "Data Source=${SQLINSTANCE};Initial Catalog=${SQLDATABASENAME}..." It is significant that the delimiters for the replacable tokens is ${ } and not $( ), since MSBuild won't mess with the curly brackets. In the Publish step, use an MSBuild property function to replace bits in the config files, the following is taken from MSDN's description of MSBuild inline tasks: Then in your project, you can use this task with, This is really just a rough guide, all of the parameters to ReplaceToken were also configured in MSBuild item metadata, allowing options for which database, server, security, etc. , each of which could be specified individually.So, for each build/deployment, it would perform the build, copy the config templates, do string replacements on them, then automate the Package/Publish, which is the final bit to go over.

Your best bet is to start with this blog: http://vishaljoshi.blogspot.com/2009/02/web-packaging-creating-web-packages.html which explains a bit, and this answer, which contains likes to a bunch of other related StackOverflow posts MsBuild and MsDeploy with multiple environments, then search online with http://www.bing.com/search?q=msbuild+msdeploy+command+line&go=&form=QBLH&qs=n&sk= to dig deeper. I really hate to just dump you off to a search engine for this part of it, but I've found that there are so many different scenarios it is tough to single one out. About half of the top ten responses have insight on some valuable angle.

Reply with more info to help narrow down my response at this point. For my implementation, I called MSDeploy. Exe directly from MSBuild using an Exec task.

Some things to consider: How to deal with security on the various publish sites. I had to set up a mess of build service accounts, and always required passing the password on the msbuild command line. If you can get by with Windows auth like you suggest it will be a bit easier.

For services, I had to use PSExec to run installutil on the remote server There were some additional configuration items that I automated using PSExec calling appcmd on the remote server. It is easy to open up a remote share on the server and use a "net use" command to map and unmap it during the build, you may have some other preference. Performance is tough.

For larger sites it can run quite long doing it file by file. RoboCopy isn't any faster. I found using MSDeploy to package remotely (point to local drop as source, and remote share for the package source) was very fast to Rackspace.

You may need to first package to a zip file using one MSDeploy call, then push the package remotely using a second. Hope this gets you started. Please comment or supply more detail in your question if there is something I really missed or glossed over.

Response to comment: The "Publish" target is something along these lines, $(PROGRAMFILES)\IIS\Microsoft Web Deploy\msdeploy -source:contentpath="$(_BuildDropFolder)" -dest:contentpath=\\$(_RemoteComputerName)\DropFolder.

SpiderM9 - thanks for that post, thats very useful. Can you give me more information on what you did with this step: "4. I enabled automated deployment (Publish) from the command line, as a new MSBuild target in the same custom MSBuild project that was driving the build." – kaes Jun 8 at 15:23 With the web.

Config transformations, I think I can get that done with the rest of this. I'm not clear though on what modules I'm meant to work with to do the remote publishing. From the IDE its easy.

The IDE connects to the msdeploy. Axd page on the remote server (there's only one remote server in my scenario) and it publishes the website straight to it. Are you saying I can do that with MSDeploy via the command line?

– kaes Jun 8 at 15:24 yes, if you can publish from the IDE you can also use msdeploy from the command line, a snippet along the lines of what I've done has been added to the text above – Brian Kretzler Jun 9 at 1:11.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.