How do you go about setting up the build / publish for an ASP.NET web site (not a compiled application).
I have a classic simple site with primarily static assets. The only reason for the site is an aspx page that is used for a contact form email.
Simple steps:
Install IIS Web App Deployment Using WinRM extension if you want to deploy app to your web server
Create new build definition with Asp.Net Build (PREVIEW) template (select ASP.NET Build PREVIEW template when create build definition)
Add Windows Machine File Copy step to copy files to your web server
Add WinRM-IIS Web App Management step to create or update web site in IIS
Add WinRM-IIS Web App Deployment step to deploy app to web site (step 4)
You also can refer to this thread: Automated Deployement of ASP.Net MVC Website In IIS server with a Continuous Deployment
If you want to deploy app to azure, you can add Azure App Service Deploy step to deploy your app to azure (do not install previous extension and remove step 3, 4, 5)
You also can refer to this article: Deploy ASP.NET apps to Azure web apps
What I was looking for was publishing a ASP.NET 2.0 Web Site (not an application that requires a build).
It ended up being pretty easy. I have mostly static files, but there is one aspx page for that is used for a contact form. I followed this solution but tweaked it a bit.
All I needed to do was add the npm and gulp task. My gulp task does as the answer suggests - copies all of my pertinent files to a folder called dist. From there, I copy everything from the dist directory to the $(Build.ArtifactStagingDirectory).
Then it is just a matter of publishing the $(Build.ArtifactStagingDirectory) to the server (a drop directory similar to the examples of building an MVC app).
I wired in the release for CI / CD.
Related
If we are deploying a basic WebApp / WebApi, both these tasks from Microsoft appear to do the same thing - deploy to an appservice.
AzureWebAppV1
AzureRmWebAppDeploymentV4
How do you choose which one to use in a new YAML release pipeline? I just want to make sure I am using the version that is most future-proof - I have 25 release pipelines and don't want to have to re-do them unless necessary.
The way the help is written, hard to compare feature to feature to spot the key "must-haves". Some Microsoft online examples use both. Both are still marked as "In Development" in the readme and both are >1 year old since last check in.
The simplest way to deploy to an Azure Web App is to use the Azure Web App Deploy (AzureWebApp) task.
By default, your deployment happens to the root application in the Azure Web App. You can deploy to a specific virtual application by using the VirtualApplication property of the AzureRmWebAppDeployment task.
Azure App Service Deploy task allows users to modify configuration settings in configuration files (*.config files) inside web packages and XML parameters files (parameters.xml), based on the stage name specified.
Just my two cents, but I just noticed Web App Deploy takes much less time than Service App Deploy. I was wondering how come a simple zip deploy (Service App Deploy) can take so long. So I looked around and found there's also that Web App Deploy, so I tested it.
My project (React/Next small sized app) normally takes 6-10 min to deploy with Azure Service App Deploy (v4). With Azure Web App Deploy (v1) it took a little more than a minute. Wow.
I have a web app, and I've setup VSTS to create a package in build, and then deploy it using release management.
It puts all of the result in the wwwroot of the site if I look at it in ftp so I get:
/site/wwwroot/
/wwroot
/
This doesn't run and I get a 404 error.
If I use the URL and go say /wwwroot/images/ it returns it just fine.
The app is set to use .net core and I'm doing a self-contained package.
How do I get VSTS release to put the files in the right place and what is the right place ? I can't find any documentation on this anywhere. Everything is to do with Windows.
Also, what linux target should the dotnet application be set to for self-contained? I have it using ubuntu but I'm sure that's wrong and it's something else.
Please use Azure App Service Deploy task with 4.* (preview) version instead, and deploy again:
I had a similar issue and I responded here. Essentially you need to have a startup command pointing to your DLL because Dev Ops deploys the package in a different way than VS.
Deploying .Net Core to Linux WebApps on Azure with DevOps
I created a sample project using VS2017 "ASP.NET Core Web Application" with Angular.
Then in VSTS I built using Build Template: ASP.NET Core (Build ASP.NET Core Web Application targeting .NET Core). This built successfully and in the artifact section kept the build in a .zip file.
I would like to deploy it to a scale set. So for the Release section I used "Azure Virtual Machine Scale Set Deployment" template. While filling it out there is a field "Deployment Script field" which is mandatory. Not sure what this script is used for and how do i configure in it and where to source the script from.
TL;DR:
This script deploys the content of your deployment package on the virtual machine that you're preparing. In the case of an Angular ASP.NET Core app, this means that you will have to install IIS, the .NET Core Windows Server Hosting Bundle and copy your app to IIS.
Extra info
The Azure Virtual Machine Scale Set Deployment template creates an environment with two tasks:
Build immutable machine image
Azure VMSS: update with immutable machine image
Both tasks have a bunch of fields that need to be configured. Release Management allows you to link important fields to your process. This means that these settings are all grouped under the environment and can be easily set without going through the tasks.
If you look at the following screenshot you'll see that beneath the selected Deployment script field there is a line: This field is linked to 1 setting in 'Build immutable machine image'.
If you look at the documentation for the Build immutable machine image tasks you see the following for the Deployment script:
Deployment Script: Specify the relative path to the PowerShell script (for Windows) or shell script (for Linux) that deploys the package. This script should be within the deployment package path selected above. For example, Deploy/ubuntu/deployNodejsApp.sh. The script may need to install Curl, Node.js, NGINX, and PM2; copy the application; and then configure NGINX and PM2 to run the application.
So this is the script that will automatically deploy your application to a VM. In the case of an Angular ASP.NET Core app, this means that you will have to install IIS, install the NET Core Windows Server Hosting bundle and copy your app to IIS.
I would encourage you to first create an empty Windows Server 2016 VM and experiment with creating a script that prepares the VM and installs your app. Once that's done, you can reuse this script in the Build Image task in VSTS to automate VM and image creation and use that image for your Scale Set.
UPDATE
Your VSTS Build produces an artifact. In your scenario, you are already publishing the zip file with your web application. You can configure the Publish Build Artifacts task to also publish any deployment scripts you want to use during your release. These scripts should be stored in version control. The whole artifact, including your zip file and any deployment scripts you add, is used as input to your Release Definition. The zip file contains your web app as a Web Deploy package that you need to deploy to IIS. This piece of documentation explains how to install Web Deploy and use it to deploy your app.
Our web site solution consists of frontend folder, where pure html/css/js application resides, and an ASP.NET WebAPI backend. I am setting up a TFS build for dev and qa environment.
Currently, I have made WebAPI backend to publish automatically via WebDeploy. Html/js fronend also has a site setup on a target IIS machine where I am trying to deploy to. But WebDeploy only works with ASP.NET sites. What mechanism I could utilize to copy files of fronend to target folder on IIS machine?
This might help:
http://www.incyclesoftware.com/2014/06/deploying-uncompiled-resources-release-management/
I haven't had a chance to test it myself yet.
I need to write a powershell script that would install my team's web application and all the web application's dependencies (ie: telerik, asp.net mvc3, third-party assemblies) with a single click of a button. Is this possible? Or does someone have to click "Next" to go through an installation wizard?
Sounds like a job for MSDeploy. This ships with PowerShell cmdlets (and a regular console executable.)
http://www.iis.net/download/webdeploy
Features
Seamless integration with IIS 7.0
Manager and Visual Studio 2010
interface for creating packages and
deploying them onto a machine, both
locally and remotely.
Seamless integration with the Web
Platform Installer to install
community web applications simply and
easily.
Web application packaging:
Ability to package a Web application
or an entire site, including the
associated databases.
Ability to package ACLs, COM, GAC and
registry settings.
Supports both live servers and zipped
packages as a source or destination.
Web application deployment:
Administrative privileges are not
required in order to deploy Web
applications.
Ability to add powerful parameters to
change text in files when they are
deployed (such as prompting to
replace a connection string when
deploying from QA to staging
environments).
Integration with the IIS 7.0 Web
Management Service (WMSVC) for remote
deployment by non-administrators.
Server administrators have granular
control over the operations that can
be performed and can delegate tasks
to non-administrators.
Web server migration and synchronization:
Ability to synchronize or migrate the
entire Web server, a Web site or
application. Synchronizes only the
data that has changed.
Ability to detect missing
dependencies during synchronization.
Automatically gathers content, IIS
configuration, SSL certificates and
ASP.NET configuration when you sync a
Web site.
In addition to the IIS Manager and Visual Studio 10, tasks can be performed using the command-line or public APIs.
-Oisn