How to publish ClickOnce application using build definition? - visual-studio

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.

Related

Why are config transforms not applied when I manually publish a console app as an Azure webjob?

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">

Calling deploy.cmd with environment-specific SetParameters.xml files?

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

How to attach file in TeamCity 8.1 build run dialog?

I want to attach some file as option in TeamCity 8.1 Build Run dialog form.
Before start build this file must be copied into defined place on the Agent side.
Who knows, is it possible? I can't find any plugins for it.
Tnx.
Where does this file normally reside? ie: where would TeamCity get it from?
Where should this file be copied to on the build agent? Can it be placed in the sandbox (work folder) for a given project?
If the file is stored in source control, you can specify a VCS root to get it copied over to the sandbox the same way you specify a VCS root to get the source code you wish to build copied to the sandbox.
For our projects, we regularly specify two VCS roots for a single project: one to copy some scripts and utilities our build requires and one to copy the actual source code that needs to be built.
Hope that helps!

Is there an easy way to publish multiple ClickOnce installations of the same application?

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.

How can I manage different database build reference paths between TFS and my local machine?

I have two database projects DB_A and DB_B. Project DB_A references DB_B.
I added a database reference by pointing to DB_B.dbschema at
C:\SourceParent\DB Projects\DB_B\sql\debug\DB_B.dbschema
When I build project DB_A on my local machine it works fine.
Now I want to build this on my TFS build server, but I get the following error
File D:\Builds\SourceParent\Build_Name\DB_B\sql\debug\DB_B.dbschema does not exist
I have a build for DB_B on my build server, but it's at a different path (the build definition doesn't necessarily match the project name).
I think I could add a build event in my build definition to copy the .dbschema file to the correct location on the server, but I'd rather not do this. (This would require a special build template for each build definition.)
Is there some way I can make the TFS build point to a different location? Or some other nice way I can accomplish this?
I solved this by creating an environment variable $(DB_SCHEMAS) pointing to a directory on my machine (e.g. C:\dbschemas).
Then I added a post build event in project DB_B to copy DB_B.dbschema to $(DB_SCHEMAS).
I then added a database reference in project DB_A pointing to $(DB_SCHEMAS)\DB_B.dbschema. Note that Visual Studio will add this reference using a relative path. To fix this, I unloaded the project in Solution Explorer, and edited the hint path to use the $(DB_SCHEMAS) environment variable.
Now I just added this environment variable on the TFS server and it will work as expected. Building project DB_B copies its .dbschema file to $(DB_SCHEMAS) (wherever that may be) and then building project DB_A references this scheme.
The only downside is that my teammates all have to add this environment variable on their machines as well, otherwise they can't build locally.

Resources