Build target in the Publish Profile is not executing even if the Publish is successful - visual-studio

I have a publish profile Staging.pubxml created for a console project (.NET Core 2.1), as follows:
<?xml version="1.0" encoding="utf-8"?>
<!--
https://go.microsoft.com/fwlink/?LinkID=208121.
-->
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<PublishProtocol>FileSystem</PublishProtocol>
<Configuration>Staging</Configuration>
<Platform>Any CPU</Platform>
<TargetFramework>netcoreapp2.1</TargetFramework>
<PublishDir>bin\Release\netcoreapp2.1\publish\</PublishDir>
<SelfContained>false</SelfContained>
<_IsPortable>true</_IsPortable>
</PropertyGroup>
<Target Name="CustomActionsAfterPublish" AfterTargets="AfterPublish">
<Message Text="First occurrence" Importance="high" />
</Target>
</Project>
When I publish it (via VS2019); publish completes successfully. Yet I'am not seeing the text: First occurrence in the output window.
In VS, MSBuild output verbosity is set to Diagnostic.
Am I doing this wrong?

Am I doing this wrong?
1.Hi friend, the .pubxml file is not a good place to define custom Target.
According to your target name, you want to run the target after build target. For this situation: always we define the custom target in project file. Please try right-click your project and choose edit xxx.csproj, and add the target into it. Then reload the project and publish, then you can find the First occurrence message in the build output.
And after my test, in.csproj file, the target can't be named AfterBuild, you can change it to:
<Target Name="CustomTargetName" AfterTargets="build">
<Message Text="First occurrence" Importance="high" />
</Target>
2.Also, the way you use can work in VS2019 though we don't suggest adding it in .pubxml. But it indeed works. For the reason why you can't get the message in output window, please check if the Staging.pubxml is really called during the publish process.
(Change the value of the PublishDir to another folder, and publish it again, check if the project is published to new directory, then you'll find if the xxx.pubxml is used)
Update:
According to your .pubxml file, your project is a .net core console app instead of a asp.net core web app. This makes the difference!
I test it in both VS2017 and VS2019, and find the target works well in asp.net web app but not .net core console one. I believe for those non-web app, this kind of after publish target may not be supported.
And please check these two official documents I found:
Asp.net core: Run a target before or after publishing
.net core: Deploy .net core apps with VS
I can't find any custom-target-related info in the .net core document. So I'm afraid it might be not supported by design.
Update2:
Actually your original need is to add CopyFiles target to publish process. So I assume what you really want is to copy sth to Publish Folder after Publish process or copy sth from Publish Folder to target folder.
Though the after publish target is not supported in .net core console apps. We have corresponding workarounds:
To copy sth to Publish Folder after Publish:
For this situation, you can add a after build target to copy the files to Publish folder before publish process. I think it works for this situation:
<Target Name="CustomTarget" AfterTargets="build">
<ItemGroup>
<MySourceFiles Include="xxx\pathToTheFolderWhereYourFilesAre\*.*"/>
</ItemGroup>
<Copy
SourceFiles="#(MySourceFiles)"
DestinationFolder="$(ProjectDir)bin\Release\netcoreapp2.1\publish\"
/>
</Target>
To copy sth from Publish Folder to target folder:
For .net core console app, actually the so-called publish process is to copy files from obj folder to publish folder. See this screenShot:
Go Tools=>Options=>Project and Solutions=>Build and Run to change the build output verbosity to Detailed and you can see details in build and publish process in VS.
That's why I suggest you can Go Project=>Properties=>build events=>post-build events to use a xcopy command to copy the files to your destination folder.(Or you can use a script like above, remember to change the source path and destination path). When we want to copy the files in publish folder, actually we're trying to copy the files from obj folder. So do something after build process is enough! Not need to do it after publish process.

Related

How do I include webjob files while debugging locally but exclude when publishing a web package?

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.

Using MSBuild.exe to "Publish" a ASP.NET MVC 4 project with the cmd line

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!

SlowCheetah executes after post-build events

I use SlowCheetah to transform my app.configs. I have a multi-project solution where one of the projects executes a post-build event where the output of the bin is copied elsewhere. I've found that SlowCheetah does it's transforms after the post-build event, so the app.config I'm copying is the pre-transformed version.
Does anyone have a suggestion of how I can execute my copy after the SlowCheetah transforms? Is this going to require that I write a custom build task?
If you are using msbuild 4.0 for building your projects - you can hook to slowcheetah targets with new AfterTargets BeforeTargets attributes.
I dont know what exactly target name you want to hook after but this code could gave you base concept how to do this
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Some_Target_Name" AfterTargets="TransformAllFiles" >
<Message Text="= Script here will run after SlowCheetah TransformAllFiles ="/>
</Target>
<Project>
Edited: I installed SlowCheetah and found that AfterTargets attribute should be "TransformAllFiles".
Just set up your target dependency AfterTargets="TransformAllFiles"
Alexey's answer leads to the correct solution but here it is in full:
Right-click your project and select Unload Project
Now right-click the project and select Edit [your project name].csproj
Scroll to the bottom and uncomment the target named AfterBuild and add this attribute AfterTargets="TransformAllFiles"
Move your post build actions into this target using the Exec command:
An example:
<Target Name="AfterBuild" AfterTargets="TransformAllFiles">
<Exec Command="ECHO Hello PostBuild World!" />
</Target>
I have bumped into this problem too... decided to update to latest version of SlowCheetah (current 2.5.8), and this problem appears to have been fixed! No more problems using post-build events to deploy a project with transformed XML!
After the NuGet package upgrade process, I had a strange issue, though... transforms were no longer happening. Editing the project like Naeem Sarfraz suggested, I have found that the SlowCheetah's PropertyGroup section was placed at the end of the .csproj.
It was just a matter of moving it to the top, near the other PropertyGroup sections, and now it works like a charm!
If you need to copy/move other .config files (other than web.config) around after the build before publishing here is how it can be done with Visual Studio 2013 (I didn't test it on earlier versions). This section can be added at the end of the .csproj file right before the closing tag </Project> and it'll be fired just before MSDeploy starts the Publishing process.
<Target Name="MoveConfigFile" BeforeTargets="MSDeployPublish">
<Move
SourceFiles="$(IntermediateOutputPath)Package\PackageTmp\ThirdPartyApp.config"
DestinationFolder="$(IntermediateOutputPath)Package\PackageTmp\bin"
OverwriteReadOnlyFiles="true"
/>
</Target>
The company I work for purchased a third party product that needs to have a .config files in the bin folder along with its assembly in order to work.
At the same time we need to process the product's .config file and be able to move it to the bin folder after transformations.
The $(IntermediateOutputPath)Package\PackageTmp folder contains the whole application that will be copied over the target server.

MVC3 project build fails because of web.config in obj folder

I have <MvcBuildViews>true</MvcBuildViews> setup in my project files.
Now when I do deployment the first time I get files in obj\release\package\packagetmp. Every subsequent build after this results in a faild build.
Web -> C:\Projects\ProjectX\Web\bin\ProjectX.Web.dll
C:\Projects\ProjectX\Web\obj\release\package\packagetmp\web.config(64):
error ASPCONFIG: It is an error to use a section registered as
allowDefinition='MachineToApplication' beyond application level.
This error can be caused by a virtual directory not being configured as an
application in IIS.
------ Skipped Publish: Project Web, Configuration: Release Any CPU ------
Now if delete the obj folder, I can build fine.
This is rather frustrating to have any build fail after I publish until I manually delete the obj folder. Is there anything I can do to fix this?
Add this to the .csproj file:
<Target Name="AfterBuild" Condition="'$(Configuration)'=='Release'">
<RemoveDir Directories="$(IntermediateOutputPath)" />
</Target>
Seems to delete the files in obj\Release but not the folder itself, at least on my machine.
This problem occurs because MvcBuildViews conflicts with Web Deploy packaging. I got the idea for this solution from http://www.zvolkov.com/clog/2011/02/16/asp-net-razor-lessons-learned/ :
<PropertyGroup>
<PackageDependsOn Condition="'$(DeployOnBuild)'=='true'">
CleanWebsitesPackage;
CleanWebsitesPackageTempDir;
CleanWebsitesTransformParametersFiles;
MvcBuildViews;
$(PackageDependsOn)
</PackageDependsOn>
<BuildDependsOn Condition="'$(DeployOnBuild)'!='true'">
$(BuildDependsOn);
MvcBuildViews
</BuildDependsOn>
</PropertyGroup>
<Target Name="MvcBuildViews" Condition="'$(MvcBuildViews)'=='true'">
<AspNetCompiler VirtualPath="temp" PhysicalPath="$(WebProjectOutputDir)" />
</Target>
Now AspNetCompiler will run before packaging. This works nicely with the msbuild /p:DeployOnBuild=True /p:DeployTarget=Package approach.
This is a known issue with MVC when you enable the build MVC views feature. Hopefully they get it fixed in the next version.
In the mean time, you can run the "Clean Solution" operation to clear out the obj folder instead of doing it manually. The downside is, your entire solution will be rebuilt every time.
Another option that I haven't done, but have considered if my project gets any bigger, is a pre-compile step in the MVC project to remove the web.config from obj\

TeamCity - problem with Publish on ASP.net site

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.

Resources