I have an existing ASP.Net MVC app that's currently hosted locally in IIS and I'm trying to deploy it to an Azure App Service.
I've seen several posts about setting the Applications Settings and Connection Strings manually in the Application Settings blade.
The problem with that is that I have a ton of App settings in my web.config file, along with various other config sections.
Is there a way to automatically map those to Azure Application Settings when I deploy my app?
Your best bet is to write a simple transform tool that changes those web.config based settings into the equivalent ARM template that sets those settings and connection strings (probably < 20 lines of code).
Note that there is no Azure equivalent of sections other than App Settings and Connection Strings.
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 developed a feature using sharepont 2010, feature Scope is "Web", feature Deployment Target is "WebApplication"(Deployement Target has been set throw Package->Advanced->Add->Add Assembly from Project Output->Deployment Target as "WebApplication).
In this feature using "SPWebConfigModification" class updating web.config file.
My concern is below:
1)After deploying it should go to particular "web" since its a "WebApplication" deployemnt but this feature is availabe in all the web apllication in the server, even though if we go to Central Admin->System Setting->Manage Farm solution, we can see this .wsp file has been deployed to particular web application not Globally Deployed. I think this looks strange. My requirement is, the feature should be available in one web application not in all web application. Can somebody point me out pls whats wrong in this or how can we do this?
This has to do with the property ActivateOnDefault in the feature manifest file, this property ONLY applies to features scoped at Farm and Web Application levels. Any feature (Farm or WebApplication) with that setting set to True will automatically activate on all web applications when you deploy the WSP solution. This property is set to true by default.
Read more about it here:
http://www.sharepoint.bg/radi/post/Activate-on-Default-confusion-and-features-scoped-at-Web-Application-level.aspx
I have some questions around the best mechanism to deploy MVC web applications to different environments. Previously I used setup projects (.msi's) but as these have been discontinued in VS2012 I am looking to move to an alternative.
Let me explain my current setup. I currently have a CI setup using TFSBuild 2010 with Team Foundation Server for source control.
A number of developers work on their local machines and check in to the TFS Server. We regularly deploy to a single server dev environment and a load balanced qa environment with 2 servers. Our current process includes installing an msi which carries out some of the following custom actions:
brings current app offline with the app_offline.htm file
run in database scripts (from database project in the solution)
modifies web.config (different for each web server of qa)
labels the code
warmup each deployed file via http request
etc
This is the current process. Now I would like to make some changes. Firstly, I need alternative to msi's. From som research I believe that web deploy via IIS and using MsDeploy is the best alternative. I can use web config transforms for web config modifications. Is this correct and if so, could I get an outline of what I need to do?
Secondly I want to set up continuous delivery via TFSBuild, I have no idea how this may be achieved, would it be possible to get an outline of how it can be integrated in to my current setup? Rather than check in driven, I would like it to be user driven following check in. Also, would it be possible for this to also run in database scripts from a database project in the solution.
Finally, there is also a production environment, but I would like to manually deploy this - can my process also produce an artifact that I can manually install?
Vishal Joshi has some information on his blog that is reasonably good, http://vishaljoshi.blogspot.com/2010/11/team-build-web-deployment-web-deploy-vs.html. It does have the downside that your deployment password is include in the properties you pass to msbuild.
Syed Hashimi has also posted some information on this in another questions Team Build: Publish locally using MSDeploy.
I am using Web.Config transformations to deploy my application to Azure. I also have 2 sites in my service, a public website, and private WCF site endpoint. I am deploying multiple sites to a single role.
When I deploy, the website project (for which the Azure Deploy project is set) transforms the web.config correctly. However, the WCF project (which is only addressed as a "site" in the .csdef file) does not transform the web.debug.config file to web.config.
This question is similar, but only addresses the projects building. I have set the dependencies in my project.
This workaround forces the transform of the web.config file, but it still does not appear in my deployment on Azure.
I suspect that this bug still exists, and I have also upgraded to the Azure 1.5 SDK in hopes that it will fix it.
I would like to try putting my configuration data in cscfg files but I am using Entity Framework Code First, and I do not know how to get my connection string to work with this format. EFCF seems to rely on web.config explicitly.
Any help would be appreciated.
When you add another web role, you provide a physicalPath to point to what you want deployed, and all the SDK does is copy the files it finds at that path into your package. It doesn't do a build.
You should probably be doing a build and a publish of the web app you want to deploy, and then point the physicalDirectory at the output of that publish step. (Make sure the directory you're setting in physicalDirectory contains exactly what you want to have deployed to the cloud.)
I have a Azure project (Azure 1.3) in VS2010. There are 2 webroles, one web page project and one WCF project. In debug mode I want the web project to use a web.config for DEV enviroment, and when publishing the web.config for PROD must be used.
What is the best way to do this ?
Currently I am facing issues when using a Web.Debug.config with transform XSLT. It doesn't seem to work in Azure....
Solve your problem a different way. Think about the web.config always being static and never changing when working with Azure. What does change is your ServiceConfiguration.cscfg.
What we have done is created our own configuration provider that first checks the ServiceConfiguration.cscfg and then falls back to the web.config if the setting/connection string is't there. This allows us to run servers in IIS/WCF directly during development and then to have different settings when deployed to Azure. There are some circumstances where you have to use web.config (yes, I'm referring to WCF here) and in those cases you have to write code and create convention instead of storing everything in web.config. I have a blog post where I show an example of how I did this when dealing with WIF (Windows Identity Foundation) and Azure.
I agree with Mose, excellent question!
Visual Studio 2010 includes a solution for this type of problem, web.config transforms. If you look at your web role you'll notice it includes Web.Debug.config and Web.Release.config along with the traditional web.config. These files are used to transform the web.config during deployment.
The canonical example is "I need different database connection strings for development and release" but it also fits your situation.
There is an excellent blog post from the Visual Web Developer Team that explains how to use this feature (don't bother with the MSDN docs, I know how it works and still don't understand the docs). Check out http://blogs.msdn.com/b/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx
I like this question !
For worker roles, I solved this problem by detecting the environment at runtime and launching my 'application' in a new AppDomain with a custom configuration :
bot.cloud.config
bot.dev.config
bot.win.config
This is incredibly efficient !
I'd like to do the same with web projects, because using the Azure specific configuration is a lot of trouble :
Both config are not in the same place, which is time-consuming when debugging
You have to learn a new way of writing something that sould be standard
Sometime you'll wonder if the app falled back on web.config because of a stupid syntax error
I'm still searching the right way to do that, like in this post
Another possible solution is to have two CloudService projects, each one with specific ServiceConfiguration.cscfg(dev/prod). Develop using the Dev, but deploy the Prod.
Currently I am facing issues when using a Web.Debug.config with
transform XSLT. It doesn't seem to work in Azure....
It depends on whether you want to make it work on your local machine or inside continuous integration.
For the local machine I tried to answer here: https://stackoverflow.com/a/9393533/182371
For the continuous integration it's even easier. When you build from the command line specifying the Configuration property value your configs WILL be transformed (no matter what it does when you build inside VS). So properly specifying build configurations for both cloud and web project will give you the correct output depending on build parameters.