I've currently got an ASP.NET Core web application with EF that I am deploying to GearHost (a non-Azure cloud platform that was recommended by a user here) using a web deploy publish profile directly from Visual Studio. I'm looking to get CI/CD set up via VSTS so that the publish ability isn't restricted to one machine.
So far I've got the build stage set up, as the .NET Core template is all that's really needed. It's the deploy part that has got me stuck - all the templates (and indeed articles) that I can find relating specifically to .NET Core are focused on Azure or an IIS deployment, neither of which are really applicable here, and indeed Azure uses deploy tasks that are created specifically for it.
If it's relevant, GearHost provides FTP credentials which could potentially be used for a manual copy. Alternatively, is there any way I could use the VS2017 publish profile to create a release definition including appsettings.json transforms and EF migrations?
There are many ways to deploy app to GearHost server, such as FTP, Publish Profile.
So, you can upload the published files (e.g. Create a publish profile with file system publish method) to GearHost server by using FTP Upload task.
You also could download the publish profile with Web Deploy method and import to VS, then deploy app by using this publish profile. (MSBuild Arguments: /p:DeployOnBuild=true /p:PublishProfile=[publish profile file name])
Regarding appsettings.json transforms, you don’t need to transform appsettings.json file, the .net core project can retrieve the values from appsettings.[environment].json file per to the value of ASPNETCORE_ENVIRONMENT system environment variable. Working with multiple environments
Regarding EF migrations, you can configure it in publish profile and publish/deploy app with that publish profile.
Update:
Steps to call GearHost cloudsite:
Log in GearHost
Click API tab >Create a new API Key
Using Invoke-RestMethod
Simple code:
$url="https://api.gearhost.com/v1/cloudsites/[could site id]/stop"
$APIID="[step 2]"
$result=Invoke-RestMethod -Method POST -Uri $url -Headers #{Authorization=("bearer {0}" -f $APIID)} -ContentType "application/json"
Related
I'm trying to migrate an old azure deployment that was previously run on windows and relied on using msdeploy into our CICD pipeline that is using a debian dotnet sdk. Is there a easy way to do this with a publish profile? I can no longer use the old MSDeploy profile, and it appears that using an FTP profile is not supported through the cli, it will only generate a local release folder.
My goal is to be able to call the follwing without additional steps
dotnet publish WebService/WebService.csproj -c Release /p:PublishProfile="sandbox"
I tried converting to an FTP profile using the ftps credentials in azure, however it only publishes into a local folder on the runner when using this profile.
I have a fully working web api written in dotnet core 3.1. I've been following the TimCoRetailManager series.
The application builds with no errors and works as intended when running in Visual Studio. I have a free azure subscription. I setup a F1 free web app service on linux and two basic SQL server databases, all in the same resource group with the firewall set to allow access to other azure services to connect. I can publish the web api and the databases. I can connect to the databases with azure data studio and things look fine. I updated the config on the app service so it's using the azure secrets instead of my dev environment secrets. The API works as intended when published from Visual Studio, i can get to the swagger ui, and life is good.
On to Azure DevOps. When I use a release pipeline from Azure DevOps, the pipeline gives a success message. However, when I navigate to the API (has a simple MVC landing page + swagger) it just has an "Application Error :(" page. I found the logs on the Azure App service and they have this...
Ok 2022-03-01T21:44:43.8098649 \/ \/ \/
Ok 2022-03-01T21:44:43.8098677 A P P S E R V I C E O N L I N U X
Ok 2022-03-01T21:44:43.8098704
Ok 2022-03-01T21:44:43.809873 Documentation: http://aka.ms/webapp-linux
Ok 2022-03-01T21:44:43.8098757 Dotnet quickstart: https://aka.ms/dotnet-qs
Ok 2022-03-01T21:44:43.8098784 ASP .NETCore Version: 3.1.21
Ok 2022-03-01T21:44:43.809881 Note: Any data outside '/home' is not persisted
Ok 2022-03-01T21:44:44.3985103 Running oryx create-script -appPath /home/site/wwwroot -output /opt/startup/startup.sh -defaultAppFilePath /defaulthome/hostingstart/hostingstart.dll -bindPort 8080 -userStartupCommand 'dotnet TRMApi.dll'
Ok 2022-03-01T21:44:44.4498212 Cound not find build manifest file at '/home/site/wwwroot/oryx-manifest.toml'
Ok 2022-03-01T21:44:44.4499139 Could not find operation ID in manifest. Generating an operation id...
Ok 2022-03-01T21:44:44.4500119 Build Operation ID: 74cf02f2-a6c2-44a8-9077-95f1bab9d974
Ok 2022-03-01T21:44:45.5344493
Ok 2022-03-01T21:44:45.5358264 Agent extension
Ok 2022-03-01T21:44:45.5358438 Before if loop >> DotNet Runtime
Ok 2022-03-01T21:44:46.2152908 DotNet Runtime 3.1Writing output script to '/opt/startup/startup.sh'
Ok 2022-03-01T21:44:46.6953451 Running user provided startup command...
Ok 2022-03-01T21:44:46.7448258 It was not possible to find any installed .NET Core SDKs
Ok 2022-03-01T21:44:46.7453653 Did you mean to run .NET Core SDK commands? Install a .NET Core SDK from:
Ok 2022-03-01T21:44:46.7457829 https://aka.ms/dotnet-download
The build pipeline appears to be working as intended. It produces four artifacts: a folder for the web api with a zip for deployment, a folder for the database stuff notably with a dacpac, and a folder for the front end with a zip file in there, too. The release pipeline isn't publishing all of this though. I set the package to $(System.DefaultWorkingDirectory)/_Standard Continuous Integration Build/ApiDrop/TRMApi.zip.
The release pipeline has the following settings:
Azure subscription: selected free trial and authenticated it
App Type: Web App on Linux
App Service name: selected api's name from drop down
Startup command: blank
Agent Job
Agent: Azure Pipelines
Agent Specification: windows-2019
Artifact download: continuous integration build > selected all artifacts
Deploy Azure App Service step
Task version: 4.*
Connection type: Azure Resource Manager
Azure subcription: read only, prefilled by app service selection earlier
App service type: also read only, prefilled
App service name: also read only, prefilled
Package or folder: $(System.DefaultWorkingDirectory)/_Standard Continuous Integration Build/ApiDrop/TRMApi.zip
Runtime Stack: 3.1 (DOTNETCORE|3.1)
Any tips or suggestions? I'm really scratching my head on this. I'm watching videos on pluralsight and youtube and it seems like the process "just works" for the content creators, but I'm not able to repeat the results.
Edit: Including screenshot of how artifact is configured in release pipeline.
FWIW, I have the exact same problem from the exact same code base.
I also have the build pipeline artifact set up correctly.
I initially got caught up on the message "It was not possible to find any installed .NET Core SDKs".
I went to the app service "Advanced tools" and then used Bash and issued the commands:
dotnet --list-sdks
dotnet --list-runtimes
Initially, it wasnt reporting any sdk's.
This led to me adding an additional Use.NET Core pipeline task at the beginning of the pipeline with the following parameters
Display Name:
Use .NET Code sdk 3.1.415
Package to install:
SDK (contains runtime)
Version:
3.1.415
Compatible Visual Studio version:
16.7.21
Path to Install .Net core:
$(Agent.ToolsDirectory)/dotnet
I chose the above versions which seemed to match what was reported being available on the linux box.
However, none of this seemed to make any difference, as it still fails with the same error as you. I did want to share what I have tried so far, but wasnt enough to solve it.
On a whim, I spun up a Windows-based App server (Free tier) to deploy to as well. I modified my Release pipeline and added a second "Deploy to App Service" step. This second one deploys to the Windows App Service.
Once I did this, the app runs successfully on the Windows App Service after the second deployment step, but not on the Linux app service after the first deployment step.
It turns out the issue was due to a Build pipeline issue.
It was building the API project using a Visual Studio Build (i.e. MsBuild) project step.
In order to target linux, this needs to be replaced with a
dotnet publish (or a dotnet build followed by a publish) with the parameters "-r linux-x64" plus the appropriate output folder.
Build pipelines and release pipelines do not use the same system default working directory. So I think your release pipeline is probably not getting the artifacts in the build pipeline.
There is an easy way to pass artifacts generated in build pipelines to release pipelines:
In your build pipeline, Use publish build artifact task or publish pipeline artifact task to publish your artfact.
In your release pipeline, click "Add an artifact". Then select "Build" as source type and fill in the information about your build. Note the value of "Source alias", which you need to use as the name for artifacts in release pipeline.
Go to the "Azure App Service Deploy" task. In "Package or folder", click browse button, and you can find your artifacts path there.
I have a hard requirement from the developer to use a website project instead of a web app project for a .net deployment. I am able to connect and use continuous integration just fine with a web app project, but when using website, it fails to find the compiled files for deployment:
#[debug]check path : D:\a\_tasks\PublishBuildArtifacts_2ff763a7-ce83-4e1f-bc89-
0ae63477cebe\1.142.2\task.json
##[debug]set resource file to: D:\a\_tasks\PublishBuildArtifacts_2ff763a7-ce83-4e1f-bc89-0ae63477cebe\1.142.2\task.json
##[debug]system.culture=en-US
##[debug]PathtoPublish=D:\a\1\a
##[debug]check path : D:\a\1\a
##[debug]ArtifactName=drop
##[debug]ArtifactType=Container
##[debug]system.hostType=build
##[warning]Directory 'D:\a\1\a' is empty. Nothing will be added to build artifact 'drop'.
Looking at the build process, it's compiling a copy of the deployment to the PrecompiledWeb folder instead of the debug folder, which seems to explain why it cannot find the results. Has anyone had luck deploying with a website project or have you run into the issue above?
Azure DevOps Continuous Integration with asp.net website project instead of web application
Since the project is asp.net website, you may need use the website.publishproj file instead of the .sln file when you publish the asp.net website project with MSBuild.
The command line like:
msbuild.exe "<PathToTheFile>\website.publishproj" /p:deployOnBuild=true /p:publishProfile=WebsiteTestDemo /p:VisualStudioVersion=1x.0
With this setting, MSBuild does not create the PrecompiledWeb folder and the publish uses the setting in the profile.
Check my previous thread for some more details.
The website project the publish process is not plumbed into the build
process. For website project since there is no formal build process
there was nothing for us to really extend.
Hope this helps.
Problem
Getting a deployment error when trying to publish to an Azure Web App from TFS CI. A file is locked and this prevents the build from updating.
Symptoms
Publishing manually (Web Deploy publish from within Visual Studio) usually succeeds.
Stopping the Web App and publishing allows it to succeed, however this defeats the point of our CI if we need need to stop and start the Web App each time.
CI publish to Web roles and Worker roles don't appear to have this issue, we only get it on publishing to Web Apps (formerly Web Sites, the current Azure Portal term is now App Service).
Only publishing from a CI build via TFS fails consistently in this way.
Error
Web deployment task failed. (Web Deploy cannot modify the file
'msvcr100.dll' on the destination because it is locked by an external
process. In order to allow the publish operation to succeed, you may
need to either restart your application to release the lock, or use
the AppOffline rule handler for .Net applications on your next publish
attempt. Learn more at:
http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.)
The information at the link isn't very helpful.
ERROR_FILE_IN_USE
Diagnosis – A destination file cannot be overwritten or deleted because it is currently in use.
Resolution – Make sure that the destination file is not in use before performing a sync. If you are syncing content to a web site
hosted on IIS 7 or later (using the appHostConfig, iisApp, or
contentPath providers), consider taking the application offline during
the sync by enabling the appOffline rule.
Attempted resolutions
We were using New Relic - have since removed New Relic and this issue still persists. The binary appears to be a Microsoft library but it's unclear how it is relevant to the application (it's not referenced).
Some other SO questions have addressed similar issues with publishing but none of these relate to getting this issue from TFS CI.
azurew website continious deployment - Web Deploy cannot modify the file 'XXX' on the destination because it is locked by an external process
How to take web app offline while publishing?
One answer in the above question suggests using the EnableMSDeployAppOffline configuration in the publish profile, and adding this configuration works OK for doing a publishing manually from within VS but it doesn't fix the problem when publishing automatically from TFS/CI.
Edit
How to take web app offline while publishing? deals with taking the app offline using the EnableMSDeployAppOffline configuration - unfortunately this config only seems to be supported when doing WebDeploy through Visual Studio (not CI).
You can use the Web Deploy v3 in CI to deploy your web app.
In Web Deploy V3, we added support to automatically take an ASP.Net
application offline before publishing to it. This is useful if a user
wants to ensure that their application does not have a lock on a file
(e.g. SQL CE sdf files which only allow one connection to the file at
a time) being overwritten, or if they want to ensure that visitors to
their site cannot affect the publish process. When the publish process
is completed, the App_Offline.htm file will be removed and the site
will be online again.
Or you can add a PowerShell script like following to deploy the web app to Azure:
param($websiteName, $packOutput)
$website = Get-AzureWebsite -Name $websiteName
# get the scm url to use with MSDeploy. By default this will be the second in the array
$msdeployurl = $website.EnabledHostNames[1]
$publishProperties = #{'WebPublishMethod'='MSDeploy';
'MSDeployServiceUrl'=$msdeployurl;
'DeployIisAppPath'=$website.Name;
'Username'=$website.PublishingUsername;
'Password'=$website.PublishingPassword}
Write-Output "Stopping web app..."
Stop-AzureWebsite -Name $websiteName
Write-Output "Publishing web app..."
$publishScript = "${env:ProgramFiles(x86)}\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\Web Tools\Publish\Scripts\default-publish.ps1"
. $publishScript -publishProperties $publishProperties -packOutput $packOutput
Write-Output "Starting web app..."
Start-AzureWebsite -Name $websiteName
Reference from: https://msdn.microsoft.com/en-us/Library/vs/alm/Build/azure/deploy-aspnet5
The new "Deploy AzureRM Web App" task has an option to take the app offline which will prevent this error.
See screenshot for checkbox
I have an MVC4 web application that uses jquery and some other libs (jquery-ui in particular).
Yesterday I decided to update all the packages via NuGet package manager; my web application worked correctly on my local machine, but when I deployed it to my azure website a javascript error popped out in my browser (it was related to jquery-ui library, something like "$browser is not a function").
I searched the web and found out that the cause of this error was that I was still using an old version of jquery. It seems that deploy process didn't publish the new version of the js libraries even if they have been updated in local project.
I solved the problem connecting via RDP to the Azure machine, deleting the contents of "Scripts" folder and deploying again, but I'm wondering if there's a way to "force" script/libraries update when deploying to Azure.
Edit 1: I'm developing with Visual Studio 2012, using Mercurial as source control provider
Edit 2: I'm deploying to Azure Web Sites
Please, in your future questions clearly indicate what type of Azure Service do you use. An MVC4 web application can be deployed to 3 different type of services: Azure Web Sites, Azure Cloud Service, Azure Virtual Machine!
Since you are talking about RDP, the viable options are Cloud Service or Virtual Machine. But then you say
I solved the problem connecting via RDP to the Azure machine, deleting
the contents of "Scripts" folder and deploying again, but I'm
wondering if there's a way to "force" script/libraries update when
deploying to Azure.
Now the question is how you do deploy to Windows Azure? Is it via Visual Studio's Publish feature to Azure Cloud Service. Is it Visual Studio's Package feature and then using any other method of deployment (upload the package from the portal, use Azure PowerShell cmdlets, or use third party tool to deploy the package)? Is it integration with Mercurial and deployment is done automatically when you check-in?
Any any case, the issue you face is a mixture of NuGET failing to do real clean update of everything. Browser caching - especially for local development - IE caches all the scripts, CSS and images and it is hard to say (without explicitly deleting all locally cached files) which script are you actually using. Simple version control issue - keeping old and new scripts.
When you do a JS/CSS updates I strongly advise all the customers to first delete all browser's cache (crtl+shift+del - works for all browsers) before testing locally.
I highly doubt that if you use a Cloud Service, RDP-ing and deleting anything in the sitesroot folder will help you when you redeploy. What you do in the ROLEROOT drive (usually E:, sometimes F: drive) is dropped of/forgotten when you re-deploy regardless of the re-deploy method you use: in-place-upgrade or full re-deploy. So what you did is actually creating new package and re-deploying your new package.
The fact that you deleted some folder has no effect on your re-deploy action.