Using a publish profile creates a deploy.cmd and a single SetParameters.xml for calling via msdeploy.
Having multiple environments, I'm looking for how to populate version-specific ProjectName.SetParameters.xml files, such that during deployment the corresponding one can be used.
I'd like to create one of these files per environment, to be source-controlled.
Is there an intrinsic way to control the creation of several SetParameters.xml in this manner, or does this need to be a post-build task transforming from a list of per-environment settings?
Is there an intrinsic way to control the creation of several SetParameters.xml in this manner, or does this need to be a post-build task transforming from a list of per-environment settings?
According to your description, the following thread provide 5 options, I would suggest that you could select option1, which create a parameters.xml file in your web project and will declare additional Web Deploy parameters.
When you build the Web Deploy package the parameters declared in parameters.xml are created in the package. When this web deploy package is created the web.config file will be transformed based on the build config.
Build once and deploy to multiple environments with msdeploy & Visual Studio 2012
For more information about Custom Parameterization, please refer to: https://www.asp.net/web-forms/overview/deployment/web-deployment-in-the-enterprise/configuring-parameters-for-web-package-deployment
Related
We are using VSTS for build and release management, and using CI/CD. Typically, our solutions consist of a web application project, and a database project.
Our current release tasks take the application offline (using app_offline.htm), publish the database, then publish the web application. Publishing the database project often results in no changes, as due to CI/CD we are much more frequently updating code on the web app than changing the db schema.
Is there a way to only run the database publish task (using WinRM) when it detects a change in the database project code, in our git repository?
EDIT: This in itself isn't a problem, as typically when the DACPAC gets published, there will be no activity. HOWEVER, I've been requesting that the database is backed up using the /p:BackupDatabaseBeforeChanges=true flag - which seems to back up the database even if there are no changes. This is an issue for large databases.
The simple way is that you can separate web project and database project to two build definitions.
Create a new build definition
Enable Continuous Integration in Triggers tab
Specify Path filter to include database project
Modify Visual Studio Build task, specify /t:[database project name] argument in MSBuild Arguments box to just build database project
The same steps for web project
Create a new related definition
Add artifacts for previous two build definitions and enable Continuous deployment trigger
Add two environments (e.g. database, web)
Open Pre-deployment conditions of an environment (e.g. database)
Enable Artifact filters and select corresponding artifact (e.g. database build artifact), specify build branch (can specify *, it means all branches)
Add tasks to just deploy database in this environment
The same steps for web environment
The answer is - exactly what I want isn't possible.
I created a release definition on Visual Studio Team Services for my Windows console application. This app runs on a Virtual Machine so I basically perform the deployment using a Windows Machine File Copy task.
Now I need to create two environments (stage and production) and each of these environments must use different app.config variables.
Recently, I have successfully performed this transformation for a web app using the Azure App Service Deploy XML Variable Substitution. But this is not an available option for file copy task.
How can I make this work?
You can do it with Replace Tokens extension, then copy files.
You can use the File Transform task from Microsoft in order to replace the environment variables in the XML config file.
This task both updates tokens and replaces them which means that you only need this single task in addition to the Copy Files task in your case.
I have a console application that I am deploying to Azure as a Web Job. I do this manually from Visual Studio 2015 by right-clicking the project and choosing "Publish as Azure WebJob".
I am now at a point where I need to deploy this app to several different environments (ex: dev, test, prod etc). In each environment the console app needs to run with different config settings.
To get this done, I've installed Slow Cheetah v2.5.48 and setup multiple config transform files - one for each environment.
I've also created dedicated publish profiles in my project - one for each environment - and I've made sure the profile names match the names of the config transform files.
When I manually publish via the Publish wizard in VS (as described above), I find that the config transforms are not applied. Instead, the "base" .config file are present on the target app service.
Why are the transforms not applied when publishing this way and how can I fix that?
According to your description, I suggest you could firstly check you have already build configuration called "dev" ,” test” like below.
Then I suggest you could check you have a right app config file in your project like below.
At last, you could make sure you have select the right build configuration.
Besides, I suggest you could open your .csproj file and ensure that the App.dev.config tag’s IsTransformFile is true.
<None Include="App.dev.config">
<DependentUpon>App.config</DependentUpon>
<IsTransformFile>True</IsTransformFile>
</None>
I would suggest you try with:
< xdt:Transform="Replace">
During build msbuild creates deployment packages for several my web projects (and wcf services) which I want to run from command line (as last step of automated build process) to deploy to several different servers.
The structure of IIS application folders is the same on each one.
My problem is that I cannot find how to configure (override default value of IIS application). It is in .SetParameters.xml, like:
which is not what I want.
I read that it is possible to create parameters.xml in the project and put there something like:
or some say
I'm trying this but it does not change content of .SetParameters.xml
Can you advice what am I missing, or/and alternative way to do this.
Thanks!
If you want to deploy the web application package manually—either by running the .deploy.cmd file or by running MSDeploy.exe from the command line—there's nothing to stop you manually editing the SetParameters.xml file prior to the deployment. However, if you’re working on an enterprise-scale solution, you may need to deploy a web application package as part of a larger, automated build and deployment process. In this scenario, you need the Microsoft Build Engine (MSBuild) to modify the SetParameters.xml file for you. You can do this by using the MSBuild XmlPoke task.
For more information, please refer to: https://www.asp.net/web-forms/overview/deployment/web-deployment-in-the-enterprise/configuring-parameters-for-web-package-deployment
I'm currently publishing the ClickOnce application manually by right clicking .csproj. Is there a way I can do the same from the solution directly so that I can use it with the build definition for continuous integration?
You can't publish the ClickOnce application from solution directly, but you can build and publish ClickOnce application with both XAML build and vNext build, and use MSBuild argument “/target:publish” to make MSBuild create the ClickOnce publish folder. Here are two blogs with detailed steps to build and publish ClickOnce application:
Build and Publish a ClickOnce App using Team Build/VSO, please refer to blog: http://blogs.msdn.com/b/tfssetup/archive/2015/09/15/build-and-publish-a-clickonce-app-using-team-build-vso.aspx
Building ClickOnce apps using build vNext, please refer to blog: http://blogs.msdn.com/b/tfssetup/archive/2015/10/15/building-clickonce-apps-using-build-vnext.aspx
Assuming you are using XAML build, so I'd like to highlight the points in the blog with XAML build. To achieve build and publish a ClickOnce application using Team Build, you need to edit the XAML build definition with following steps:
Set the publish path in the properties of the project, which would correspond to the destination. Then checkin your project to TFS.
Create a copy of template TFVCTemplate.12.xaml to do customization. In order to make the build process get a few environment data, you need to:
Create two environment variables – DropLocation and WorkingDirectory.
Add two events of type GetEnvironmentVariable from the tool box. Add them any place you prefer within the flow.
Use the first to set the variable DropLocation with data “Microsoft.TeamFoundation.Build.Activities.Extensions.WellKnownEnvironmentVariables.DropLocation”.
Use the second variable to set the variable WorkingDirectory with data “Microsoft.TeamFoundation.Build.Activities.Extensions.WellKnownEnvironmentVariables.BuildDirectory”.
Create new argument of type DestinationLocation and set to In with type String. This would be used to hold the location (file location) where your end data is going to go.
The reason we are editing the XAML build definition is the way ClickOnce publishing is done by MsBuild. MSBuild publish doesn’t do the copy of files to the destination, it creates a folder within bin and puts the files there.
As by default TFS copies the bin folder to the output drop location. But we need the app.publish folder. In order to find a way to take the published files from the publish folder. You need to:
Search for “Copy binaries to drop” activity within the template.
In the properties over write the existing source location(which would be the bin folder, like WorkingDirectory + "\src\Desktop\TeamAdmin\ClickOnceTest\ClickOnceTest) to something like this – WorkingDirectory + "\src\Desktop\TeamAdmin\ClickOnceTest\ClickOnceTest\bin\Debug\app.publish".
Add an event CreateDirectory, to create the directory again. We can use the destination location variable we created before. And Copy the files from the drop location to the desired location.
Now we can create a new build definition and enter the value for the DestinationLocation and the MSBuildArguments “/target:publish” and queue the build.