VSTS CI CD for desktop apps - azure-devops

How can I achieve CD (Continuous Delivery) for winform applications in VSTS (Visual Studio Team Services)? Currently this is what I have in my Visual Studio Solution file
1) A winform project
2) A Windows setup and Deployment project
So every time I build a winform project, I do the following steps (and I need CI / CD for exactly these)
1) Build Setup and Deployment project, which takes Build output of Winform project and creates and EXE / MSI
2) I take this MSI file and use NSIS to embed it inside EXE
3) I run SIGNTOOL from command prompt and digital sign the EXE
4) I upload this signed EXE to my website
Now how can I use CI / CD pipeline to automate the above or is it not possible for my case? I am confused. I can't find any material for winforms, all are for web apps.
Thanks

You will obviously need some sort of desktop deployment strategy. The easiest is to be using xcopy. Other alternatives include frameworks like ClickOnce, Windows Installer or Squirrel to name a few. I have a number of corporate apps that use Clickonce that I have deployed using vsts.
Now I am unable to understand how will VSTS help me with this?
Use VSTS to build the software first and include additional tasks to package your app. In my case, I use devenv.exe to generate ClickOnce packages, but you can include custom tasks by using powershell. The artifact of the build should now be the "packaged app".
Then use the VSTS deployment to copy the "package" to some kind of hosting server from where your users can download the package. That could be either a web server or a fileserver or any location appropriate for your deployment strategy.
In this context, VSTS is an orchestration tool. It helps to trigger actions for you.
See Deploy an agent on Windows to see how to setup an on-premise agent.

To build and deploy the way as you used in VSTS, you can use below steps:
Create a repository (Git or TFVC) and push your solution in the repository.
Add build/release definitions.
With CI build, enable the Continuous Integration in Triggers Tab. With CD deploy, enable Continuous deployment trigger in Pipeline Tab. The process for CI build and CD deploy, you can refer CI/CD.
Add related tasks in your build/release definition.
Build VS Installer task: build setup project with msi file.
Nsis Build Task: embedded msi file in exe.
Command Line task: to execute the signtool command. Since Hosted agent has not signtool.exe, so you should use private agent which has the signtool.exe on the machine.
Copy files task, Copy Files Over SSH task or Windows Machine File copy task: upload the file exe to your web server.

Related

How to build Visual Studio Installer Project in Azure Pipelines in Self-Hosted Windows Agent

The image above shows my Hello World project structure. I am trying to build the Setup-HelloWorld-x86.vdproj in Azure Pipeline in Self-Hosted Windows Agent (which is nothing but my local machine) by using the command line script task like shown in below image.
But I get the following error.
Kindly help me to build this Setup-HelloWorld-x86.vdproj
If you want to run the project via cmd devenv, you can refer to this doc.
As a workaround, you can install the extension Build VS Installer and use the task DutchWorkz - Build VS Installer(s) to build Visual Studio Installer Project in Azure Pipelines.
You can specify to build .sln or .vdproj to generate .msi file(s) in Task-mode option.
Update1
Thanks Tharunavignesh J for sharing.
The solution was to run the azure agent under proper account. Earlier my azure agent was running under some Network Service account, then I change it to the local account, then this cmd worked properly.
This other stack overflow link helped me get my visual studio installer project compiled with Azure DevOps pipelines. It is using yaml configuration instead of classic, but same steps / commands apply to both:
YAML Script for building Visual Studio Installer Projects using Azure DevOps
Basically the steps are:
Setup your variables to point to the tools
Download Nuget packages for your solution
Disable Out Of Process Builds command executed
Script task with the command line arguments to build your solution

Invoking MsDeploy.exe manually in a Azure Devops

Background
As part of our deployment pipeline we are creating our deployment artifact, by running several .xdt transforms on our build artifact as well as adding several additional files.
As the last step before publishing, we would like to invoke msdeploy.exe to build a "custom" webdeploy package from a folder containing the wwwroot-content - (msdeploy command for creating custom package found in this question Web Deploy - How to create a package with selected items)
We are using hosted agents (win 2017).
We wish to deploy to an Azure AppService.
Question
Is there a task in Azure DevOps, that allows you to invoke MsDeploy.exe manually, such that we can create a custom webdeploy package, before we deploy?
Is there a task in Azure DevOps, that allows you to invoke MsDeploy.exe manually, such that we can create a custom webdeploy package, before we deploy?
I am afraid there is no such task to invoke MsDeploy.exe manually. We need invoke it by command line task, just like Daniel comment.
As we know, the default installation will place msdeploy.exe in:
C:\Program Files (x86)\IIS\Microsoft Web Deploy V3\msdeploy.exe
To verify the msdeploy path on the hosted agents, I use a copy task with content **\msdeploy.exe:
Then use the Publish build artifacts to output the msdeploy.exe, I could get the result on the hosted agent vs2017-win2016 and windows-2019:
So, the the msdeploy path on the hosted agents vs2017-win2016 and windows-2019 is C:\Program Files (x86)\IIS\Microsoft Web Deploy V3\msdeploy.exe. We could use command line task to invoke it.
Hope this helps.
Here is the exact CommandLine task that worked for me (without parameters though):

VSTS - MVC Web app deploy task is deprecated. How to deploy to test server on prem

