By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,365 Members | 1,245 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,365 IT Pros & Developers. It's quick & easy.

Modifying application folder structure results in application restart- How to stop?

P: n/a

Ok, we are all aware of the situation where modifying the folder
structure (adding files, folders, deleting files, etc) will result in
ASP.NET triggering a recompilation/restart of the application.

In a nutshell, I understand how this can be considered desireable by
some, but I am not one of those people.

My situation is that we have a root site (hosted @ http://www.mydomain.com)
in the root application folder '/'.

This is an ASP.NET 2.0 application, running in it's own application
pool. It is sporatically updated (receives about 1 production build
per quarter). This site isn't allowed to be down.... ever... :)

Beneath this site, in '/content/someOtherApplication' is running an
older .NET 1.1 application in a seperate application pool, configured
as an application in IIS......that receives almost daily updates.

So, when a new build to /content/someOtherApplication is pushed, the
root application '/' restarts as well.

Definitely a bad situation, and something I am looking to avoid.

Aside from telling me to put things in non-nested virtual directories
(which is absolutely not an option), what can I do?

In a perfect world, I would like to simply tell ASP.NET to NOT restart
the apps automagically, but I suspect there is some other means to
configure this so that I can retain that 'feature' for appropriate
scenarios.

Thanks in advance.
Jun 27 '08 #1
Share this Question
Share on Google+
5 Replies


P: n/a
asp.net runs a file monitor and recycles on any change in any folder under
its vdir except app_data. you have a couple options.

1) switch to fat file system that does not support file monitoring

2) place the sub apps under the app_data folder.

3) (most logical) do not have the /content physical file folder under the
root app's file folder, but create the vdir under the root.
-- bruce (sqlwork.com)
"IUnknown" wrote:
>
Ok, we are all aware of the situation where modifying the folder
structure (adding files, folders, deleting files, etc) will result in
ASP.NET triggering a recompilation/restart of the application.

In a nutshell, I understand how this can be considered desireable by
some, but I am not one of those people.

My situation is that we have a root site (hosted @ http://www.mydomain.com)
in the root application folder '/'.

This is an ASP.NET 2.0 application, running in it's own application
pool. It is sporatically updated (receives about 1 production build
per quarter). This site isn't allowed to be down.... ever... :)

Beneath this site, in '/content/someOtherApplication' is running an
older .NET 1.1 application in a seperate application pool, configured
as an application in IIS......that receives almost daily updates.

So, when a new build to /content/someOtherApplication is pushed, the
root application '/' restarts as well.

Definitely a bad situation, and something I am looking to avoid.

Aside from telling me to put things in non-nested virtual directories
(which is absolutely not an option), what can I do?

In a perfect world, I would like to simply tell ASP.NET to NOT restart
the apps automagically, but I suspect there is some other means to
configure this so that I can retain that 'feature' for appropriate
scenarios.

Thanks in advance.
Jun 27 '08 #2

P: n/a
Actually from my experience it does recycle on create/rename sub folder
event in app_data. Not sure about file's events.

George.

"bruce barker" <br*********@discussions.microsoft.comwrote in message
news:5E**********************************@microsof t.com...
asp.net runs a file monitor and recycles on any change in any folder under
its vdir except app_data. you have a couple options.

1) switch to fat file system that does not support file monitoring

2) place the sub apps under the app_data folder.

3) (most logical) do not have the /content physical file folder under the
root app's file folder, but create the vdir under the root.
-- bruce (sqlwork.com)
"IUnknown" wrote:
>>
Ok, we are all aware of the situation where modifying the folder
structure (adding files, folders, deleting files, etc) will result in
ASP.NET triggering a recompilation/restart of the application.

In a nutshell, I understand how this can be considered desireable by
some, but I am not one of those people.

