I'm using VSTS to deploy at several environments. And as usual, some parameters on config files need to be different depending the environment, hence I will use config transformations to deploy it at the target environment.
Since I want to have the package with both the config and the transform that will be applied later I set the Build Action as Content as such:
<Content Include="App_Config\MyConfig.config" />
<Compile Include="App_Config\MyConfig.prod.config">
<DependentUpon>MyConfig.config</DependentUpon>
</Compile>
<Compile Include="App_Config\MyConfig.uat.config">
<DependentUpon>MyConfig.config</DependentUpon>
</Compile>
<Compile Include="App_Config\MyConfig.dev.config">
<DependentUpon>MyConfig.config</DependentUpon>
</Compile>
The package is done correctly and the deploy as well (MyConfig.config has the parameters changed depending on the environment it runs).
My problem is that on the server machine I have the MyConfig.*.config files as well.
Looking at the official documentation example note's (https://learn.microsoft.com/en-us/vsts/pipelines/tasks/transforms-variable-substitution?view=vsts#xml-transformation-example) doesn't give anything clear. It's just "msbuild will do it before packaging and azure not" but doesn't explain a way to do it.
Edit: Solution I went with.
Basically I couldn't avoid to keep the artifacts clean, as they are not dependant on the environment. So after all Release pipeline I added a Delete files job (https://learn.microsoft.com/en-us/vsts/pipelines/tasks/utility/delete-files?view=vsts) To remove all configuration files with the following parameters:
Source Folder:
$(wwwRoot)\
Contents:
**\*.Debug.config
**\*.Release.config
**\*.UAT.config
**\*.PROD.config
You would probably need to think about creating a post deploy script to clean those files and add it to your release script to run at the end of deployment.
First, with XML file transformation, the xx..config file is required.
Secondly, the transform will be applied when publish web app to web deploy package or publish to server directly per to the configuration (e.g. Release, Debug).
Regarding web deploy package, there is xx.SetParameters.xml file, which contains the related transformed elements and the value will be applied during deploy. You can update that file before deploy.
Web.config Transformation Syntax for Web Project Deployment Using Visual Studio
Update:
You also can store the files in Secure Files, then copy the file to related folder through Copy file task:
Download Secure File task
Copy file task (Source folder: $(agent.builddirectory)\..\_temp)
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.
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\
I'm trying to make a subdirectory in an MS Deploy package writable to the application pool user. Thanks to a helpful post about the setAcl provider by Kevin Leetham I was able to get most of what I need into my project file:
<MsDeploySourceManifest Include="setAcl"
Condition="$(IncludeSetAclProviderOnDestination)">
<Path>$(_MSDeployDirPath_FullPath)\doc\public</Path>
<setAclAccess>Read,Write,Modify</setAclAccess>
<setAclResourceType>Directory</setAclResourceType>
<AdditionalProviderSettings>setAclResourceType;setAclAccess</AdditionalProviderSettings>
</MsDeploySourceManifest>
Note that I've added "\doc\public" to the root deployment directory. In the resulting manifest that VS2010 builds, I see the following setAcl element:
<sitemanifest>
<contentPath path="C:\Source\...\obj\Debug\Package\PackageTmp" />
<setAcl path="C:\Source\...\obj\Debug\Package\PackageTmp"
setAclResourceType="Directory" />
<setAcl path="C:\Source\...\obj\Debug\Package\PackageTmp"
setAclUser="anonymousAuthenticationUser"
setAclResourceType="Directory" />
<setAcl path="C:\Source\...\obj\Debug\Package\PackageTmp\doc\public"
setAclResourceType="Directory"
setAclAccess="Read,Write,Modify" />
</sitemanifest>
That last line looks good: it's appended the subdirectory I want to be writable, and the access modifiers all seem to have transferred over well enough.
However, when I deploy this package I receive an error:
Error: A value for the 'setAclUser' setting must be specified when the
'setAcl' provider is used with a physical path.
This is a confusing error because I'm not trying to set an ACL on a physical path, exactly, but a subdirectory of a web application. Looking at the output of MS Deploy, it's easy to see the problem:
Info: Adding setAcl (REST Services\1.0.334).
Info: Adding setAcl (REST Services\1.0.334).
Info: Adding setAcl (C:\...\obj\Release\Package\PackageTmp\doc\public).
MS Deploy is apparently substituting the web application name for my absolute path "C:...\obj\Release\Package\PackageTmp", but when I append "\doc\public" to that absolute path it no longer recognizes it as a web application directory. This exact problem is described by another victim over on the ASP.NET forums without any resolution.
Does anyone know how to set an ACL on a particular subdirectory of a web application via Web Deploy without manually identifying the physical path and application pool user on the target host?
OK let me first say that this is way harder than it should be!
I think the reason why it is failing is because when you are publishing it cannot recognize the folder as being a folder in the IIS Application. The reason this is happening is because the full path is being transferred to the destination when the SetAcl provider is invoked. Instead of that we need an path which is relative to the IIS Application. For instance in your case it should be something like : "REST SERVICES/1.0.334/doc/public". The only way to do this is to create an MSDeploy parameter which gets populated with the correct value at publish time. You will have to do this in addition to creating your own SetAcl entry in the source manifest. Follow the steps below.
In the same directory as your project create a file with the name {ProjectName}.wpp.targets (where {ProjectName} is the name of your Web application project)
Inside the file paste the MSBuild content which is below this list
Reload the project in Visual Studio (VS caches the project files in memory so this cache needs to be cleared).
{ProjectName}.wpp.targets
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="SetupCustomAcls" AfterTargets="AddIisSettingAndFileContentsToSourceManifest">
<!-- This must be declared inside of a target because the property
$(_MSDeployDirPath_FullPath) will not be defined at that time. -->
<ItemGroup>
<MsDeploySourceManifest Include="setAcl">
<Path>$(_MSDeployDirPath_FullPath)\doc\public</Path>
<setAclAccess>Read,Write,Modify</setAclAccess>
<setAclResourceType>Directory</setAclResourceType>
<AdditionalProviderSettings>setAclResourceType;setAclAccess</AdditionalProviderSettings>
</MsDeploySourceManifest>
</ItemGroup>
</Target>
<Target Name="DeclareCustomParameters" AfterTargets="AddIisAndContentDeclareParametersItems">
<!-- This must be declared inside of a target because the property
$(_EscapeRegEx_MSDeployDirPath) will not be defined at that time. -->
<ItemGroup>
<MsDeployDeclareParameters Include="DocPublicSetAclParam">
<Kind>ProviderPath</Kind>
<Scope>setAcl</Scope>
<Match>^$(_EscapeRegEx_MSDeployDirPath)\\doc\\public$</Match>
<Value>$(_DestinationContentPath)/doc/public</Value>
<ExcludeFromSetParameter>True</ExcludeFromSetParameter>
</MsDeployDeclareParameters>
</ItemGroup>
</Target>
</Project>
To explain this a bit, the target SetupCustomAcls will cause a new SetAcl entry to be placed inside of the source manifest used during publishing. This target is executed after the AddIisSettingAndFileContentsToSourceManifest target executes, via the AfterTargets attribute. We do this to ensure that the item value is created at the right time and because we need to ensure that the property _MSDeployDirPath_FullPath is populated.
The DeclareCustomParameters is where the custom MSDeploy parameter will be created. That target will execute after the AddIisAndContentDeclareParametersItems target. We do this to ensure that the property _EscapeRegEx_MSDeployDirPath is populated. Notice inside that target when I declare the value of the parameter (inside the Value element) that I use the property _DestinationContentPath which is the MSBuild property containing the path to where your app is being deployed, i.e. REST Services/1.0.334.
Can you try that out and let me know if it worked for you or not?
FYI - this does work for a root website if you follow the convention specified in the post here:
http://forums.iis.net/p/1176955/1977169.aspx#1977169
<Match>^$(_EscapeRegEx_MSDeployDirPath)\\#(CustomDirAcl)$</Match>
<DefaultValue>{$(_MsDeployParameterNameForContentPath)}/#(CustomDirAcl)</DefaultValue>
<Value>$(_DestinationContentPath)/#(CustomDirAcl)</Value>
This post also has the benefit of being able to specify a block of subdirectories in a single ItemGroup.
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.