Is it possible to publish an ASP.NET (core) application to a running site on IIS 8 without having to stop and start the website manually?
Visual Studio 2015 keeps giving the error that a file is in use. I'm using publish to the file system, because my Web Deploy to a server in our network fails at the end with an error that it cannot authenticate on the server with port 443.
I don't mind IIS having to recycle the application pool, but when I constantly have to put the app down, publish (which takes about a minute) and restart it, it's not really good for the users.
Another option would be something like 2 websites running the same application, but only if this is automatable. Then it would put down 1 of the 2, update this, put it on, put down the second, update this and start it.
A third option is something like a hot update, where I could just update the application while it being on.
Can anyone point me in the right direction (perhaps some blog posts), because my Google searches didn't give me any good information?
If you copy a file called app_offline.htm to the application folder IIS will gracefully stop your application and start serving the contents of the app_offline.htm file. When application is stopped you can copy your files. After files are copied remove the app_offline.htm file and IIS will start your app. VS does that for you when you deploy to Azure but not when deploying to file system.
You mention "two websites running the same application". Do you mean two web servers hosting the same app?
If you already have multiple web servers (a.k.a. cluster of servers, or web farm), you can simply take some servers out of the cluster and update them. That is how we push out our updates. We use software from Citrix for managing the server farm. It also handles load balancing. This type of software allows one to monitor the servers, so you can determine when all the users have "moved" off the web servers (that were recently taken out of cluster). Then you can iisreset, deploy the new build, and move on to the next server (or set of servers, depending on your configuration). We have more than 20 virtual web servers. Typically we take down half of the servers, update them, and take the other half down as we put the first half back in the cluster/farm. This should allow for uninterrupted service. I understand you want to automate the process. I'll assume you're using Windows NLB (network load balancing). You could write a PowerShell script to automate taking down the servers. Here's a reference:
https://technet.microsoft.com/en-us/library/ee817138
I understand this may be viewed as a workaround. I'm not sure if recycling the app pool is always necessary with ASP.NET Core. I wasn't able to find a definitive answer. Most production applications should be on more than one web server anyway. Even if you don't have a lot of users, you should have multiple web servers for failover purposes.
Related
We are using IIS7 to host an asp.net web-based application.
In this environment administrators and developers can deploy code to the application on a regular basis.
The new code or app goes as a DLL to the ASP.NET bin folder. Upon deployment of the new DLL, IIS restarts the process, impacting (slowing down) all online users.
Is there a way to configure IIS to run the process in the background and once ready make the switch from old state into new without impacting the users?!
Thanks in advance for your feedback!
IIS already does this, that's what recycling is all about. IT's loading the DLL's while the old version of the application is still running. only after this is completed the recycling is complete.
However loading the DLL's is only part of getting web applications ready, there might also be initial loads like loading/caching the user db etc.
These actions are not part of the recycle process, they happen after all DLL's reloaded and the recycling is already completed.
A while back I ran into this issue with an application that had a huge startup time due to heavy db activity/caching during startup. So I was interested if there is some functionality that allows us to execute code before the recycle is marked as completed, so that the application is first considered recycled when everything is ready to run. Basically what I wanted is some kind of staging functionality.
I was in contact with the IIS team regarding this issue, sadly they told me that no such functionality exists, nor is it planned.
To solve this you could try do the following:
Use alternating deploys:
You setup 2 Websites with separate application pools. One of them is the LIVE website the other one is the STAGED website. If you want to deploy changed you simply deploy to the STAGED website. After everything is loaded/cached etc. you switch the URL settings of the web applications to reroute incoming requests from the LIVE to the STAGED one. So the LIVE one becomes the new STAGED and the other way around. The next deploy would then go to the new STAGED again and so on.
UPDATE
Apparently they have created a IIS Module that provides this functionality by now:
IIS Application Warm-Up Module for IIS 7.5
The IIS team has released the first beta test version of the
Application Warm-Up Module for IIS 7.5. This makes warming up your
applications even easier than previously described. Instead of writing
custom code, you specify the URLs of resources to execute before the
Web application accepts requests from the network. This warm-up occurs
during startup of the IIS service (if you configured the IIS
application pool as AlwaysRunning) and when an IIS worker process
recycles. During recycle, the old IIS worker process continues to
execute requests until the newly spawned worker process is fully
warmed up, so that applications experience no interruptions or other
issues due to unprimed caches. Note that this module works with any
version of ASP.NET, starting with version 2.0.
For more information, see Application Warm-Up on the IIS.net Web site.
For a walkthrough that illustrates how to use the warm-up feature, see
Getting Started with the IIS 7.5 Application Warm-Up Module on the
IIS.net Web site.
See:
http://www.asp.net/whitepapers/aspnet4
If you use ASP.NET 4 Auto Start feature:
You can still choose to auto-recycle the worker processes from time to
time. When you do that, though, the app will immediately restart and
your warm up code will execute (unlike today - where you have to wait
for the next request to-do that).
The main difference between Warm Up and Auto Start feature is that the Warm Up Module is part of the recycling process. Rather than blocking the application for requests, while running the init code.
Only thing you get by using the Auto Start feature is that you don't have to wait for a user to hit the page, which does not help your case.
See the Gu's blog post:
http://weblogs.asp.net/scottgu/archive/2009/09/15/auto-start-asp-net-applications-vs-2010-and-net-4-0-series.aspx
UPDATE 2:
Sadly the Warmup Module has been discontinued for IIS 7/7.5:
http://forums.iis.net/t/1176740.aspx
It will be part of IIS8 though (It's now called Application Initialization Module):
http://weblogs.asp.net/owscott/archive/2012/03/01/what-s-new-in-iis-8.aspx
UPDATE 3:
As pointed out in the comments the Warmup Module resurfaced for IIS 7.5 as Application Initialization Module for IIS 7.5 after IIS 8 was released:
http://www.iis.net/downloads/microsoft/application-initialization
The first part of ntziolis answer is a wee bit inaccurate. The worker process isn't being recycled or restarted, it just keeps running. If this were the case, then in shared pool environments you would have sites knocked out every time a new one was deployed.
When you deploy a new ASP.NET application it's the site's "Application Domain" within the worker process is torn down, not the pool process.
In addition pool recycling is a completely separate concept to deployment
At this point in time in the commercial life of ASP.NET, during a deployment, a site will be in an inconsistent state until all of the site is deployed. There is still no good story about this from Microsoft at this time for single site on a single server deployments.
This is why ASP.NET has the special App_Offline.htm page. It's there so you can enable that page, deploy and then turn it off.
The second part of ntziolis answer is nearly correct but you don't need two sites or two application pools. You just need two file system folders that switch between being the physical folders for the site...if you're on a single server and not behind a load balancer or ARR.
If your sites were on a web server behind a load-balancer or ARR then having two different sites would make sense, you could route requests from one site to the other and round-robin on each deploy.
Obviously if there is a large amount of user generated content (uploaded files and the like) then you'd map a virtual directory in your site to a common location for this data.
In larger scale deployments where your app is running across (for example) a load-balanced environment you can do more sophisticated deployments.
For related questions please see:
How Do I deploy an application to IIS while that web application is running
Publishing/uploading new DLL to IIS: website goes down whilst uploading
Is smooth deployment possible with componentized ASP.NET MVC apps?
I've created an Azure server instance. I've deployed a simple application to it. As part of the deployment process I enabled Remote Desktop Connections.
I have some standard ASP.net applications that run on Windows, is there something to stop me deploying these applications manually to IIS using Remote Desktop. I've read so much about having to migrate standard ASP.net apps to Azure. I don't want to this as we will have customers who will still use Windows Server 2003/2008 so I don't want to have to maintain 2 versions.
Well, as I understand it, in theory you could deploy stuff using remote desktop. But when the instance shuts down/restarts you'll lose it all (unless you've built it into your startup scripts) and have to re-load everything each time. The main reason they suggest you have at least two instances is so that when one shuts down for updates etc there is always at least one other running.
The "Windows Azure Accelerator for Web Roles" project allows you to create an Azure web role which then enables you to use web deploy for all your other web sites - I'm guessing that will be a whole lot better approach and is definitely worth a look. Also, I believe smarx.com is a good place to browse for info and ideas.
Using a startup task and the Azure Bootstrapper you can download, unzip, install almost any kind of 3rd party software that supports either xcopy deployment (just copy the files) or an unattended(silent) install.
Assuming you aren't using Azure storage or anything like that, there shouldn't be any difference with the IIS application. If you are using anything specific to Azure, you can use the RoleEnvironment.IsAvailable to test if you are running inside Azure or not. That will return true for the emulator as well. If you want to use Azure storage from both, you can add the settings in the web.config to use if not running in Azure.
I'm a developer now developing my startup. I really don't know much about IIS setup. I will host my startup on Amazon EC2. And I want to know how can I scale my application if my traffic increase. I been reading about MS Deploy and Web Farm Framework here: https://serverfault.com/questions/127409/iis-configuration-synchronization-for-web-server-farm . And I want a simple architecture, with not to much configuration. So I been looking an experience with an IIS web farm and Amazon ELBs. And I did not find any one.
So the question is:
It is possible to make a IIS web farm with Amazon ELBs?
Any experience on Ec2? IIS web deploy or WFF and/or without ELBs?
What you recommend for an easy web farm setup?
You can do almost anything you want with IIS on EC2. They are full servers (well window 2k8 datacenter edition) and you can open any ports you need to communicate between servers. Here is an explicit tutorial on how to set up WFF, for example, on EC2.
The question is, are you sure you need to build a web farm? If you simply want to have multiple servers running your code then you can accomplish this without anything more than IIS and the tools that EC2 provides.
You build your app so it uses shared resources (like a session state server, central location for storing user uploaded content), configure a server the way you like it, and capture a server image (AMI). You use this image when you configure AutoScaling to launch new instances based on server metrics (like CPU usage), and they would be automatically added to the load balancer when launched.
The last challenge is ensuring servers launched automatically are running your latest code. You can write a custom program to get the latest code from somewhere (like SVN) on server startup, or you can use something much simpler like Dropbox to handle the synchronization.
We need to deploy our asp.net web site in web farm which consists of 16 web servers. Whenever we need to roll out a new release it is very time consuming and tedious as we need to deploy it first on the DR environment (16 web servers) and then on to Live environment (16 web servers).
Currently we prepare the msi on our build server and copy it on all the front end web servers which involves first FTPing the msi to a common location on hosting network and then copying from the common location to each server.
After thet we backup the existing website and then run the installer one by one on each machine.
After installing the new version we replace the web.config file with the older one as it is encrypted and hardly contains any new thing in it as part of new release. This saves us from encrypting the web.config file again.
Could somebody please suggest a better way of doing this deployement as it is really turning out to be time consuming. Previously this model was ok for us as we had only 4 web servers but not it is no longer a sutable option.
Thanks..
Take a look at the Web Farm Framework. It will handle the replication of your application across your entire farm.
Another option is to use the "Shared Configuration" option in IIS7 as well as a DFS share to replicate all of your files and metabase configuration. This just won't handle registry changes or the GAC.
How to deploy an asp.net webApp to multiple servers?
Deploy Web Applications Using the Copy Web Tool
also check thread
What method do you use to deploy ASP.Net applications to the wild?
It depends how many servers you're talking about.
For less than about 4 or 5 servers, I just zip the application, copy to each server, unzip into a new folder, and tell IIS to look at the new folder, using IIS Manager. In a load-balanced environment, it also means taking all servers except one offline, and then updating them one at a time, and bringing them back online afterwards.
For more servers than that, I prefer to use Windows Deployment Services (WDS).