My situation is that we have a root site (hosted @
http://www.mydomain.com)
in the root application folder '/'.

This is an ASP.NET 2.0 application, running in it's own application
pool. It is sporatically updated (receives about 1 production build
per quarter). This site isn't allowed to be down.... ever... :)

Beneath this site, in '/content/someOtherApplication' is running an
older .NET 1.1 application in a seperate application pool, configured
as an application in IIS......that receives almost daily updates.

So, when a new build to /content/someOtherApplication is pushed, the
root application '/' restarts as well.

Definitely a bad situation, and something I am looking to avoid.

Aside from telling me to put things in non-nested virtual directories
(which is absolutely not an option), what can I do?

In a perfect world, I would like to simply tell ASP.NET to NOT restart
the apps automagically, but I suspect there is some other means to
configure this so that I can retain that 'feature' for appropriate
scenarios.

Thanks in advance.

Jun 27 '08 #3

P: n/a
re:
!Actually from my experience it does recycle on create/rename sub folder event in app_data.

Filesystemwatcher events are supposed to be ignored by the ASP.NET runtime.

App_Data is designed not to respond to this filesystemwatcher behavior.

Since directories are a special type of file, anyway, directory changes under App_Data
aren't supposed to trigger filesystemwatcher behavior...but you're right, they do.

"ASP.NET developers know that if you create a new file , modify any file in the application
root or the /bin folder, or modify web.config, this will trigger an application restart."

As a result of extensive testing, using Web Application Projects,
I've found that these are the file events which trigger application restarts :

1. Adding, modifying, or deleting any source code file in any application folder ( *.cs, *.vb, etc. )

2. Adding, modifying or deleting global.asax or web.config.

3. Adding, modifying or creating any assemblies in the /bin folder

4. Adding, modifying, or deleting localization resources
from the App_GlobalResources or App_LocalResources folders.

5. Adding, modifying, or deleting source code files in the App_Code directory.

6. Adding, modifying, or deleting Profile configuration.

7. Adding, modifying, or deleting Web service references in the App_WebReferences directory.

8 Adding, renaming or deleting any directory.

*** If anybody knows of any other event which triggers an application restart,
if a WAP is used, please post the info so the list can be updated. ***

Regarding "standard" web site projects, I need to do more testing,
but I suspect that application restarts won't occur when a single
source file is modified, unless it's located in App_Code.

That would leave items 2-8 in the above list, eliminating only item 1.

*** If anybody has tested the website project scenario and found
different behavior, please post the info so the list can be updated. ***


Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================
"George Ter-Saakov" <gt****@cardone.comwrote in message news:O1**************@TK2MSFTNGP06.phx.gbl...
Actually from my experience it does recycle on create/rename sub folder event in app_data. Not sure about file's
events.

George.

"bruce barker" <br*********@discussions.microsoft.comwrote in message
news:5E**********************************@microsof t.com...
>asp.net runs a file monitor and recycles on any change in any folder under
its vdir except app_data. you have a couple options.

1) switch to fat file system that does not support file monitoring

2) place the sub apps under the app_data folder.

3) (most logical) do not have the /content physical file folder under the
root app's file folder, but create the vdir under the root.
-- bruce (sqlwork.com)
"IUnknown" wrote:
>>>
Ok, we are all aware of the situation where modifying the folder
structure (adding files, folders, deleting files, etc) will result in
ASP.NET triggering a recompilation/restart of the application.

In a nutshell, I understand how this can be considered desireable by
some, but I am not one of those people.

