I have my ASP.NET Core + Angular WebApp uploaded to GitHub(through VSTS) and now I would like to set up the CI pipeline. After that I would like to deploy my app to Azure.
In the template section - there is an ASP.NET Core template, but also an Azure Web App template.
Considering my case which is better suited for this case?
I found the almost perfect working answer in Levi Fuller's blog.
You can get it working with a minor change: unlike what Levi states, you really need only a single npm task
set up the npm task
by clicking the three dots button -> set the Working folder with package.json to your folder that contains the package.json file.
set up the Azure App Service Deploy
by clicking the three dots button -> set the Package or folder to your folder that contains the .csproj file.
There isn’t the build template that you use directly, the template is convenient to use, you need to modify it per to detail requirement.
Refer to these steps:
Go to build page of team project (e.g. https://XXX.visualstudio.com/[teamproject]/_build)
Click +New button to create a build definition with ASP.NET Core template
Add npm install task before .NET Core Restore task (Command: install; Working folder with package.json:[package.json folder path])
(optional) Delete/disable .NET Core Test task if you don’t need
Add Azure App Service Deploy task at the end (Package or folder: $(build.artifactstagingdirectory)/**/*.zip; Check Publish using Web Deploy option)
Note: you can move step 4 to release and link this build to release (change package or folder to $(System.DefaultWorkingDirectory)/**/*.zip).
Related
I would like to create an installer for my self-hosted service written in .NET Core 3.1. I'm using Visual Studio 2019 so I had to install VisualStudioClient.MicrosoftVisualStudio2017InstallerProjects and this allowed me to create Setup Project.
So, everything now works ok, except that I can't run any code during the installation! In standard .NET Framework there was Installer class that enabled me to inject some functions, like "register and start service". But .NET Core has nothing like that!
So how can I run extra C# code after the installation is finished?
It turns out that Installer class is not supported anymore and probably won't be in foreseeable future.
The workaround is to you the service exe itself as as a host for custom code, run be parameters.
Steps:
In the Solution, where your .Net Core service lies add the "Setup Project" project. (it must be the same solution)
Go to File System -> Application Folder and add PublishItemsOutputGroup
Go to custom actions view and add a custom action PublishItemsOutputGroup to Install with your exe name selected. (e.g. it should say (name) PublishItemsOutputGroup from MyApiService (Active))
Set arguments to /my_Install
Go you form Main in the service and add something like:
if (args.Length == 1)
{
File.AppendAllText("test_install_ca.txt", args[0]);
return;
}
Once you run it, you will find test_install_ca.txt in System32 dir with the content /my_Install
I have a standard way of working for building and deploying my asp .net applications on a build server (usually Jenkins). I have a custom build script and publish profile that builds my solution, copies some files and publishes the web project all with a single call to MSBuild.
I am trying to recreate this in Azure DevOps. My first obstacle seems to be that build and "publish" (or "release" in DevOps parlance) are separate steps. But it also seems like maybe I don't need to "publish"?
So
How do I control what ends up in the "artifacts" folder of the build? Is that through Azure? Can I do it with a .MSBuild file? And
Do I even need the concept of "publish" or does the release step just copy all artifacts to the destination (a VM in this case)? Can I control what gets deployed?
I am having a hard time finding some kind of basic tutorial that cover asp .net projects being deployed this way.
How do I control what ends up in the "artifacts" folder of the build? Is that through Azure? Can I do it with a .MSBuild file?
Yes, we could use the MSBuild Arguments parameter /p:PackageLocation=$(build.artifactstagingdirectory) to control what ends up in the "artifacts" folder.
When we use the task Visual Studio build to build the project, we could edit the MSBuild Arguments parameter to be like: /p:DeployOnBuild=true /p:PublishProfile=Test /p:PackageLocation=$(build.artifactstagingdirectory)
Then we could use Publish Build Artifacts task to publish build artifacts to Azure Pipelines, TFS, or a file share.
Do I even need the concept of "publish" or does the release step just copy all artifacts to the destination (a VM in this case)? Can I control what gets deployed?
Yes, you can simply understand the release step just copy artifacts to the destination. If you want to control what gets deployed, you can filter the artifacts when you use the copy task with contents.
Check the article Deploying Web Applications Using Team Build and Release Management for the details.
Hope this helps.
If you have existing scripts that work, just use those :). The new YAML builds are moving slowly away from fully featured UI tasks with lots of logic to more bare bones scripts that do what is needed.
It is a common practice though to split build from publish. That way you can put in additional checks, reviews and approvers on the release stage.
In your case it would mean:
Build stage
Use MsBuild to build & create a publish package either in the form of a folder or a zip file.
Use the Publish Pipeline Artifact task to store this folder or zip file
Release stage
Use the Download Pipeline Artifact task to restore the file to publish
Optionally use a Infra as Code tool to prep the target environment.
Use msdeploy.exe or another tool to publish the package. Optionally generate and pass in a settings file to override certain settings.
This way you can have multiple release stages to generate test environments, temporary POC environments etc by simply using another set of variables and/or settings override file.
There are special tasks in Azure Pipelines that wrap around these tools and provide an easy to use UI and some additional logic. These can be very useful if you don't have intimate knowledge of the commandline tools. If you do know your way around them, there may not be a very strong reason to use the fancy tasks.
I'm doing a web site deployment in azure with bit bucket source.
When I do the deployments I can see always its building the source,
Actually that is not required to me, because it is a Kentico 10 web site (.Net website project).
How do i avoid building while source deployment/ pull the latest from bitbuckt ?
You should stop using continuous integration process in bitbucket and hook your own process to do a xcopy (preferably delta) to target website folder.
Using the OOB tools it is not possible to deploy without a build. So you can do a few things:
FTP
Visual Studio publish
command line copy after a successful build locally.
Another setup could reduce the number of builds you have when deploying but will still build the solution, more branches in Bitbucket.
You could continue to use CI but make sure you hook your environments to proper branches so they only deploy when you perform a merge into that branch.
How do i avoid building while source deployment/ pull the latest from bitbuckt ?
You could check the deployment details under "DEPLOYMENT > Deployment options" as follows:
And you could leverage KUDU and check the auto-generated deploy.cmd file under D:\home\site\deployments\tools\deploy.cmd.
For your requirement, I would recommend you customize your deploy.cmd file, and put .deployment and deploy.cmd files into your Bitbucket repository. For a simple way, you could just download your current deployment script and modify the scripts under the Deployment section, you need to remove the script for building your solution and just leave the script for kudu sync, and you need to modify the value for the -f option from "%DEPLOYMENT_TEMP%" to "%DEPLOYMENT_SOURCE%" when invoking the %KUDU_SYNC_COMMAND%. Details you could follow Custom Deployment Script.
If you want to deploy the full content of your repo with no build or transformation at all, just set SCM_SCRIPT_GENERATOR_ARGS=--basic in the Azure App Settings. This will force the script generator to treat is as a 'basic' site, and won't do any build.
See wiki for more info.
I have done a fair amount of research for publishing and deploying web apps with VSTS and so far I have found the following:
1.Use .pubxml files and pass the DeployOnBuild = True to MSBuildArguments
2.Copy and publish Artifacts and create a separate release definition.
We are currently using the first method, but found that the build can be marked as successful but the publish fails (in our case it was a bad transform)
So we decided to look into separating the publish step and to create a release for our changes.
The issue I am running into is that the copy files and publish artifacts step only copies DLLs and our .js and .html/.css changes don't seem to make it to the UI. As a work around I added these params to the Copy Files method but it is taking a long time to publish. (There are no issues with the release definition)
**\*
!$tf\**
**\!$tf\**
**\!Debug\**
**\*!pdb
All the guides online for using the Publish Artifacts and creating a separate release definition seem to say the same thing, and only push Dlls from the bin folder to the IIS server.
Here is my build definition:
So my question is, why aren't UI changes being deployed to the website when the release completes if this isnt an issue anywhere else?
No, not really. We usually not only publish DLLs and our .js and .html/.css as build artifacts, but for the whole web app.
The Visual Studio Build task usually with the MSBuild Arguments as (if you use ASP.NET build template, it's the default setting):
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\"
In this way, the web app (published files) will be copyed to $(build.artifactstagingdirectory) directly. So you don’t need the Copy Files task.
If you need to deploy all files, you can use ** in Copy Files task.
Then when you deploy the app to IIS server in release definition, the whole web app in build artifacts will be downloaded.
I am using a "web site" in visual studio 2008, and i would like to add a post-build event which would append the build time to the web.config file. Is it possible?
I'm afraid this isn't supported for web sites, you'll need to use a web application project.
One of the major benefits of going the WAP (Web Application Projects) route rather than WSP (Website Projects) is that you get the ability to have Post Build events.
Therefore, it is not possible out of the box anyway. Here is the detail.
Add a separate (empty) project (".buildstep"), to which you add your custom build step - you'll have to specify target folders to the main web project, but make use of the predefined environment variables (like $solutiondir, $platform, $mode etc).
Add a dependency to this new project from the main web project (Project | Project Dependencies).
Rebuild + verify build step has been carried out. You're done.
;o)
Maybe it is no relevant, but you can customize start options (make it run script/command) though it will be triggered only when you Launch project (Dubug -> Start).
One possible solution is creating an empty dummy C#/VB project without any files, and adding the necessary batch script as post build event there. Then, you can build that "project" right after you publish the web site - an extra mouse click but still better than running things manually. I went this route for our deployment packaging and it works great.
You can create publish profile for Web Site type applications.
*.publishproj should be created.
Then you can add there post and pre build commands as Targets.
<Target Name="BeforeBuildTarget" AfterTargets="BeforeBuild">
<Exec Command="cmd.exe"></Exec>
</Target>
<Target Name="AfterBuildTarget" AfterTargets="AfterBuild">
<Exec Command="cmd.exe"></Exec>
</Target>