AFAIK IIS restarts, whenever any of the web.config files is changed.
I've created my own configuration files (my.config, with slightly different hierarchy). Is there any possibility to have IIS automatically (automagically :)) restarted, whenever any of these are changed, too?
EDIT: I've considered filesystem watchers, but I'm not sure where to put them.
You mean to say that whenever you change my.config iis has to be restarted automatically.
Maybe you can write a batch file to perform your iisreset functinality alone if you dont want the user to manually restart IIS. But even if you give a batch file the user still needs to execute.
quick and ugly fix would be put config files in bin directory.
btw. I don't believe I am writing this ;)
these changes restarts web app:
* web.config
* machine.config
* global.asax
* Anything in the bin directory or it's sub-directories
copy/pasted from here Common reasons why your application pool may unexpectedly recycle
Use SomeAssemly.dll.config which will be put into ~/Bin, automatic be read on app (re)start and cause app restart on edit.
Note that App.config in project becomes $(OutputAssembly).config on build
Related
for example, there is an application written using dot net core 2.1
Published under the IIS (Windows Server 2016). At the root of the application (near to the binaries (.dll)) random files are being created and modified. Will this affect the performance of the application? Will it make a difference if these files are created in a subdirectory next to the binaries?
If we exclude IIS and host under Kestrel, will it affect somehow?
As far as I remember, when hosting applications, written on a .NET fullframework, under IIS, and modifying any file (for example, a text file) in the BIN directory resulted in restarting the web application.
I do not know what files are being created and modified i would separate them form the app files for security reasons to say the least. Having said that to answer your question.
It should not affect the performance unless the volume of operations is so large that it will use up all iops on the drive or the pc/ram of the machine.
Kestrel will not be affected unless you try to modify files that kestrel uses for the app in some way and if you use dotnet watch run it will try to recompile them and run in the host if not it will ignore their existence until the host is restarted.
IIS should ignore them as well but i do not know what will happen if you have those files in bin and try to restart the host. i have tried changing and adding a file and did not restart. Maybe there is something in IIS settings but since i have not setup our IIS my answer is lacking in that regard.
As for IIS, I have a PHP app, and I am using web.config for configuration.
When I change settings in web.config, shall I restart the server? or just refresh my webpage and expect settings to take place?
You don't need to explicitly restart server. Web.config is special file, any changes in it are watched FileWatcher and app pool is restarted automatically when you do changes in this file. So your app pool restarts on following things.
Any changes in web.config
Any changes in machine.config
Any changes in global.asax
Anything changes in bin directory or it's sub-directories
I have an IIS installation with three websites. I'm using Zend PHP -- each site is being directed to it's own PHP.ini file. My problem is this -- whenever I go into IIS to make a change, or restart IIS, the server, or mess with any configuration settings at all, IIS is saving my changes to the:
C:\Windows\System32\inetsrv\config\applicationHost.config file.
...but then it's is pulling an earlier configuration and IIS it referencing it as the config. This blows up the sites, tells me each site is trying to use the same configuration and gives an IIS error. I found that this file it's overwriting everything with is in the C:\InetPub\Temp\appPools[somename].tmp
This file is locked -- I can view it in a text editor, but can't make a change to it. It's taking the config in this file, then pushing it to another folder:
C:\InetPub\Temp\appPools[SiteFolder][site].config
I can take the config from applicationHost.config, and shove it into the site.config, and it fixes my problem -- but only until the next change is made...then that file gets overwritten again. I have many other servers with sites set up like this, and any changed made within IIS is written to applicationHost.config and properly referenced by IIS.
In IIS, if I view "CONFIGURATION: SEARCH CONFIGURATION", I pull up the applicationHost.config file and it shows this 'default configuration, and the path shows:
C:\Windows\System32\inetsrv\config\applicationHost.config
But what it shows in IIS doesn't actually match what is actually in that file. If it wouldn't then everything would work. I'm sure this is confusing -- but if anyone can help lead me in the right direction, I'll really appreciate it :)
I have a poweshell command which deletes the folder(i.e. Summer) from wwwroot directory and recreates the folder with the necessary files(images, css, dll etc) in it. The problem is every once in a while the IIS tends to lock some of the images or files in the directory so the powershell command fails to delete the file. I do recycle/stop the apppool before running powershell script which is used by site but still the problem persists. This issue is random i.e. the powershell script can delete the folder sometime while it can't other time. The weird thing is, if i start deleting the contents (subfolders, files) inside 'Summer', at the end, i am able to delete 'Summer' folder, but it is an manual process and which is tedious.
Is there any command which i can put in powershell or batch file to delete 'Summer' folder, even though when it is locked by IIS?
I agree with #Lynn Crumbling and recommend iisreset.
Sysinternals has two tools that provide other options:
The ProcExp tool allows you to find which processes have open handles to a given file, and allows you to close that handle. The downside of this tool is that it's not a command line tool.
The MoveFile tool allows you to schedule the file to be removed after reboot.
You can use the IIS powershell commandlets to start and stop app pools, web sites etc
Import-Module WebAdministration;
Stop-WebAppPool ${appPoolName}
Stop-WebSite ${webSiteName}
you can then start them again afterwards using the opposite commands
Start-WebAppPool ${appPoolName}
Start-WebSite ${webSiteName}
As put in comment, fully stopping IIS using iisreset stop would work.
Also, you may want to stop only the application from which you are trying to delete files from. Look at the Administration Guide.
I am aware that any change to ANY file in the BIN directory will trigger an application restart in IIS. Are there any other "special" cases where changing a file or moving a file in any other directory will trigger an app restart?
I know this is a very old post, but may be helps someone:
See this: http://programming360.blogspot.com/2009/04/what-causes-application-restart.html
ASP.net run-time environment implements a good deal of checks and automatically restarts an application if any of the following scenarios occur:
The maximum limit of dynamic page compilations is reached.
The physical path of the Web application has changed, or any
directory under the Web application folder is renamed.
Changes occurred in global.asax, machine.config or web.config in the
application root, or in the Bin directory or any of its
subdirectories.
Changes occurred in the code-access security policy file, if one
exists. Too many files are changed in one of the content directories.
(Typically, this happens if files are generated on the fly when
requested.)
Changes occurred to settings that control the restart/shutdown of the
ASP.NET worker process. These settings are read from machine.config
if you don't use Windows 2003 Server with the IIS 6.0 process model.
If you're talking full advantage of IIS 6.0, an application is
restarted if you modify properties in the Application Pools node of
the IIS manager.
If you change the web.config you app domain should also be reloaded and assemblies flushed.