I have an application which is running on machine with production database,I need to do a quick test against test database, for this I need to create the second publish which will start the new installation instead of updating the production application.
I tried changing product name, but it just update the product name. Is there any setting available in publish, which forces the second publish to start a new installation instead of updating the old first one?
Creating copy of the project will solve the problem, but it would be nice to create the 2 different publish from the same project.
For now changing assembly name and product name does the trick. But I wonder if its possible to publish both production and test simultaneously with different app and publish settings!!
Related
I have a standard build configuration, ending with a simple ssh copy of the output files to a remote server.
The process wanted is simple:
The developper pushes the commit to production
Teamcity builds the product
The developper downloads the product from the remote server where build results are stored
The developper tests the product (end-to-end testing, testing setups etc, can't be automated at the moment).
If the product is okay, label the build that produced this output as the new version (let's say 3.2.1).
Teamcity applies the label, and moves the files produced by this build to a folder named after the label value (3.2.1 in this example).
Only the last step is missing, because I don't find any ways to connect on the tag action to trigger some sort of build action.
I already tried to link another build configuration to this one, but the issue is that it has to be triggered by the developper for a specific build ID, so the developper tests the output of a given build, if it's okay, he tells teamcity "Okay, release this build as version 3.2.1" and the build artifacts are persisted in a folder named 3_2_1 for instance.
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 was wondering if there is an easy way to use ClickOnce deployment to publish multiple versions of the same application. For instance, I have an application that we distribute to several of our sister companies for use, and so I need to have that companies name set in the config file so that it displays their name on the splash screen and the reports the program outputs (and possibly change the application name as well).
My only thought on how to do this is to have separate directories on the web server and place a published deployment on each one. In visual studio I will have to set the correct name in the config file, publish the files to the server, go back and change the name in the config file, publish again, etc until each company has their own individual deployment.
You can create an MSBuild script that will update the config file, update the location of where to publish the ClickOnce files and then start the actual ClickOnce publishing process. Have the script loop through your different companies until they are all complete.
I've got a website and a console application which work together.
The Website is published to any of ~10 different servers depending on the publish profile. For production, that's MSDeploy but for Dev/Test/UAT/etc... it's a simple UNC File path copy.
I'd like to be able to publish the CLI as easily (at least to "local" servers). What I want is to click Publish, pick the Profile/Server and have it compile and copy the output in the bin folder to \\Server\ApplicationName
I'm aware I could perform the Copy as a Post-Build step but don't always want to do the copy and definitely don't always want it to the same place.
The publish options which exist for Console/WinForms apps seem to center around 1-click publishing which isn't what I'm after (I don't want the app phoning home looking for new versions every time, I want to explicitly push a specific version to a specific server).
I'm aware that if the app is running during the attempted publish, there will be problems.
Is this achievable?
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