We have a single solution which contains one webapp project and some accompanying projects. Our TFS 2010 is building this solution every night and deploys the webapp to an IIS server. It runs like a breeze.
In the Process tab of the TFS build definition you can specify the "MSBuild Arguments". This is the value which is set in our build definition (all in one line):
/p:DeployOnBuild=True
/p:DeployTarget=MsDeployPublish
/p:CreatePackageOnPublish=True
/p:MSDeployPublishMethod=WMSVC
/p:MSDeployServiceUrl=<service url of IIS>
/p:DeployIisAppPath="<a website>"
/p:UserName=<domain>\<user
/p:Password=<password>
This blog post explains the whole setup: http://vishaljoshi.blogspot.com/2010/11/team-build-web-deployment-web-deploy-vs.html.
So far, so good.
Now we have added a second webapp project which we want to be deployed also to the same IIS every night. Unfortunately in this case the setup is not applicable. The TFS deploys only one webapp.
There are others with the same problem out there:
TFS 2010 + MSDeploy when solution has multiple web applications
and
WebDeploy to deploy multiple web sites
Vishal R. Joshi suggests to add some properties to each webapp project. Now the release build will generate the webpackage (zip file) for each webapp project which has the following properties defined:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DeployOnBuild>True</DeployOnBuild>
<DeployTarget>Package</DeployTarget>
<CreatePackageOnPublish>true</CreatePackageOnPublish>
</PropertyGroup>
Ok. But how to bring the TFS to deploy each webapp to the IIS? Any other ideas?
See Configure an App Service app in the Azure portal for more details. YAML pipelines aren't available on TFS. By default, your deployment happens to the root application in the Azure Web App. If you want to deploy to a specific virtual application, enter its name in the Virtual Application property of the Azure App Service Deploy task.
The simplest way to deploy to an Azure Web App is to use the Azure Web App task. To deploy to any Azure App service (Web app for Windows, Linux, container, Function app or web jobs), use the Azure App Service Deploy task.
You can configure the Azure Web App to have multiple slots. Slots allow you to safely deploy your app and test it before making it available to your customers. Use the option Deploy to Slot or App Service Environment in the Azure Web App Deploy task to specify the slot to deploy to.
There are many ways to handle multiple (web) projects in a solution and deploy them on build. I've seen many examples and all examples required loads of configuration. I believe this is the easiest way, for this to work you need Team Foundation Server as your Version Control software. The Solution contains a total three projects. Example: .-
As Vishal describes in the blog article you linked to yourself, all the MSBuild paramaters can be moved inside the csproj. This then means each project can have its own settings.
I have a single solution with 6 projects, 4 class libraries and 2 web (WCF and MVC app). I followed the directive from Vishal's blog and simply moved all my MSBuild paramaters into each csproj file.. i.e.
<PropertyGroup>
<DeployOnBuild>True</DeployOnBuild>
<DeployTarget>MsDeployPublish</DeployTarget>
<CreatePackageOnPublish>True</CreatePackageOnPublish>
<MSDeployPublishMethod>InProc</MSDeployPublishMethod>
<MSDeployServiceUrl>localhost</MSDeployServiceUrl>
<DeployIisAppPath>Dev.Auzzy\Web</DeployIisAppPath>
<UserName>Username</UserName>
<Password>Password</Password>
...
Make sure you then remove the paramaters from the build definition.
TFS then deploys as expected.. each project into the correct folder specified as the home directory for each IIS site.
Also its worth noting that you can not include the DeployIisAppPath in the PropertyGroup as above but use the project's properties page to specify this for each build configuration. (Right Click on each project > Properties > Package/Publish Web).
It took me 2 days on this problem. I found a freaking simple solution that works for me.
I created 2 more configurations by using solution's Configuration Manager named DeployMvc1, DeployMvc2. Uncheck build for MVC2 project in DeployMvc1 and uncheck build for MVC1 project in DeployMvc2.
Next, I created 2 build definitions DeployMvc1Build and DeployMvc2Build. The first one listens to MVC1 project with
/p:DeployObBuild=true
/p:Deploytarget=MsDeployPublish
/p:Configuration=DeployMvc1
/p:Platform="Any CPU"
/p:MSDeployPublishMethod=WMSvc
/p:MsDeployServiceUrl="https://{server1}:8172/MsDeploy.axd"
/p:DeployIisAppPath="mvc1"
/p:AllowUntrustedCertificate=True
/p:Username="{username}"
/p:Password={password}
The second one listens to MVC2 project with
/p:DeployObBuild=true
/p:Deploytarget=MsDeployPublish
/p:Configuration=DeployMvc2
/p:Platform="Any CPU"
/p:MSDeployPublishMethod=WMSvc
/p:MsDeployServiceUrl="https://{server2}:8172/MsDeploy.axd"
/p:DeployIisAppPath="mvc2"
/p:AllowUntrustedCertificate=True
/p:Username="{username}"
/p:Password={password}
Then my problem solved.
I have a similar situation where I have a TFSBuild.proj build file and I generate a handful of installers and packages at the end of the build, targetting each of the deployment environments: Development, Test, Staging, and Production. Properties defined in @Matt Shepherd's answer can also be provided directly to the MSBuild task instead of writing them into the individual project files.
<!-- After build -->
<Target Name="AfterCompileSolution">
<!-- Create SynchWorkflow deployment packages -->
<CallTarget Targets="PackageSynchWorkflow" />
</Target>
<!-- Build deployment package for each target environment -->
<ItemGroup>
<BuildMode Include="Development"/>
<BuildMode Include="Test"/>
<BuildMode Include="Staging"/>
<BuildMode Include="Production"/>
</ItemGroup>
<PropertyGroup>
<PackageLocation>$(OutDir)</PackageLocation>
</PropertyGroup>
<Target Name="PackageSynchWorkflow" Outputs="%(BuildMode.Identity)">
<Message Text="Building %(BuildMode.Identity)"/>
<MSBuild Projects="$(SolutionRoot)\SynchWorkflow\SynchWorkflow.csproj"
Properties="Platform=Any CPU;
Configuration=%(BuildMode.Identity);
DeployOnBuild=true;
DeployTarget=Package;
DeployIisAppPath=Default Web Site/SynchWorkflow;
OutputPath=$(PackageLocation)\SynchWorkflow.%(BuildMode.Identity)Package;"/>
</Target>
In this case it is possible to specify the DeployIisAppPath and that value will be written to the deployment package parameters file.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With