After the initial attempt to publish my web app to Azure I got the following error. I'm using Visual Studio 2019.
Is there a way to undo the publish?
How do I determine what is missing?
The configBuilder 'Secrets' failed while processing the configuration section 'appSettings'.: 'Secrets' Initialization Error: Method not found: 'System.String Microsoft.Configuration.ConfigurationBuilders.Utils.MapPath(System.String)'.
How do I undo the changes that Publish did within my project:
Approach-1:-
Generally, Azure Web Apps provides back up feature which you may enable in your app to keep a backup of your site. If you are sure that the deployment did not go as planned, you can restore the backup.
Goto App Service -> Choose BackUps
You can see the status of the webapps for every hour as shown here:
Click on Restore icon if needed.
Enter the restore location in Choose a location. Select Create new under the App Service box to restore to a new app. Select Create new beneath the Deployment slot box to restore to a new deployment slot.
You can choose the site configuration as well as per requirements. After providing all these, restore it.
Approach-2:-
Usually after publishing any web app to azure from local, it will be deployed on production server.
You may want to undertake some activity or verification before delivering/after delivering the website to production. You can use deployment slots in this case.
Azure provides non-production deployment slots for each web app, on which we can deploy the website temporarily.
Detailed in article given by #Krishna Kumar.
Create deployment slot by adding a slot under app service as shown:
Alternative Reference: Get publish profile
Related
If I select Deployment Option, VSTS as a source is not available. The option was available for the other app service I created using this account. But I come back from lunch and now I can't select VSTS as a source for deployment option. I've tried deleting and re-creating the app service. Logging in on another browser and nothing. If I select the Deployment Center (Preview) option, it DOES see my VSTS repos. So what gives?
I have a working app service named "matanwebserver" over a subscription in Azure.
This is a website that I am working on. I work with Visual Studio and I wrote my code inside this app service in Visual Studio.
Now I want to create an Integration site so I can test my code before publishing to the production site.
For that, I created a new app service in azure under the name "matanwebservertest" and I want to use the code I wrote for "matanwebserver" over the new app service that I just created.
I could not find any source which provides a solution, so thanks in advance.
Added some screenshots for a better understanding of the issue
In Visual Studio I do right click on the web app which is called "MatanWebServer" and choose "publish".
Then I choose the new web app that I just created on Azure portal which called "matanwebserertest", and publish successfully.
enter image description here
This is the original (production) website. which its address is http://matanwebserver.azurewebsites.net
enter image description here
After publish to the matanwebservertest web app, I expect to see a "copy" of the original site, but it seems like nothing is there.
enter image description here
To get the current app cloned to the new one, have a look at the 'Clone App' option.
What you're trying to do feels like a perfect example to use for using Deployment Slots Please refer to Set up staging environments in Azure App Service.
When you deploy your web app, web app on Linux, mobile back end, and API app to App Service, you can deploy to a separate deployment slot instead of the default production slot when running in the Standard or Premium App Service plan tier. Deployment slots are actually live apps with their own hostnames. App content and configurations elements can be swapped between two deployment slots, including the production slot. Deploying your application to a deployment slot has the following benefits:
You can validate app changes in a staging deployment slot before swapping it with the production slot.
Deploying an app to a slot first and swapping it into production ensures that all instances of the slot are warmed up before being swapped into production. This eliminates downtime when you deploy your app. The traffic redirection is seamless, and no requests are dropped as a result of swap operations. This entire workflow can be automated by configuring Auto Swap when pre-swap validation is not needed.
After a swap, the slot with previously staged app now has the previous production app. If the changes swapped into the production slot are not as you expected, you can perform the same swap immediately to get your "last known good site" back.
Short version: How can I deploy a new version without first manually stopping the app-service?
Long version:
I'm using the following workflow to publish a new version of my ASP.NET Core app to an Azure App-Service.
The App-Service is running on a basic instance. I understand this is not intended for real use but I hope there is a good way to get this workflow running before we go into production(standard instance).
This works but how can I avoid step 4 to 7?
Publish the solution into a local folder.
Move the published content into a local git repo.
Commit all files and push to the app-service.
Stop the app-service from the portal
Enter the console and delete all files in the wwwroot folder
Redeploy the commit from the portal
Start the app-service
I was hoping that the push in step 3 would automatically trigger the remaining steps.
After step 3 I can see that the files have been updated, the new static files are served to the browser but the old binary is still running.
Similarly I can switch between deployment slots on the portal. I get the new static files served but the previous deployed binary is still answering all calls.
This doesn't work, the static files are changed but the old binary is still responding to calls.
Redeploy from portal
Restart app-service
The old binary is still served.
This works.
Stop app-service
Deploy from portal
Start app-service
It appears the running binary is blocking the deployment.
How can I automate deployment using git push or from the portal without manually having to stop the service?
Application settings:
You need to enable msdeploy flag MSDEPLOY_RENAME_LOCKED_FILES=1 in Azure App Service application settings. The option if set enables msdeploy to rename locked files that are locked during app deployment
Click application settings and scroll down until you see app settings.
set this key: MSDEPLOY_RENAME_LOCKED_FILES and for its value put 1
How can I deploy a new version without first manually stopping the app-service?
When I develop my .Net Core Web application via VS, I would leverage the publish wizard, check the option Remove additional files at destination and use the App offline support by setting EnableMSDeployAppOffline to true under the publish profile for publishing my application to Azure Web App.
Based on your current deployment workflow, I assume that you are using the Continuous Deployment to your Azure App Service with your local Git Repository. After I changed the source code, then commit the changes to the local repository, then push the source code to my web app remote repository, the source code would be built and copied to D:\home\site\wwwroot on Azure side. Details you could follow Local Git Deployment to Azure App Service.
For your step 1 to 3, I just push the code changes from the local repository to my app service remote repository. Azure would generate the deployment script for you to build your source code project and move the built content to D:\home\site\wwwroot. Moreover, you could Custom Deployment Script for your additional requirement.
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.
When we deploy our App Service from Visual Studio 2015 to Azure we tag the current commit in Git so that we can get back to any of our past deployments.
But I suspect that we forgot to do that when we deployed our current ASP API.
Using the Azure portal how do I tell when the deployment running in one of our app service's deployment slots was made?
Maybe try using kudu: https://[webappname].scm.azurewebsites.net/ - you can see file timestamps in the console.
If you are use classic portal, you can find the deployment history list in the DEPLOYMENTS tab of your app service application. And you can click one of them, click the REDEPLOY button at the bottom nav bar to rollback to the specific deployment version.
If you are using Azure portal, you also can find the deployment history, by clicking deployment source => selecting the specific deployment version=>click redeploy button to rollback.
By clicking you service you can go to All Settings --> Audit Logs. There you can filter by 'Update website'