My situation is that we have a root site (hosted @ http://www.mydomain.com)
in the root application folder '/'.

This is an ASP.NET 2.0 application, running in it's own application
pool. It is sporatically updated (receives about 1 production build
per quarter). This site isn't allowed to be down.... ever... :)

Beneath this site, in '/content/someOtherApplication' is running an
older .NET 1.1 application in a seperate application pool, configured
as an application in IIS......that receives almost daily updates.

So, when a new build to /content/someOtherApplication is pushed, the
root application '/' restarts as well.

Definitely a bad situation, and something I am looking to avoid.

Aside from telling me to put things in non-nested virtual directories
(which is absolutely not an option), what can I do?

In a perfect world, I would like to simply tell ASP.NET to NOT restart
the apps automagically, but I suspect there is some other means to
configure this so that I can retain that 'feature' for appropriate
scenarios.

Thanks in advance.



Jun 27 '08 #4

P: n/a
Wow, that is extensive testing...Want to add to this list

9. You can make 15 (by default, configurable) changes to .aspx files with
out triggering restart. After 15th, application will restart. Does not
matter what changes to HTML or to code that is in <script runat=server>

George.

"Juan T. Llibre" <no***********@nowhere.comwrote in message
news:%2***************@TK2MSFTNGP05.phx.gbl...
re:
!Actually from my experience it does recycle on create/rename sub folder
event in app_data.

Filesystemwatcher events are supposed to be ignored by the ASP.NET
runtime.

App_Data is designed not to respond to this filesystemwatcher behavior.

Since directories are a special type of file, anyway, directory changes
under App_Data
aren't supposed to trigger filesystemwatcher behavior...but you're right,
they do.

"ASP.NET developers know that if you create a new file , modify any file
in the application
root or the /bin folder, or modify web.config, this will trigger an
application restart."

As a result of extensive testing, using Web Application Projects,
I've found that these are the file events which trigger application
restarts :

1. Adding, modifying, or deleting any source code file in any application
folder ( *.cs, *.vb, etc. )

2. Adding, modifying or deleting global.asax or web.config.

3. Adding, modifying or creating any assemblies in the /bin folder

4. Adding, modifying, or deleting localization resources
from the App_GlobalResources or App_LocalResources folders.

5. Adding, modifying, or deleting source code files in the App_Code
directory.

6. Adding, modifying, or deleting Profile configuration.

7. Adding, modifying, or deleting Web service references in the
App_WebReferences directory.

8 Adding, renaming or deleting any directory.

*** If anybody knows of any other event which triggers an application
restart,
if a WAP is used, please post the info so the list can be updated. ***

Regarding "standard" web site projects, I need to do more testing,
but I suspect that application restarts won't occur when a single
source file is modified, unless it's located in App_Code.

That would leave items 2-8 in the above list, eliminating only item 1.

*** If anybody has tested the website project scenario and found
different behavior, please post the info so the list can be updated. ***


Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================
"George Ter-Saakov" <gt****@cardone.comwrote in message
news:O1**************@TK2MSFTNGP06.phx.gbl...
>Actually from my experience it does recycle on create/rename sub folder
event in app_data. Not sure about file's
events.

George.

"bruce barker" <br*********@discussions.microsoft.comwrote in message
news:5E**********************************@microso ft.com...
>>asp.net runs a file monitor and recycles on any change in any folder
under
its vdir except app_data. you have a couple options.

1) switch to fat file system that does not support file monitoring

2) place the sub apps under the app_data folder.

3) (most logical) do not have the /content physical file folder under
the
root app's file folder, but create the vdir under the root.
-- bruce (sqlwork.com)
"IUnknown" wrote:
Ok, we are all aware of the situation where modifying the folder
structure (adding files, folders, deleting files, etc) will result in
ASP.NET triggering a recompilation/restart of the application.

In a nutshell, I understand how this can be considered desireable by
some, but I am not one of those people.

