This is almost a duplicate of Link build configuration to a publish profile, but that question was not answered...
I have 2 1 Click Publish configurations for my Web Application:
Test Server
Production Server
If I select Build => Configuration Manager => Release and then click the Publish button my application will be published with a release configuration (and visa versa) - without regard to the current Publish profile selected.
But what I REALLY want is...
To set the appropriate Build Configuration from the 1 Click Publish settings. Test Server should be published with my Debug settings and Production Server should be published with the Release settings.
I shouldn't have to make the change from within the Configuration Manager. But I Do.
So, I have 2 questions:
Am I just doing it wrong? Based on a little note in the Publish Settings stating "Use Build Configuration Manager to change configuration" this seems like this is exactly how it is intended to work.
Is there another way of having 2 publish profiles, one with a Debug config and one with a Release config?
The only thing I'm using the debug/release build configurations for is for my Config Transforms that have different connection strings. So, alternative, but still 1 Click, publishing solutions are acceptable. :-)
It's possible to do another way by having multiple Web Deployment Packages.
Basically create two different projects and each one will compile and set the asp.net build config and output. Then script the deployment as part of it.
Bit hacky (wish the publish profiles could set the build config as you wished).
Other than that I normally do via powershell scripts and kick off from my desktop deploy that does all the appropriate compiling and deployment scenarios.
http://msdn.microsoft.com/en-us/magazine/cc163448.aspx
http://johnnycoder.com/blog/2010/01/07/deploy-aspnet-web-applications-with-web-deployment-projects/
I was able to get this to work by installing the Visual Studio Web Publish Update. This update allows you to tie a build configuration to a specific publish profile.
http://msdn.microsoft.com/en-us/library/jj161045.aspx
Related
Having built a Blazor (hosted) application in development environment in blissful ignorance of the challenges of deployment, I now come to my first attempt at deploying.
My intention is to deploy to my local machine on IIS as a 'staging' environment before publishing a 'production' environment to the web.
My first attempt resulted in a snag relating to connection strings, which I believe is because my development settings had used integrated security, but the staged deployment is using IIS Application Pool identity, which does not have the SQL permissions.
Fine. So I think my next step is to create an appropriate appsetting.json file for 'staging'.
What I think I understand:
When 'publishing' the appropriate appsetings.<environment>.json file will be merged with the root appsettings.json file and become the deployed appsettings.json file.
The launchSettings.json file sets the <environment> under one of the 'profiles'.
What I can't get to the bottom of:
How, when I'm publishing from Visual Studio, do I tell it which 'profile' to publish with?
Or have I misunderstood something else?
UPDATE:
I now see that on project properties > Debug tab, I have the opportunity to create an additional "Profile" and set the Environment Variable for ASPNETCORE_ENVIRONMENT to "Staging". From there, I guess I can create an appsettings.staging.json file.
So, I think my question now is:
Do I have to go to the 'Debug' tab and select the profile I want to use BEFORE publish? And then change it back for when I'm doing more work in development?
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 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">
Q. How can I setup our config/transforms to get release management to work in the example way?
I'm trying to get release management to work in the way all the videos seem to show. The same build progressing through environments going through build --> Dev/Staging --> Production.
It's making me step back a little and question the way we do our configurations in Visual Studio solutions (and our git flow branch process). I think the way we use the configurations is making things more difficult further down the line with the build and then release.
Configurations
We currently use the two default configurations, debug & release.
We tend to use the debug build on our Dev (contains the dev database
connection string & other app settings transforms). This is what we deploy to 'dev'.
Then we also have the release configuration with the production transforms in. This is what we deploy to 'Production'.
How can I setup our config/transforms to get release management to work in the example way?
One option: Build both configurations. Publish both configurations as artifacts in your build.
In your release definition, deploy the appropriate configuration from the linked artifacts.
Another option: Don't do compile-time configuration transforms and instead do deployment-time configuration.
What you provide in the screenshot is a Overview of releases. Which is used to track a release in Microsoft Release Management. Based on a release name and links.
The Overview page shows a list of release definitions. Each one is shown as a series of environments, with the name of the release and the date or time it was started. The color of the heading and the icon in each environment indicate the current status of the release. The color scheme is the same as in the Releases page.
You just need to follow the provided starter deployment templates or you can also create your own templates for your project.
Back to the screenshot, there are just the environments in a release build definition. You can add the need environment in the definitions.
After that you will view the same thing in the overview just like the example:
For your situation, you can created two separate release definition with two build definition based on the both configurations. Moreover,there has been a very detailed document in MSDN, including setup, configurations, manage release, deploy, you can have a systematic understanding.
We are using TFS 2010. In our projects we have multiple configuration files. Each configuration file is needed for a specific build.
Example: Project XYZ includes three configuration files, lets say DEV-CONFING, QA-CONFIG and PROD-CONFIG files.
Now we want to find a way that during the build process, the build process includes the right configuration file and excludes the rest.
Example:
Build for Dev should pickup and copy only the DEV-CONFIG file (and excludes all other configuration files)
Build for QA should pickup and copy only the QA-CONFIG file (and excludes all other configuration files)
Build for production should pickup and copy only the PROD-CONFIG file (and excludes all other configuration files)
Is it possible to change the setting of individual build definition and address this issue?
What is best possible solution for this problem in VS 2010 and TFS 2010?
Please list all required steps and be precise as much as possible because I'm a newbie in TFS 2010 and have not much experience with the whole process.
The "Web Config Transformations in VS2010" addresses the problem of modifying the web.config during compile time. Some people might want the web.config to be modified at deployment time instead of compile time (like me) so that we dont have to recompile the code while moving from one environment to another, in that case you can make use of "Web Deployment Parameters"
You can read more about it at:
http://www.asp.net/mvc/tutorials/deployment/visual-studio-web-deployment/web-config-transformations
web config transformation syntax:
http://msdn.microsoft.com/en-us/library/dd465326.aspx
#user2585405 to your comment above "But all the configurations in my case are for the same mode "Release Mode". The decision should relay on the build definition. So when I use a build definition for DEV, the configuration for DEV should be automatically chosen or for QA build definition, the corresponding QA configuration should be automatically chosen."
Doesnt matter whether currently you have only one configuration. You can add how much ever configurations you want, right click the solution and select the configuration manager. Now add a new configuration say "Dev" (it can be in "Release/Debug" and also select the platform "x86, any cpu etc"). Now add another configuration for QA and PROD. Then come back to your web.config and right click and select "Add web config transformation".
Now you should be able to see the web.Dev.Config, web.QA.config etc. The root web.config will have all the common properties and the DEV/QA/Prod specific config will have only the delta changes (you have to define these entries) which are specific to that configuration (lets say connectionstring). When you compile, within the build definition you can select which configuration you want to compile (Dev, QA, prod) you dont have to keep multiple build defintion. Just one is enough! After the compilation is done, the root web.config will be replaced with the values specific to the configuration for the connectionstring part alone.
Hope this helps!
Yes this possible. You can keep configuration files in different mode for eg:
You can have configuration files in Release mode debug mode, release mode and the common configuration file used by all.
So when you build your solution in Debug mode then the debug mode configuration file will be used and when in release mode then release mode configuration file will be used.
For further clarity take example of web config when you will expand the web config tab you will see the two configuration file in different modes.