My Solution consist of two projects:
-One is a regular asp.net mvc web front end
-a webapi...
When i use azures "Deployment Options" or "Continuos Delivery Preview" I cannot choose which one i want to make available at that specific slot/app.
I don't know why but the web app is always the one that gets deployed.
I already tried setting the default start-up project
How can I do that?
How can i tell azure which project to use on that slot/app?
is that a in-solution configuration?
I managed to do it by setting up the project publish on the build definition. The box becomes available once you uncheck the "publish web projects"
Related
I would like to publish an ASP.NET Core 2.1 website to Azure using an Azure Web App to host it. When creating the Azure Web App on the Azure portal, one of the settings is "Runtime Stack". In this case I would set it to ".NET Core 2.1" to match the framework my code is currently using. However once the web app is created, I do not see an option to edit this setting anywhere on the Azure portal, so how would I change it if necessary in the future?
For instance, if I were to later update my application code to use ASP.NET Core 2.2, how would I change the runtime stack of the Azure web app to ".NET Core 2.2"? Is there a setting to edit this in some area of the Azure portal? Or does the Azure web app look at the code (possibly the .csproj file), and automatically update the target framework internally, thus ignoring any settings anyway? Or would I need to delete the web app and create a new one with the correct settings? (If I would need to delete the web app and create a new one, is there some recommended approach to plan for this situation and reduce downtime? Would it be possible to update the staging slot to a newer runtime stack from the production slot, and then do a swap?)
At least for Linux hosts, the runtime stack is available via the app service settings - it is just split up into multiple properties:
On a more technical note, it can be accessed via LinuxFxVersion:
"siteProperties": {
"metadata": null,
"properties": [
{
"name": "LinuxFxVersion",
"value": "DOTNETCORE|2.1"
},
{
"name": "WindowsFxVersion",
"value": null
}
],
"appSettings": null
},
E.g. via Azure CLI:
az webapp config set -g MyResourceGroup -n MyUniqueApp --linux-fx-version DOTNETCORE|2.1
If you want to avoid downtimes, you should use slots like you mentioned. Like every app deployment, you will have a very slow application for a short while during the deployment.
Changing everything in one go is possible if you use something like Azure Pipelines. The Azure App Service Deploy Task allows you to both deploy the application an set the runtime stack at the same time.
Slots are very much independent from each other, so you can have different runtime stacks depending on the slot.
Step 1 - Set the target framework for the project
In the project set the target framework to the one you want. In VS, right click the project name, choose Properties, then specify the target framework.
Or directly edit the .csproj file to specify target framework, using the following syntax
<TargetFramework>netcoreapp3.1</TargetFramework>
Step 2 - Set the target framework for publishing
When publishing the project, set the target framework there as well. In VS, right click the project name, choose Publish, and in the publish wizard specify the target framework.
This setting will be reflected in the .pubxml file as well (and can be edited there instead if you prefer using the syntax <TargetFramework>netcoreapp3.1</TargetFramework> )
Step 3 - Check that the runtime you need is present on Azure
If the runtime version specified in the project and publish settings is present on Azure, then that version will be used automatically. So we need to check if it is present.
Alex described how to do this on Linux hosts in his answer but that does not work on Windows hosts (the 'Major Version' and 'Minor Version' settings are not displayed for Windows hosts on the Azure portal).
The Kudu console on the other hand works for both operating systems. Kudu can be reached at https://<app_name>.scm.azurewebsites.net. There are a couple of different ways to look up runtime versions Kudu -
Option 1. Click the 'Runtime versions' link in the Rest API section.
It will
display the supported dotnetcore versions (and also nodejs versions,
os version, etc).
Option 2. Click Debug Console -> CMD to launch the kudu
command prompt. Type in dotnet --list-runtimes.
(Do not use dotnet --list-sdks because what is important is the runtime, not the sdk, since the sdk is needed for building an app and most likely you will build the app on your local machine before publishing to Azure).
Step 4 - If the runtime is not present on Azure
This might be the case if the runtime you are using is still in preview. You can either embed your own .net core version with the application or you can use an extension. These are described by Sebastien in his answer.
Step 5 - Publish the app
There is no need to delete the existing web app and create a new one. You can publish to an old app that was previously using a lower target framework.
Previous answer is correct, you can manage runtime version in Application Settings Configuration.
But, you can also run dotnet publish --runtime win-x86 to embed your own .Net Core version with your application.
It adds some overhead but you control runtime version.
.NET Core RID Catalog
A third option is to install a Site Extension
I am setting up a release for the first time in 2018 Release Management. We have a website that we want deployed to IIS.
The build definition is setup and has created the artifacts. When I setup the release definition I select the IIS Website Deployment template which gives me two tasks.
IIS Web App Manage
IIS Web App Deploy
They seem to cover similar ground, but I cannot find documentation to tell me how they are different. Do I need both?
When I configure IIS Web App Deploy, the Website Name field is grayed out. The link icon tells me
This setting is linked to the 'Website name' (Parameters.WebsiteName)
process parameter.
So I created the process parameter in the release definition and the build definition with a different name. However the Website Name does not update. Is there a way to manually edit this field?
In short:
IIS Web App Manage
This task does provisioning, for example creating an IIS Web Site and Application Pool. Typically this is only needed the first time deploying to a target machine, but there is no harm in running it on every deploy, since it then just skips creating already existing items.
IIS Web App Deploy
This task deploys your code.
You need to create a Deployment Group before using the IIS Website Deployment template. Deployment groups in VSTS/TFS make it easier to organize the servers that you want to use to host your app. A deployment group is a collection of machines with a VSTS/TFS agent on each of them. Each machine interacts with VSTS/TFS to coordinate deployment of your app.
Useful link and blog for your reference:
https://learn.microsoft.com/en-us/vsts/build-release/archive/apps/aspnet/aspnet-from-vsts-to-windows-vm?view=vsts
https://abelsquidhead.com/index.php/2017/11/28/build-and-deploy-to-multiple-iis-servers-and-sql-server-using-vsts/
If you don't want to use this template, you could also try other extensions, such as IIS Web App Deployment Using WinRM.
Both tasks are needed. The website name is set on the Environment level then referenced in all of the tasks within.
I'm trying to learn how to deploy Web Application to Azure using Visual Studio 2015. I could successfully deploy a simple Web Application (without creating any slot). I moved to the ARM portal and found that there isn't any slot. However, when I try to swap, I can see "production" as an option in the source & destination drop down lists.
I created another slot and then I tried to publish the Web Application again, but I could only see one slot, which is the newly created slot (please see the screen shot)
I'm a bit confused. According to my understanding, there should be a default slot which I can deploy specifically to it and then swap to/from it.
Any ideas?
As far as I know, the "TestWithDB20170822062605" application is your default application. You could directly select this web app. If you publish the application to this. It will be regard as production app.
If select the TestWithDBSlot2, it will publish the application to your newly created slot.
Firstly, if you select the "TestWithDB20170822062605" application, VS will publish the application to the TestWithDB20170822062605.azurewebsites.net.
This is according to the url not the slot or something else.
But if you swap the web app.
It will like this
TestWithDB20170822062605.azurewebsites.net --------> TestWithDBSlot2
TestWithDBSlot2.azurewebsites.net -----------> Production
So you will find you publish the application to the slot TestWithDBSlot2, but the url is still TestWithDB20170822062605.azurewebsites.net. This is according to the url not the slot name.
We have a VSO repository with multiple sites in the same solution. We want to be able to deploy our sites independently of each other to Azure with continuous delivery. Right now the first site alphabetically is deployed to all our sites which of course is not desirable.
Is this possible to achieve?
I have tried to set the Project key to the correct csproj in App Settings like suggested here: https://github.com/projectkudu/kudu/wiki/Customizing-deployments without any success. Maybe Kudu is not used for VSO?
Any help would be greatly appreciated!
You should move away from trying to do this in a build, especially if you want that level of control.
You have Release Management Online provided with your VSO account and can use the Release Management client to configure your releases.
I believe that you can right-click on your Build and have an appropriate starter release template created when configured.
http://nakedalm.com/create-release-management-pipeline-professional-developers/
Here is an example of and end to end deployment with a web app. Deploying to Azure with RM is Childs play...
Currently our developers deploy our Mobile Service (.Net backend) from Visual Studio 2013 using the Publish Wizard. Occasionally this means that a developer deploys something that either wasn't committed at all or wan't pushed to the origin source control repository. We are already using Visual Studio Online Build servers to do Continuous Integration from the origin server so it would make sense to use the files it builds to do the deployment to remove this risk.
Currently the only way I can see of doing this is to do a "download drop as zip" from the Visual Studio Online build portal and then do a FTP style deployment. This means I lose the web deploy features of only uploading the changes.
I noticed there is a different build template called GitContinousDeploymentTemplate which allows you to specify a Windows Azure Deployment Environment, but this seems to only be applicable for traditional Cloud Services or Web sites.
If anyone knows a good way of doing this any help would be much appreciated.
Cheers
F
From here
Found a solution.
In the build definition's MSBuild arguments, add the following:
/p:DeployOnBuild=true /p:PublishProfile="{publish name}"
/p:AllowUntrustedCertificate=true /p:VisualStudioVersion=12.0
/p:UserName={username} /p:Password={pw}
You can obtain the value from the publishing profile that can be downloaded from the
Mobile Service dashboard on Azure managament portal.
Under Deployment, add the path to pubxml file in source control under "Path to Deployment Settings". Note: add an extra backslash at
the end of the path to escape the last "\".
One problem with this solution is that deployment happens regardless
of your tests outcome, but that could possibly be remedied by
modifying the build template. We used the
GitContinuousDeploymentTemplate template in our case.