My solution has 5 projects and tfs build is working fine. Issue I am having is when I set to deploy from tfs on successful build. Its looking for publish profile in wrong project rather than my startup project. Please Help.
ScreenShot
Update:- So I was able to eventually find what was causing the issue during my build and publish in tfs. Each of the projects that were added in my solution were web applications. And Each of the project had in .csproj file these settings <Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />
<Target Name="MvcBuildViews" AfterTargets="AfterBuild" Condition="'$(MvcBuildViews)'=='true'">
<AspNetCompiler VirtualPath="temp" PhysicalPath="$(WebProjectOutputDir)" />
</Target>. Once I have commented out these in my other applications, the tfs build/publish using my publish profile was not looking for config file that I mentioned in my publish profile. Thanks for your help Patrick.
Suggest you first manually remote to your build agent and double check if there are corresponding DEVAPP1DEBUG.pubxml file located at the path on the build agent.
According to your description, maybe there are something wrong in your build artifacts for deployment. Suggest you try this way, looking into the TFS options for Build Definitions and when you have to select a template for the definition, you can see two options Build and Deployment, try with the Deployment option :
and by default in the MSBuild Arguments the parameter is :/p:OutDir="$(build.binariesdirectory)\\"
In that folder you should have everything need for the deployment.
Related
I'm using Visual Studio 2017 and have a solution with several web projects and webjob projects.
There are some files that I want to include when running locally in the development environment that I want to exclude from being deployed as part of a web publishing package.
I'm attempting to use the process described here http://sedodream.com/2010/05/01/WebDeploymentToolMSDeployBuildPackageIncludingExtraFilesOrExcludingSpecificFiles.aspx and elsewhere, which is:
<ItemGroup>
<ExcludeFromPackageFiles Include="connectionstrings.config">
<FromTarget>Project</FromTarget>
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</ExcludeFromPackageFiles>
</ItemGroup>
This works perfectly for my web projects - meaning that when building the connectionstrings.config file is copied to my bin\ directory and not included as part of the web deployment package - whereas when implemented in my webjob projects the file is copied to my bin\ directory but also included in the deployment package.
In the msbuild output I see:
Copying file from "C:\Users\me\Documents\Projects\myapp\myapp\webjob1\connectionstrings.config" to "bin\ProdBuildCfg\connectionstrings.config".
which is what I want because it allows me to run/debug locally, and also:
Copying C:\Users\me\Documents\Projects\myapp\myapp\webjob1\bin\ProdBuildCfg\connectionstrings.config to obj\ProdBuildCfg\Package\PackageTmp\app_data\jobs\continuous\webjob1\connectionstrings.config.
which demonstrates the problem - connectionstrings.config is still being copied to the package directory for subsequent publishing/deployment.
The process described in the above article and others applies to web projects, and they indicate you should place the <ItemGroup> under the
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
line of the project file. Webjob projects don't include that line but rather have something resembling:
<Import Project="..\packages\Microsoft.Web.WebJobs.Publish.1.0.13\tools\webjobs.targets" Condition="Exists('..\packages\Microsoft.Web.WebJobs.Publish.1.0.13\tools\webjobs.targets')" />
I suspect the problem relates to targets - either my project file doesn't include the proper <Import Project="...*.targets')" /> line or I'm not at the right spot in the file.
Next I tried the method mentioned here How do I include webjob files while debugging locally but exclude when publishing a web package?:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<ExcludeFilesFromDeployment>connectionstrings.config</ExcludeFilesFromDeployment>
</PropertyGroup>
I have the connectionstrings.config Build Action set to None and Copy to output directory set to Always (my understanding is that action that results from the Copy to output directory setting is distinctly different from the actions associated with packaging/deployment). Same result. (I've ensured I'm in the right <PropertyGroup> for my build configuration.
Note: I'm deploying either by right-clicking the project in VS and selecting "Publish as Azure webjob" or using an msbuild command to publish like msbuild myproj.csproj /p:DeployOnBuild=true /p:Configuration=Release /p:PublishProfile="Prod" /p:VisualStudioVersion=15.0 /p:Password=
How do I include webjob files while debugging locally but exclude when publishing a web package?
To my knowledge, if you do not want to publish any file, you just need to set the file property to "copy to output directory as DO NOT COPY". This way when you will package the application that particular file will not be part of package and will never be on Azure.
Update:
Unfortunately that setting prevents the file from being copied to the
output directory which means I can’t run or debug locally.
When you debugging the project, you can set the "copy to output directory" as "Copy always". When you want to deploy the project, you can manually clean the build and change the value to DO NOT COPY.
If you do not want to do all those manually, I would like provide you a workaround, hope this can help you.
To accomplish this, unload your project. Then at the very end of the project , just before the end-tag, place below scripts:
<Target Name="ExcludeFileFromPackage" BeforeTargets="PipelineCopyAllFilesToOneFolderForMsdeploy">
<Message Text="Delete the connectionstrings.config from Obj folder to exculde this file in the package directory" />
<Delete Files="$(ProjectDir)obj\Release\Package\PackageTmp\connectionstrings.config" />
</Target>
With this target, VS/MSBuild will delete the connectionstrings.config from the obj folder before publish the project as package.
I'm looking for a command to run against the MSBuild.exe that just takes a MVC 4 project and publishes it to a given directory.
For example,
MSBuild <solution>/<project>.csproj -publish -output=c:/folder
This is obviously incorrect syntax. I'm trying to simplify my question.
This question talks of a build XML, but I'm not trying to do anything with that much detail.
I'm simply trying to do a deploy.
Further down in that question, someone speaks of "MSDeploy". I can look into that, but is it the only option? I do not have the ability to install web deploy on the server. In which case, all I really need to do is "Publish" and send the contents of the published project to a given directory on the server/file-system.
Does anyone have a one liner I can use?
Do I have to use MSDeploy?
Does MSDeploy require web deploy to be installed on the server?
Doesn't setting up web deploy on the server require setting up some ports, permissions, and installing some IIS add-ons?
I'd love to just execute something simple.
In VS 2012 (as well as the publish updates available in the Azure SDK for VS 2010) we have simplified command line publishing for web projects. We have done that by using Publish Profiles.
In VS for a web project you can create a publish profile using the publish dialog. When you create that profile it is automatically stored in your project under Properties\PublishProfiles. You can use the created profile to publish from the command line with a command line the following.
msbuild mysln.sln /p:DeployOnBuild=true /p:PublishProfile=<profile-name>
If you want to store the publish profile (.pubxml file) in some other location you can pass in the path to the PublishProfile.
Publish profiles are MSBuild files. If you need to customize the publish process you can do so directly inside of the .pubxml file.
If your end goal is to pass in properties from the command line. I would recommend the following. Create a sample publish profile in VS. Inspect that publish profile to determine what MSBuild properties you need to pass in on the command line. FYI not all publish method support command line publishing (i.e. FTP/FPSE).
FYI if you are building the .csproj/.vbproj instead of the .sln and you are using VS 2012 you should also pass in /p:VisualStudioVersion=11.0. For more details as to why see http://sedodream.com/2012/08/19/VisualStudioProjectCompatabilityAndVisualStudioVersion.aspx.
Create a build.xml file thats look like below
Start Visual Studio command prompt
Run msbuild build.xml
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0" DefaultTargets="Build">
<PropertyGroup>
<Build>$(MSBuildProjectDirectory)\Build</Build>
<ProjectFile>MyProject.csproj</ProjectFile>
<ProjectName>MyProjectNameInVisualStudio</ProjectName>
<CopyTo>$(MSBuildProjectDirectory)\CopyTo</CopyTo>
</PropertyGroup>
<Target Name="Build">
<RemoveDir Directories="$(Build)"/>
<MSBuild Projects="$(ProjectFile)" Properties="Configuration=Release;OutputPath=$(Build);OutDir=$(Build)/"></MSBuild>
<Exec Command="robocopy.exe $(Build)\_PublishedWebsites\$(ProjectName) $(CopyTo) /e /is
if %errorlevel% leq 4 exit 0 else exit %errorlevel%"/>
</Target>
</Project>
The command below works perfect:
msbuild Myproject.sln /t:Rebuild /p:outdir="c:\outproject\\" /p:Configuration=Release /p:Platform="Any CPU"
I found Sayed's answer was deploying the default configuration i.e. Debug. The configuration selected in the Publishing Profile seems to get ignored by MSBuild. Accordingly I changed the command to specify the correct configuration for the deployment...
msbuild mysln.sln /p:Configuration=[config-name] /p:DeployOnBuild=true /p:PublishProfile=[profile-name]
where config-name = Release or some other build configuration you've created
With web projects you need to build, as per above, but then you also need to package/copy. We use a file copy, rather than the "publish"...
Also; we use DEBUG/RELEASE to build the website; but then actual environments, ie "QA" or "PROD" to handle the web.config transforms.
So we build it initially with RELEASE, and then package it with QA - in the example below.
<PropertyGroup>
<SolutionName>XXX.Website</SolutionName>
<ProjectName>XXX.Website</ProjectName>
<IisFolderName>XXX</IisFolderName>
<SolutionConfiguration>QA</SolutionConfiguration> <!--Configuration will be set based on user selection-->
<SolutionDir>$(MSBuildThisFileDirectory)..</SolutionDir>
<OutputLocation>$(SolutionDir)\bin\</OutputLocation>
<WebServer>mywebserver.com</WebServer>
</PropertyGroup>
<Target Name="BuildPackage">
<MSBuild Projects="$(SolutionDir)\$(SolutionName).sln" ContinueOnError="false" Targets="Clean;Rebuild" Properties="Configuration=Release" />
<MSBuild Projects="$(SolutionDir)\$(ProjectName)\$(ProjectName).csproj" ContinueOnError="false" Targets="Package" Properties="Configuration=$(SolutionConfiguration);AutoParameterizationWebConfigConnectionStrings=False" />
</Target>
<Target Name="CopyOutput">
<ItemGroup>
<PackagedFiles Include="$(SolutionDir)\$(ProjectName)\obj\$(SolutionConfiguration)\Package\PackageTmp\**\*.*"/>
</ItemGroup>
<Copy SourceFiles="#(PackagedFiles)" DestinationFiles="#(PackagedFiles->'\\$(WebServer)\$(IisFolderName)\$(SolutionConfiguration)\%(RecursiveDir)%(Filename)%(Extension)')"/>
</Target>
So;
Setup your properties
Call the BuildPackage target
Call the CopyOutput target
And voila!
Has anyone had any success with running StyleCop from TeamCity?
I know StyleCop supports a command line mode, however i am not sure how this will integrate into the report output by TeamCity.
I've checked out this plugin found here: https://bitbucket.org/metaman/teamcitydotnetcontrib/src/753712db5df7/stylecop/
However could not get it running.
I am using TeamCity 6.5.1 (latest).
I don't know how familiar you are with MSBuild, but you should be able to add a new Build Step in TC 6 and above, and set MSBuild as the build runner, and point it to a .proj file which does something similar to the following:
<Target Name="StyleCop">
<!-- Create a collection of files to scan -->
<CreateItem Include="$(SourceFolder)\**\*.cs">
<Output TaskParameter="Include" ItemName="StyleCopFiles" />
</CreateItem>
<StyleCopTask
ProjectFullPath="$(MSBuildProjectFile)"
SourceFiles="#(StyleCopFiles)"
ForceFullAnalysis="true"
TreatErrorsAsWarnings="true"
OutputFile="StyleCopReport.xml"
CacheResults="true" />
<Xslt Inputs="StyleCopReport.xml"
RootTag="StyleCopViolations"
Xsl="tools\StyleCop\StyleCopReport.xsl"
Output="StyleCopReport.html" />
<XmlRead XPath="count(//Violation)" XmlFileName="StyleCopReport.xml">
<Output TaskParameter="Value" PropertyName="StyleCopViolations" />
</XmlRead>
<Error Condition="$(StyleCopViolations) > 0" Text="StyleCop found $(StyleCopViolations) broken rules!" />
</Target>
If you don't want to fail the build on a StyleCop error, then set the Error task to be Warning instead.
You'll also need to add the following to your .proj file:
<UsingTask TaskName="StyleCopTask" AssemblyFile="$(StyleCopTasksPath)\Microsoft.StyleCop.dll" />
Microsoft.StyleCop.dll is included in the StyleCop installation, and you'll need to set your paths appropriately.
To see the outputted StyleCop results in TeamCity, you will need to transform the .xml StyleCop report to HTML using an appropriate .xsl file (called StyleCopReport.xsl in the script above).
To display the HTML file in TeamCity, you'll need to create an artifact from this .html output, and then include that artifact in the build results.
The Continuous Integration in .NET book is a great resource.
Did you know that teamcity provides specific properties just from msbuild?
No need for the service messages, see:
http://confluence.jetbrains.net/display/TCD65/MSBuild+Service+Tasks
So you dont have to add a custom report page.
Use the build stats e.g.
<TeamCitySetStatus Status="$(AllPassed)" Text="Violations: $(StyleCopViolations)" />
you can then log the statistic too:
<TeamCityReportStatsValue Key="StyleCopViolations" Value="$(StyleCopViolations)" />
And then create a custom graph to display, and you already have the violations in your msbuild output.
edit main-config.xml and add:
<graph title="Style Violations" seriesTitle="Warning">
<valueType key="StyleCopViolations" title="Violations" buildTypeId="bt20"/>
</graph>
Where buildTypeId="bt20" bt20 is your style build.
I'm late to the show here but a very easy way to achieve this is to install the StyleCop.MSBuild NuGet package in any project which you want to analyse with StyleCop.
After installing the package, StyleCop analysis will run on every build you do, regardless of where or how it is invoked, e.g VS, command line, msbuild, psake, rake, fake, bake, nant, build server, etc. No special actions are required.
If you want the build to fail when StyleCop rules are broken you just need to add the following element to your project file under each appropriate build configuration, E.g.
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<StyleCopTreatErrorsAsWarnings>false</StyleCopTreatErrorsAsWarnings>
...
Again, this will work on every build, regardless of where and how it is invoked.
There's a (new?) third-party TeamCity plugin for StyleCop here, (though I haven't tried it yet).
UPDATE: as far as I can tell, the latest version only works with TeamCity 7 (or I did something wrong). Also, I have a very slow (virtual) build server, so even after the services were restarted, it took a while for the StyleCop runner to appear in the web interface.
Another stupid thing I did was not read the readme properly: you have to unzip the downloaded zip, and use the zip inside.
I also originally started with just a list of .cs files in the "Include" option (for the build step), but that didn't work; links to sln or csproj files do work though.
I am using the MSBuild runner in Team city to build and deploy my project to a staging environment. Everything works perfectly except for the fact that it keeps removing my repository folder located in the root of the project.
In Visual Studio 2010 there is a check box in the publish profile dialog that says "Leave extra files on destination (do not delete)"
Is there a way to accomplish the same thing with MSBuild?
<Target Name="Deploy" DependsOnTargets="Build;Test">
<MSBuild Projects="MyProject.sln" Properties="Configuration=$(Configuration); username=username; password=password; DeployOnBuild=True; DeployTarget=MSDeployPublish; MSDeployPublishMethod=WMSVC; MSDeployServiceUrl=https://DEVWEB01:8172/MsDeploy.axd; DeployIISAppPath=MyProject.$(Configuration); AllowUntrustedCertificate=True;"/>
</Target>
Found the answer!
All you need to do is add the following property to the Properties attribute:
SkipExtraFilesOnServer=True;
I am trying to configure TeamCity 5.0 to run "Publish" target on one of my projects.
When I load the solution in VS 2008 and click publish on the project the website is being build nicely - files on server appearing by themselves etc. Yet when I run the sln file via TeamCity Sln2008 runner the TeamCity returns:
[Project "Portal.csproj" (Publish target(s)):] Skipping unpublishable project.
Has anyone had the same problem?
Filip
You could create your own simple build file. For example:
<Project DefaultTargets="Build" ToolsVersion="3.5" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets"/>
<PropertyGroup>
<PackageFolder>C:\Builds\AppServer\Actual</PackageFolder>
</PropertyGroup>
<Target Name="Build" DependsOnTargets="BeforeBuild">
<MSBuild Projects="TeamWork-AppServer.sln"
Targets="Rebuild"
Properties="Configuration=Debug;OutDir=$(PackageFolder)\;"></MSBuild>
</Target>
</Project>
Or you can use VS 2008 Web Deployment Project. Here is a great turtorial.
If it is a WebProject you can use the Microsoft.WebApplication.targets. Unless you have installed the windows SDK on your build agent you will need to copy the targets file into your source control and reference it from your web project by adding:
<Import Project="{path to your tools}\Microsoft.WebApplication.targets" />
You can find the targets file here (depending on your os):
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v9.0\WebApplications
Now you just need to update your msbuild task to reference the right targets:
<MSBuild Projects="{path to your web project file}"
Targets="Build;ResolveReferences;_CopyWebApplication"
Properties="Configuration=Release;Architecture=Any;WebProjectOutputDir={your web root};OutDir={your web root}\bin\" />
Here is how I modified the .csproj file for an ASP.NET MVC project to deploy via TeamCity 5.1.2. In the .csproj file, replace the AfterBuild target with this XML (If there are already commands in your existing AfterBuild, you will have to merge them into these targets):
<PropertyGroup>
<DeployTarget>0</DeployTarget>
<PublishTarget>0</PublishTarget>
<PublishFolder>..\Deployment\YourWebsiteName</PublishFolder>
</PropertyGroup>
<Target Name="PublishProperties">
<CreateProperty Value="$(PublishFolder)">
<Output TaskParameter="Value" PropertyName="WebProjectOutputDir"/>
</CreateProperty>
<CreateProperty Value="$(PublishFolder)\bin\">
<Output TaskParameter="Value" PropertyName="OutDir"/>
</CreateProperty>
</Target>
<Target Name="WebPublish" DependsOnTargets="BeforeBuild;PublishProperties">
<RemoveDir Directories="$(PublishFolder)"
ContinueOnError="true" />
<CallTarget Targets="ResolveReferences;_CopyWebApplication" />
</Target>
<Target Name="Deploy" DependsOnTargets="WebPublish">
<CreateProperty Value="Path\To\Your\Server" Condition="$(DeployFolder) == ''">
<Output TaskParameter="Value" PropertyName="DeployFolder"/>
</CreateProperty>
<RemoveDir Directories="$(DeployFolder)" Condition="$(CleanDeploy) == 1" />
<ItemGroup>
<DeploymentFiles Include="$(PublishFolder)\**\*.*" />
</ItemGroup>
<Copy SourceFiles="#(DeploymentFiles)"
DestinationFolder="$(DeployFolder)\%(RecursiveDir)" />
</Target>
<Target Name="AfterBuild">
<CallTarget Targets="WebPublish" Condition="$(PublishTarget) == 1" />
<CallTarget Targets="Deploy" Condition="$(DeployTarget) == 1" />
</Target>
This script uses the $(PublishTarget) and $(DeployTarget) properties to trigger additional steps after your project is built. The PropertyGroup at the beginning sets the default values to 0, so the extra targets are not run. You can override the default in TeamCity by going to the Properties and Environment Variables page of your build configuration and adding System Properties names "PublishTarget" and "DeployTarget" and setting their value to 1.
The Publish target contains most of the magic. This makes a call to the Visual Studio _CopyWebApplication target to output the website to the PublishFolder. By default the publish folder is "..\Deployment\YourWebsiteName" relative to the project file, but this can also be overridden with a System Property. The Deploy target takes the files output by the Publish target and copies them to the DeployFolder. DeployFolder can be set with a System Property in TeamCity or you can replace the "Path\To\Your\Server" path in the Deploy target.
You could also skip the extra Deploy step by simply setting the PublishFolder to whatever your deployment destination is. This script depends on the "Microsoft.WebApplication.Build.Tasks.Dll" and "Microsoft.WebApplication.targets" files installed by Visual Studio, but you can simply copy the files from your developer workstation to the build server. The default location is "C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications".
I have this same problem, here's what I've tried:
I have a solution file in Visual Studio 2010, committed to a Mercurial repository.
I have setup an FTP server for the root directory of the site to publish to, and publishing from within Visual Studio 2010 locally works nicely, it connects and uploads everything as expected, and the website works.
Now, I wanted to automate this on every push to the central Mercurial repository, and since I'm using TeamCity, I discovered that the field to specify the Target of the build, usually "Rebuild" can also take "Publish", so I specified "Rebuild;Publish", as per the documentation and help.
I have verified that after publishing in Visual Studio, and committing new files, a file named ProjectName.Publish.xml is accompanying my ProjectName.csproj file, and this file is pulled down into the server directory when TeamCity builds.
Yet, no publishing is done, and when I check the build log, it says:
[19:01:02]: [Project "Test.sln" (Rebuild;Publish target(s)):] Project "Test.UI.Web.csproj" (Publish target(s)):
[19:01:02]: [Project "Test.UI.Web.csproj" (Publish target(s)):] Skipping unpublishable project.
Exactly as the question here says.
Note that this is a development site, publishing just so that we can let more people test changes, so don't get into a discussion of whether this is actually a good idea or not.
Note: I do not care in which way the files are published, I just need the single TeamCity build-step to actually do it, so if anyone got a MSBuild-like solution that just sidesteps TeamCity, then I would be satisfied
Have you tried to execute Visual Studio directly, rather than relying on MSBuild to publish the project directly. MSBuild can't execute certain kinds of projects. I had a similar problem with getting MSI's built from within Team City.
I'm taking a guess at the exact commandline settings to this, since I don't know your exact setup.
<PropertyGroup>
<buildconfiguration>Release</buildconfiguration>
<DevEnv>C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\devenv.com</DevEnv>
</PropertyGroup>
<Exec Command="%22$(DevEnv)%22 /build $(buildconfiguration) $(teamcity_build_checkoutDir)\Test.sln /project Test.UI.Web.csproj"/>
If you're using the Team City solution runner as your build runner, you'll have to switch to MSBuild.
If you want to stay with the Team City runner, you could always try adding a project to your solution that will be the last one built, (or do it on the project that currently gets built last), and do the spawning trick as a post-build command line on the project.
Can TeamCity publish a Web project using the sln2008 build runner
Can TeamCity publish a Web project using the sln2008 build runner?
What type of project are you trying to publish?
http://social.msdn.microsoft.com/forums/en-US/msbuild/thread/7ec0d942-6354-41c3-9c97-7e7d1f461c29
Taken from above link:
What I discovered is that "Shared-addins" are not publishable
and are distinct and different from document and application level
VSTO addins, which are deployable.
When I rebuilt my application as an application level
VSTO addin, the publish option was available.
http://www.automise.com/Default.aspx?tabid=53&aft=9813
Taken from above link:
Assuming you're using Visual Studio 2008, we're unable to execute the web site
publish feature from FinalBuilder as it's partially implemented by the VS IDE.
You'll need to use to the MSBuild action to compile the application and then
use one of the other actions (FTP, File Copy, etc) in FinalBuilder to perform
the deployment. Visual Studio 2010 has fixed this problem by performing the
entire publish using MSBuild, see this post for more info:
http://www.finalbuilder.com/forums....&afv=topic
Two threads that might help
http://devnet.jetbrains.net/thread/280420;jsessionid=5E8948AE810FFFF251996D85E7EB3FE3
Visual Studio. Publish project from command line
For anyone using Web Application Projects in VS2010, I managed to get TeamCity to package the deliverables and then Web Deploy the package after successfully building the solution.
With a little tweaking, this had the same effect as hitting the 'Publish' button in VS.
My solution has a handful of projects, 1 of which is an ASP.NET MVC Web Application project. I build the solution, package the web app project, and msdeploy the package in 3 steps. I haven't figured out a (better|shorter|simpler|more elegant) way to do this.
I don't have VS installed on my TeamCity server, so I needed to grab both C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\Web and C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\Web Applications and put them both in the same spot on the TeamCity server (the second depends on the first). If you're working w/x64 machines, I'd grab them from both Program Files (x86) and Program Files. You also need to have Web Deploy installed on your machine and (I believe) IIS Management Service (i.e., something listening on https://yourservername:8172/MsDeploy.axd)
There are 3 build steps:
Visusal Studio (sln), Target=Rebuild, Configuration=Debug
MSBuild WebProject.csproj, Targets=Package Commandline=/p:PackageLocation=%teamcity.build.checkoutDir%\Debug.zip /p:Configuration=Debug
Commandline, Executable=%teamcity.build.checkoutDir%\Debug.deploy.cmd, Parameters=
/Y "-setParam:'IIS Web Application Name'='Default Web Site/PreCreatedAppInIis'"
In that last step, 'IIS Web Application Name' is an actual parameter name, don't change it. It's value can either be something like 'Default Web Site' or whatever you named your website in IIS and/or it can be an IIS application path below it. If the application doesn't exist, you may run into errors about the app pool not being configured correctly to host the application. Rather than investigate it, I just created an application in the appropriate app pool. In my case, I'm targeting ASP.NET 4.0 x64 where the default app pool is ASP.NET 2.0 x64.