Setting up a Release definition task to deploy a MVC web app to a test server (on prem). Typically I have done this a FileSystem publish via a Visual Studio publish profile. What task can I use in VSTS to achieve the same thing, assuming I already have a working agent setup on the test server and a successful build?
The app is actually setup as a website on the test server, not a virtual app under another website. Looking at adding the "IIS Web App Deploy" task, VSTS reports that this task is "deprecated, so what is the suggested replacement for this?
I suppose I could use the Windows file copy task, but the build artifacts are zipped. What would I need to use if I went this route?
You can use Visual Studio Build task with /p:SkipInvalidConfigurations=true /p:DeployOnBuild=true /p:WebPublishMethod=FileSystem /p:publishUrl="$(build.artifactstagingdirectory)\\" /p:DeployDefaultTarget=WebPublish MSBuild Arguments to publish web app to artifact folder (e.g. {agent working folder}/1/a).
You also can specify the publish profile directly /p:SkipInvalidConfigurations=true /p:DeployOnBuild=true /p:PublishProfile="{publish profile name}";publishUrl="$(build.artifactstagingdirectory)"
With FileSystem publish method, the published files are in a folder, not zipped, but you can zipped the folder through Archive files task.
Also you can extract files through Extract files task, so you can copy extracted files through Window machine file copy task to the corresponding web site path.
On the other hand, you can deploy the web app through WinRM-IIS Web App Deployment task.

VSTS: Release Management Deploying Artifacts to IIS on Premise

I am using VSTS Release management to deploy artifacts to IIS websites. I have several Web applications and web services to be deployed. So, i am trying to figure out what sort of tasks that best fits my situation.
I have created a build definition with Visual Studio Build Task for projects as this one:
which works fine but i need to add a task for copying the artifacts Under IIS Website Directory.
The other approach is to use IIS web deployment as a task in Release definition, so I created the build definition as:
However, it expects a Publish Profile (the build fails because it can't find it). I don't need to create a publish profile for each project in the application because this would be too much work.
Is there is a workaround for that or what is preferred approach for this?
You can update your build definition to generate a web deployment package and upload it to artifacts. And then in Release Management, add a task to run "projectname.deploy.cmd" in the deployment package to deploy it to your IIS server. Refer to this link for details: How to: Install a Deployment Package Using the deploy.cmd File Created by Visual Studio.
And you can also enable FTP Publishing on your IIS server and add a task in your release to publish the artifacts via FTP. You may need this task:
FTP Uploader.
My Continuous Delivery with TFS / VSTS – Server Configuration and Application Deployment with Release Management blog post (with reference to some previous posts) has all the details you need for deploying your artefacts to target nodes using Windows Machine File Copy tasks then use PowerShell on Target Machines tasks to get them in to correct locations and to do token replacement and anything else that's required.
I would recommend using PowerShell DSC so that IIS is properly configured before deployment but that's not required. Where possible for web apps I favour keeping things very simple by creating artefacts that contain all the web files that are needed for a particular folder and then just using plain xcopy for the deployment.
If you need more control you can also use my MSDeploy VSTS extension to deploy a MSDeploy package
https://marketplace.visualstudio.com/items?itemName=rschiefer.MSDeployAllTheThings
https://dotnetcatch.com/2016/04/20/msdeployallthethings-vststfs-extension-is-public/

OnPrem TFS 2015.1 vNext - What step to Release to on premises IIS server?

I'm trying to use TFS 2015.1 on premise to build a CI pipeline for our dev & uat. I've created a vNext CI build, which builds fine. But when I want to add a deploy step for on prem IIS server, I only then see Azure Web Deployment options.
Ideally I wanted to add a step which uses the existing deploy (MS Deploy) profiles, which I'm able to use from VS2015 directly, using 'Publish'. However I see no option to do so.
How can I deploy the latest build to internal dev servers (not Azure)? I would like to use the MS Deploy option, unless there's a better way of doing it?
The fact that their is no option to starts to make me think there's probably a different way to accomplish it!
Thanks.
If you're able to upgrade to TFS 2015.2, web-based Release Management came out with it that works similarly to Build vNext with flexible and open-source tasks. You can also customize tasks.
Here's a link for IIS Web App Deployment from the vso-agent-task's GitHub repo where Microsoft stores updated versions of their tasks that you can download for web-based Build and Release Management.
I'll be publishing a blog about web-based RM with TFS 2015 Update 2 or VSTS on my website in the next few weeks. To give you an idea though, the starting point (for a web application) is a folder in your web project called WebDeploy (no significance - any name will do) that contains a PowerShell DSC script that configures the server, deploys the web files and then replaces any tokenised configs. To give you an idea see this post about how to use DSC to configure servers. (Only covers part of the final script though!) The next steps are:
In the build hub create a Website artifact - containing your web files and DSC script.
In the release hub for an environment use a Windows Machine File Copy task to deploy the artifact to a temp folder on the target node.
Then use a PowerShell on Target Machines task to execute the DSC script. After configuring the server the script copies the web files to their proper location, sorts out config using xReleaseManagement and cleans up the WebDeploy folder.
See this article for general details of the route I'm taking, but watch out as it has some errors eg the firewall instructions are incomplete (file and print sharing through the firewall needs to be enabled).
I can thoroughly recommend the PowerShell DSC route - I've had a few glitches but on the whole it feels very productive and the right way to be going.