I have a web application that I publish using VS 2010 and Web Deploy. Because I need to publish the application to different sites, I have created different publishing profiles which, for example, I've named SITE1 and SITE2.
To customize behavior, I added a .wpp.targets file and, in that file, I'm able to reference things like $(Configuration), but I have not been able to figure out if it's possible to reference the name of the publishing profile (SITE1 or SITE2).
Is there a variable for the publishing profile name?
You can use the $(PublishProfileName) variable to get the name of the current publish profile, at least in VS 2012.
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?
I wanted to created a demo app that does automatic deployment. In other words once I check-in my code changes, the changes can be seen on the published website. I did the following steps:
I created an .NET project on Visual Studio 2017, published the project with IIS instructions from here and here. I published my project to a local file on my machine;
The I did Continuous Delivery and Release Management using TFS 2015 and created a build and release definitions from here;
The final step was to use the Copy File to and Publish Artifacts tasks, using file share option to drop the contents to the publish folder I've created. So when I check-in my changes using TFS, the changes will be seen online.
Here is the configuration for the build definition:
The folder in the file share path is shared to everyone, and the path is correct (when I type it in the browser, I can see the folder's contents).
The error I keep getting is the following:
Publishing build artifacts failed with an error: Unable to create
directory '{p}'. Unable to verify the directory exists: '{testDir}'.
If directory is a file share, please verify the share name is correct,
the share is online, and the current process has permission to access
the share. \localhost\builddrop\drop \localhost\builddrop\drop
I've been trying to solve this for 2 days with no luck, but I could not find similar issues... I would like to know what is causing this error, or if you have any hints or tips that will get me closer to the solution.
Thanks to #Maxsur answer I realized that I did not install a build agent, which is needed for in case you want to publish your code into a file share.
I did that by going to the team foundation server web portal clicked on the gear sign, and chose Agent Queues and followed the steps. Additionally you will also need to acquire a token by clicking on your profile icon then choosing security and add new token.
Reference: https://learn.microsoft.com/en-us/vsts/pipelines/agents/v2-windows?view=vsts
Try to check (and change) an account for your build agent service.
It can be found at Windows Services -> VSTS Agent on build machine (or TFS server if it used as build machine).
This service can run under "local service" account, which cannot access network shares (even on local machine!).
Try to change this account to Administrator (for example) or setup one by guidelines of MSDN
In your Publish Artifacts Task, you've specified //localhost/builddrop/ in File share path, which is not correct. You need to specify the File share path as below:
\\servername\builddrop
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">
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.
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.