In order to update our IIS Site we delete then replace contents of the associated physical path. However, sometimes we are not able to dele some files and/or folders as they are "being in use".
How should we proceed in such cases?
It depends on the application you used.
If you use asp.net application, you can replace the content of sites directly. When asp.net application was deployed on IIS at beginning, IIS will load it firstly and create a shadow copy in temp file. All requests will be handled by the shadow copy. When you update the files, it creates a new AppDomain to service any new requests, and signals the previous AppDomain to shut down as soon as it has finished servicing any current requests.
If you use asp.net core application, you need to stop application, then update it. Asp.net core application is different from asp.net application. It actually runs in kestrel. IIS just acts as a proxy to forward requests to kestrel.
Related
Each time when I launch the debugger for an ASP.net core application under local IIS from VS2017, a new Application pool is created.
I wish the application to remain stable under the DefaultAppPool 'Identity', and not create a new one.
Where is this setting to influence this?
I can manually set it to the old value using IIS management console, but it's getting tiresome.
What you are experiencing is most likely a side effect of the new InProcess hosting model that was introduced with .NET Core 2.2. Check your .csproj file for this line:
<AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
InProcess hosting allows only one IIS site per application pool. It will generate new app pools on the fly if this condition is not met.
You can return to the old Kestrel hosting by removing the above line or by changing it to:
<AspNetCoreHostingModel>OutOfProcess</AspNetCoreHostingModel>
The difference between In- and OutOfProcess hosting is also reflected in web.config, so you may have to change it there too if you want to go back. Look for the aspNetCore node in system.webServer:
<aspNetCore
processPath="..."
arguments="..."
stdoutLogEnabled="false"
stdoutLogFile=".\logs\stdout"
hostingModel="InProcess"
>
Again, you may remove the hostingModel entry or change its value to "OutOfProcess" :
<aspNetCore
...
hostingModel="OutOfProcess"
>
But wait!
You may actually want to reconsider and adopt the new InProcess model for reasons explained in the following.
New InProcess hosting vs. old Kestrel hosting
Before .NET Core 2.2 all Core web applications on IIS were run using a second web server called Kestrel. Kestrel is lightweight and fast but lacks many functions of a full-blown web server. So IIS was used as a proxy in front of Kestrel to add all higher functionality (like redirects, authentication etc.). As you may imagine, cascading two web servers will reduce overall performance and consumes additional resources.
Since .NET Core 2.2 there is another option: InProcess hosting
If you activate InProcess hosting, IIS uses an in-process server implementation for IIS called IISHttpServer. This implementation as well as the Core app itself run in the same process as the IIS worker process. This reduces the resource footprint and increases performance.
There is one limitation though: Each InProcess hosting site in ISS needs a dedicated application pool. You cannot use the same application pool for multiple sites that are configured for InProcess hosting!
Also remember that this unique app pool requires read and write access to the site's folder or any other folders where the app reads and writes files. Otherwise you will get 503 errors.
Basic InProcess configuration
A typical PropertyGroup entry in .csproj for an InProcess project looks like this:
<PropertyGroup>
<TargetFramework>netcoreapp2.2</TargetFramework>
<AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
</PropertyGroup>
You can easily switch back and forth between new InProcess and old Kestrel hosting by simply changing InProcess to OutOfProcess and vice versa.
More info
For more information on InProcess hosting see: ASP.NET Core Hosting Models
For info on migrating existing Core projects to InProcess hosting see: Adopt the IIS in-process hosting model
I updated a ASP.NET CORE/ASP.NET 5 RC1 controller cs file with a programming change.
The site has previously been deployed on production on IIS7.5 Windows 2012 Server which makes use of HTTPPlatformHandler installed in IIS.
This is a remote server I have to access via VPN.
The site is setup as an application in IIS and the folder points to the wwwroot directory of the deployed site.
I deploy it currently by deploying it first locally by right clicking on my project in Visual Studio 2015 and selecting publish to local folder. I then copy the contents of the local folder to the remote network IIS7.5 web server site folder.
If I copy for example the appsettings.json or a changed .cs file to the server, the change will not reflect.
If I copy the whole site to the production server I get folders and files in use messages. I have to kill the 'dnx' process in order to copy without getting these messages.
From my understanding if I kill the process dnx it will force a recompile. This is currently the only way I know of to restart the site after updating it but I imagine it is not the best way.
What is the standard practice to restart your website after you update your production sites that run ASP.NET5 RC1?
Also changing my app.settings json file aslo doesn't trigger a site reload like changing the web.config did in ASP.NET 4 so being able to restart a site is important.
If I have multiple sites on the same app pool and I only want to update one in production. How can I only restart the one site to reflect the latest changes?
Is it possibly to restart the website to reflect the change as updating it directly doesn't cause a recompile taking into consideration if I only have access to a shared folder and not the web server itself?
With IISPlatformHandler, DNX process is started by IIS (instructions are in wwwroot\web.config).
IIS knows nothing about your source files, all requests are forwarded to DNX.
DNX does NOT watch source files for changes, because there is no dnx-watch there.
IIS only watches for wwwroot\web.config file changes, so you need to change/edit/touch it to force IIS to restart website (and DNX process).
I use msdeploy to deploy, it has commands to stop and start app pools, using these commands has resolved my file in use errors. There are lots of ways to use msdeploy, below is how I happen to be using it.
msdeploy -verb:sync -source:recycleApp -dest:recycleApp="site/pool",recycleMode="StopAppPool",computername=COMPUTERNAME
msdeploy -source:contentPath='SOURCE PATH' -dest:contentPath='\\COMPUTERNAME\wwwroot\' -verb:sync -retryAttempts:2 -disablerule:BackupRule
msdeploy -verb:sync -source:recycleApp -dest:recycleApp="site/pool",recycleMode="StartAppPool",computername=COMPUTERNAME
I'm currently in the process of migrating an ASP platform from Windows 2003 R2 IIS 6 web servers to Windows 2012 R2 IIS 8.5 web servers. I'm at the stage where I've migrated a number of sites across to two separate 2012 web servers, all looked great, clients and developers are happy... However the following error has presented itself after a few days hosting on one of the new servers.
Active Server Pages error 'ASP 0223'
TypeLib Not Found
/jobboard/conf/constants.vbs.inc, line 1
METADATA tag contains a Type Library specification that does not match any Registry entry.
The METADATA tag is below:
<!--METADATA TYPE="typelib" NAME="Microsoft ActiveX Data Objects 2.8 Library" UUID="{2A75196C-D9EB-4129-B803-931327F72D5C}" VERSION="2.8"-->
Restarting IIS on this server resolved the issue (albeit temporarily).
Subsequently the other 2012 web server in production presented the same error a couple of days later, again, restarted IIS and works for now.
I've checked the registry and the relevant tag exists with the right UUID and correct permissions.
It doesn't affect all sites on the server, only all sites in a particular application pool.
The application pools use a domain user identity and sites are split up into a number of shared pools.
I've now determined what was causing the above problem...
Our sites on IIS run in a number of shared application pools running as a domain user. We also have a Windows scheduler job which runs a number of scripts over night which also run as the same domain user.
It seems there are cases when this scheduler job runs it interferes with the IIS worker processes. When it completes and ends its user session it unloads the registry file in memory, which the w3wp.exe processes could also using.
This error is presented in the Event log...
Windows detected your registry file is still in use by other
applications or services. The file will be unloaded now. The
applications or services that hold your registry file may not function
properly afterwards. No user action is required.
Along with references to the w3wp.exe processes currently running.
It was replicated when I terminal serviced in as the domain user and logged out again after a period of time. The event log presented the error and the sites all bombed shortly afterwards.
Running the scheduled job as a different user has fixed this issue for us.
I remember having an include file for ADOVBS.inc with all the ADO constants inside and including it as a standard ASP include inside my global include file which is included on every page on the site.
This was before I used the META way of including the file.
So maybe a last resort is to revert to that method of loading in the ADO constants.
It seems like some sort of threshold is being hit, CPU/Memory?, which then prevents IIS caching/loading the file in from the registry. This then causes the error and a recycle of the pool. As no redirect is being done to the 500.100.asp error handler page which hides the error details from the user. It would suggest the error is in IIS and related to the server.
Thanks
As I deploy my web site, I found that I could convert a folder into a virtual folder or web application, I am totally confused about these 2 concepts.
Why there are two different types?
What's the purpose of each?
A Virtual Folder or Virtual Directory is just a link to a physical folder somewhere on the server. This folder becomes part of the website structure and you can use the virtual directory in the path part of URLs. Code that executes in Virtual Directories will execute in the same "Application" as it's parent.
An Application is where the code that runs inside that "folder" has it's own Session state and Application state. It is in effect a new standalone application living underneath the root application.
For example, if you were to deploy an ASP.NET application into a site that had an Application folder called /myapp then that application would have it's own application domain, session state, application state completely separate from another ASP.NET application running in /. For example: if you set an Application value Application["Thing"] = 123 in the root application and then did the same but with a different value in /myapp then Application["Thing"] in the root would not be overwritten by the assignment in /myapp.
Another thing you can do with Application's is specify a different Application Pool to run under. For example your root / application might contain an ASP.NET 2.0 application and run in a pool configured for .NET 2.0. However you may want to run a blog or forum application written in ASP.NET 4.0. Now because you can't mix ASP.NET runtime versions in the same application pool, you can specify an alternative application pool specifically for ASP.NET 4.0 applications.
Applications can also behave like Virtual Directories and you can point an application folder at a physical folder elsewhere on the server.
If you're interested in the underlying mechanics of Virtual Directories and Applications on IIS7 then have a look at this answer I posted a while back:
Using ServerManager to create Application within Application
To add an informational detail to what Kev has very nicely mentioned - All virtual directories by default run under a pre-defined app pool named DefaultAppPool. DefaultAppPool comes by default with IIS whenever you enable this feature in windows. For WebApps you can always create fresh/new appPools and run your webApp inside your newly created appPool. These appPools provide you that physical/separate process space (in form of worker processes) with the help of which IIS is able to provide services like sessions state, application state etc in silos to a webApp when it has its own appPool defined. Whenever your webApp's appPool crashes, the other webApps (using their own custom appPool) or virtual directories (using DefaultAppPool appPool) remain completely unaffected.
I know one can set the session timeout. But, if the application itself has received no requests for a given period of time, IIS shuts down the application.
This behavior is configurable in the IIS management console, and I know how to do this. Still, I wonder if it is possible to configure this in web.config.
Not in IIS 6. In IIS 6, Application Pools are controlled by Worker Processes, which map to a Request Queue handled by HTTP.sys. HTTP.sys handles the communication with the WWW Server to determine when to start and stop Worker Processes.
Since IIS 6 was created before .Net, there's no communication hooks between .Net and the low-level http handlers.
ASP.net is implimented as an ISAPI filter, which is loaded by the Worker Process itself. You have a chicken-before-the-egg issue if you are looking at the web.config controlling a worker process. This is primarily why MS did the major re-write of IIS 7 which integrates .Net through the entire request life-cycle, not just the ISAPI filter portion.
You can edit these settings, but not in web.config. If you have IIS7, the setting is in applicationHost.config, and the key attribute is the shutdownTimeLimit.
You can google for it, to find out how to use appcmd and other tools to set or change it.
Example
Also you can directly modify the shutdownTimeLimit by editing the applicationHost.config file, which is in the \inetsrv\config directory.
The schema for the applicationHost.config file is in the \inetsrv\config\schema\IIS_schema.xml file.
So open it in your favorite schema-aware XML editor and you'll get intellisense, etc.
You can do it with setting IdleTimeout.
BUT changes to the processModel element take effect only when the worker process is restarted—not immediately after the setting is changed, as with other configuration elements.
You can see it here:
processModel Element
You also must change machene.config to can edit machine configuration from other archive.