In IIS 7.5 I have the following configuration:
Sites
-Site1
--App1
--App2
Site1, App1 and App2 are each running in separate Application Pools. When I update the web.config under App1 it restarts both App1 and App2. Is there anyway to prevent a web.config update in a sub app from restarting the entire site?
When a change is made to a web.config, it is typically the app domain that is unloaded and not the app pool that is recycled (some info on that here). Site1, App1, and App2 should each be defined as separate applications and not just virtual directories. Each application will be running in its own app domain, so replacing or changing a web.config should not affect the others unless it is a child application that is inheriting settings from the parent web.config. Depending on the change, making a change to the Site1 web.config could end up causing the app domain for App1 and App2 to unload.
If App1 and App2 are using the same web.config (i.e. if both document roots are pointing to the same file system location) then making a change to the web.config will end up unloading the app domain for both applications.
You can change the App Pool behavior so that a config file change does not cause an app pool recycle.
App Pools -> Your App Pool -> Advanced Settings -> Recycling/Disable Recycling for Configuration Changes = True
(default value is False)
Related
When we restart the app pool on our IIS server, the web application that is using that app pool serves an html page from the file system. I'm trying to identify where that name of that file is configured within IIS so that we can change it. We would ideally like to control the behavior of what is served during an APP Pool restart.
I've reviewed all configuration settings within IIS that I'm aware of and can't find a mapping to the error page that is served from disk, which is named "restarting.htm".
When setting up an ASP.NET web application using IIS 10, the web server observes the web.config file for changes by default. If the file changes, an automatic app pool recycle is triggered.
Is it possible to set up the IIS to recycle the app pool automatically as well if a specific other file is changed? And can it be located outside the web application's root path, e.g. its parent directory?
My company is exploring ASP.NET Core. We currently use ASP.NET Web API 2 & MVC 5.2.2. We deploy our applications under IIS using the following configuration:
VirtualDirectory1 (web.config with connection string and other non-specific information)
App1 (app specific web.config)
App2 (app specific web.config)
Api1 (api specific web.config)
Api2 (api specific web.config)
VirtualDirectory2 (web.config with connection string and other non-specific information)
App1 (app specific web.config)
App2 (app specific web.config)
Api1 (api specific web.config)
Api2 (api specific web.config)
As you know, each application or API inherits configuration from the parent web.config under IIS, so each inherits the parent connection string. We use a single copy of each application on the server. Can we deploy ASP.NET Core applications the same way?
I found StackOverflow articles on nested objects and environment specific AppSettings.json configurations but this does not appear to be the answer.
UPDATE 1:
The above is a multi-tenant configuration where each virtual directory is a tenant. The web.config at the root of each virtual directory contains the connection string all apps under the virtual directory use.
I read that a web.config file must exist for ASP.NET Core apps to work under IIS.
https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/index?tabs=aspnetcore2x#webconfig-file
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?tabs=basicconfiguration#webconfig-file
So I wonder if that the connection string is visible to the ASP.NET Core applications.
Update 2:
A.F.A.I.K, web.config can be loaded from the app content root, but the one we need resides up in a virtual directory. A AspNetCoreModule maintainer told me environment variable inheritance (which applies in this scenario) is unreliable, and no plumbing exists to access other inherited configuration. The web.config only exists to configure IIS for ASP.NET Core applications.
The best solution seems to be using host headers the way Saaskit does.
https://github.com/saaskit/saaskit
This requires us to change our IIS deployment and add a DNS record per tenant, but it is the next best thing to inherited web.config files. I would like the ASP.NET Core team to consider introducing a ASP.NET Core-approach to inherited settings that gives us the same ability inherited web.configs did.
Putting tenant specific settings in a file up in a virtual directory is out of the box thinking, but it greatly simplifies multi-tenant support. Our MVC & Web API code needs nothing extra. It simply retrieves settings through the ConfigurationManager as though no other tenant exists.
We have one website under IIS and one virtual directory per tenant. Each tenant is accessed via its URI.
https://myfqdn.com/tenant1/myapp
https://myfqdn.com/tenant2/myapp
tenant1 and tenant2 are virtual directories containing a tenant specific web.config, so invoking https://myfqdn.com/tenant1/myapp loads tenant1's web.config and myapp inherits its settings for requests. /tenant2/myapp loads a different web.config.
Myapp is unaware of which virtual directory it was invoked from on each request. We install myapp in one physical location but add it as an application under each tenant's virtual directory. The result is we have one copy of the app, multiple instances, and no multi-tenancy plumbing.
ASP.NET Core is not bound to IIS so the same approach won't work as for ASP.NET. But you can implement a similar approach if you would like by moving your common settings to some SharedSettings.json and use this.
.ConfigureAppConfiguration((hostingContext, config) =>
{
var env = hostingContext.HostingEnvironment;
var sharedFolder = Path.Combine(env.ContentRootPath, "..", "Shared");
config
.AddJsonFile(Path.Combine(sharedFolder, "SharedSettings.json"), optional: true) // When running using dotnet run
.AddJsonFile("SharedSettings.json", optional: true) // When app is published
.AddJsonFile("appsettings.json", optional: true)
.AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true);
config.AddEnvironmentVariables();
})
Read more here: Sharing appsettings.json configuration files between projects in ASP.NET Core
ASP.NET Core out of the box supports hosting in IIS and self-hosting scenarios using the Kestrel and WebListener HTTP servers. Accordingly to web.config / project.json looks like IIS is used, but if so it is not clear for my "why" so, as now IIS is acting just as a reverse proxy and the application itself runs as a separate process using the Kestrel HTTP server.
So the main question is "what" and "why" is used by default, if deploy to Azure?
Yes, when you publish to Azure App Services, IIS is used to host your application. As you said, it acts as a reverse proxy to your application, which is running Kestrel HTTP server. But IIS does more than that - it also manages the application process through application pool, which includes or may include:
restarting the app when web.config changes
starting the app on the first HTTP request
running the app as a specified user
recycling the app pool (and effectively restarting the app) on certain conditions
starting multiple app processes
handle webdeploy (this is what happens when you hit "Publish" in Visual Studio
I have deployed multiple Web Applications in IIS, When I am deploying a modified Dll for any of this Web Application, I need to restart the IIS to get the effect of the new dll. This impacts other Applications. All of these Applications get restarted as I have restarted IIS. Is there any way by which I can restart the specific Application, for which the modified Dll has been deployed?
Yes. Create a different "Application Pool" for your app (in IIS). Make sure your app is assigned to the new pool.
When your app is deployed, the app pool is automatically restarted (affecting all of the other apps in that pool). By default, everything gets deployed to the default app pool.