My situation is that we have a root site (hosted @
http://www.mydomain.com)
in the root application folder '/'.

This is an ASP.NET 2.0 application, running in it's own application
pool. It is sporatically updated (receives about 1 production build
per quarter). This site isn't allowed to be down.... ever... :)

Beneath this site, in '/content/someOtherApplication' is running an
older .NET 1.1 application in a seperate application pool, configured
as an application in IIS......that receives almost daily updates.

So, when a new build to /content/someOtherApplication is pushed, the
root application '/' restarts as well.

Definitely a bad situation, and something I am looking to avoid.

Aside from telling me to put things in non-nested virtual directories
(which is absolutely not an option), what can I do?

In a perfect world, I would like to simply tell ASP.NET to NOT restart
the apps automagically, but I suspect there is some other means to
configure this so that I can retain that 'feature' for appropriate
scenarios.

Thanks in advance.




Jun 27 '08 #5

P: n/a
re:
!Wow, that is extensive testing...

<chuckle>

I've sweated meatballs doing that.. <g>

re:
!Want to add to this list

!9. You can make 15 (by default, configurable) changes to .aspx files without
!triggering restart. After the 15th configurable change, the application will restart.
!It doesn't matter whether the changes are to HTML or to code that is in <script runat=server>

Thanks! Added to the list.

Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================
"George Ter-Saakov" <gt****@cardone.comwrote in message news:O4**************@TK2MSFTNGP03.phx.gbl...
Wow, that is extensive testing...Want to add to this list

9. You can make 15 (by default, configurable) changes to .aspx files with out triggering restart. After 15th,
application will restart. Does not matter what changes to HTML or to code that is in <script runat=server>

George.

"Juan T. Llibre" <no***********@nowhere.comwrote in message news:%2***************@TK2MSFTNGP05.phx.gbl...
>re:
!Actually from my experience it does recycle on create/rename sub folder event in app_data.

Filesystemwatcher events are supposed to be ignored by the ASP.NET runtime.

App_Data is designed not to respond to this filesystemwatcher behavior.

Since directories are a special type of file, anyway, directory changes under App_Data
aren't supposed to trigger filesystemwatcher behavior...but you're right, they do.

"ASP.NET developers know that if you create a new file , modify any file in the application
root or the /bin folder, or modify web.config, this will trigger an application restart."

As a result of extensive testing, using Web Application Projects,
I've found that these are the file events which trigger application restarts :

1. Adding, modifying, or deleting any source code file in any application folder ( *.cs, *.vb, etc. )

2. Adding, modifying or deleting global.asax or web.config.

3. Adding, modifying or creating any assemblies in the /bin folder

4. Adding, modifying, or deleting localization resources
from the App_GlobalResources or App_LocalResources folders.

5. Adding, modifying, or deleting source code files in the App_Code directory.

6. Adding, modifying, or deleting Profile configuration.

7. Adding, modifying, or deleting Web service references in the App_WebReferences directory.

8 Adding, renaming or deleting any directory.

*** If anybody knows of any other event which triggers an application restart,
if a WAP is used, please post the info so the list can be updated. ***

Regarding "standard" web site projects, I need to do more testing,
but I suspect that application restarts won't occur when a single
source file is modified, unless it's located in App_Code.

That would leave items 2-8 in the above list, eliminating only item 1.

*** If anybody has tested the website project scenario and found
different behavior, please post the info so the list can be updated. ***


Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================
"George Ter-Saakov" <gt****@cardone.comwrote in message news:O1**************@TK2MSFTNGP06.phx.gbl...
>>Actually from my experience it does recycle on create/rename sub folder event in app_data. Not sure about file's
events.

George.

"bruce barker" <br*********@discussions.microsoft.comwrote in message
news:5E**********************************@micros oft.com...
asp.net runs a file monitor and recycles on any change in any folder under
its vdir except app_data. you have a couple options.

1) switch to fat file system that does not support file monitoring

2) place the sub apps under the app_data folder.

3) (most logical) do not have the /content physical file folder under the
root app's file folder, but create the vdir under the root.
-- bruce (sqlwork.com)
"IUnknown" wrote:

>
Ok, we are all aware of the situation where modifying the folder
structure (adding files, folders, deleting files, etc) will result in
ASP.NET triggering a recompilation/restart of the application.
>
In a nutshell, I understand how this can be considered desireable by
some, but I am not one of those people.
>
My situation is that we have a root site (hosted @ http://www.mydomain.com)
in the root application folder '/'.
>
This is an ASP.NET 2.0 application, running in it's own application
pool. It is sporatically updated (receives about 1 production build
per quarter). This site isn't allowed to be down.... ever... :)
>
Beneath this site, in '/content/someOtherApplication' is running an
older .NET 1.1 application in a seperate application pool, configured
as an application in IIS......that receives almost daily updates.
>
So, when a new build to /content/someOtherApplication is pushed, the
root application '/' restarts as well.
>
Definitely a bad situation, and something I am looking to avoid.
>
Aside from telling me to put things in non-nested virtual directories
(which is absolutely not an option), what can I do?
>
In a perfect world, I would like to simply tell ASP.NET to NOT restart
the apps automagically, but I suspect there is some other means to
configure this so that I can retain that 'feature' for appropriate
scenarios.
>
Thanks in advance.
>
>
>





Jun 27 '08 #6

This discussion thread is closed

Replies have been disabled for this discussion.