We’re rewarding the question askers & reputations are being recalculated! Read more.
3 Added a note about MEF being part of the .NET framework, the possibilty of using code-in-front model and also mentioned load-balancers.
source | link

You could also look into using something like the Managed Extensibility Framework (MEF) (MEF - which has been a full part of the .NET framework since version 4) which allows you to write a plugin based architecture and specify a folder outside of your /bin/ directory to monitor for new .DLLs - although I've not tried this to see if it will avoid the app restart issue, I have used this to good effect in a web environment for adding common functionality to a site.

If that doesn't appeal, the only other option I can think of would be to add the controls as "code-in-front" as we did in classic ASP - i.e. with a <script runat="server"> block instead of a compiled "code-behind" class that contains the logic to run the control - this will remove the need for a DLL change, at the expense of some first-time performance loss as the control is compiled on the fly - again you'll need to balance this with the NumRecompilesBeforeAppRestart if you're doing lots of little changes.

How do I persist sessions across app restarts?

This way you will have persistent sessions that survive an app restart. However, these aren't "free" - everything you store in session must now be serializable, and you will incur a slight performance hit as each page load will now require additional network trips to get, and potentially release the session data.

However, if you're in a position where it takes "several minutes" for the application to restart after a deployment, you may want to consider moving to a load-balanced environment, or at the least a hot-swappable Staging/Live setup (such as that provided by Azure/AWS/etc.) - this way you can take a server offline while you update it or get it ready with the new code and then swap it in - provided you've taken the steps to address shared sessions (see above) this will work fine with no impact to your users.

You could also look into using something like the Managed Extensibility Framework (MEF) which allows you to write a plugin based architecture and specify a folder outside of your /bin/ directory to monitor for new .DLLs - although I've not tried this to see if it will avoid the app restart issue, I have used this to good effect in a web environment for adding common functionality to a site.

How do I persist sessions across app restarts?

This way you will have persistent sessions that survive an app restart. However, these aren't "free" - everything you store in session must now be serializable, and you will incur a slight performance hit as each page load will now require additional network trips to get, and potentially release the session data.

You could also look into using something like the Managed Extensibility Framework (MEF - which has been a full part of the .NET framework since version 4) which allows you to write a plugin based architecture and specify a folder outside of your /bin/ directory to monitor for new .DLLs - although I've not tried this to see if it will avoid the app restart issue, I have used this to good effect in a web environment for adding common functionality to a site.

If that doesn't appeal, the only other option I can think of would be to add the controls as "code-in-front" as we did in classic ASP - i.e. with a <script runat="server"> block instead of a compiled "code-behind" class that contains the logic to run the control - this will remove the need for a DLL change, at the expense of some first-time performance loss as the control is compiled on the fly - again you'll need to balance this with the NumRecompilesBeforeAppRestart if you're doing lots of little changes.

How do I persist sessions across app restarts?

This way you will have persistent sessions that survive an app restart. However, these aren't "free" - everything you store in session must now be serializable, and you will incur a slight performance hit as each page load will now require additional network trips to get, and potentially release the session data.

However, if you're in a position where it takes "several minutes" for the application to restart after a deployment, you may want to consider moving to a load-balanced environment, or at the least a hot-swappable Staging/Live setup (such as that provided by Azure/AWS/etc.) - this way you can take a server offline while you update it or get it ready with the new code and then swap it in - provided you've taken the steps to address shared sessions (see above) this will work fine with no impact to your users.

2 added 6 characters in body
source | link

There are a number of ways to handle what you're asking for, and a few different aspects to your question:

Handle small updates for promotions

What you're really after here is a content management system or similar that allows you to edit the content on the fly (think Wordpress/Drupal or from a .NET point of view N2 CMS, Umbraco, Orchard, etc.), however there are some things you could try if you haven't gone down that route.

Because ASP.NET only really reloads if you touch certain types of file (web.config(s), the contents of the /bin/ and /app_code/ folders mostly) - and has a configurable limit for "other file changes" (basically once you've modified so many files within your site the application pool will restart - NumRecompilesBeforeAppRestart) you could look at doing something where you check a different folder for some static (i.e. .html) files that you pull in and display as needed, or utilise the LoadControl method that takes a string path to an .ascx user control and dynamically loads it - how you determine which to show however is is a different question more suited to StackOverflow - however I'd recommend a naming convention based solution.

You could also look into using something like the Managed Extensibility Framework (MEF) which allows you to write a plugin based architecture and specify a folder outside of your bin/bin/ directory to monitor for new .DLLs, - although I've not tried this to see if it will avoid the app restart issue -, I have used this to good effect in a web environment for adding common functionality to a site.

How do I persist sessions across app restarts?

This is possibly an easier issue to solve and involves three key steps:

  1. Configure the MachineKey (IIS7, but still holds for 8) to be a constant value rather than AutoGenerate - this means that when the AppPool recycles it will use the same key, and so will be able to decrypt session cookies, viewstate, etc. from before the recycle.
  2. Either setup a State Server or configure a Database to hold Session State.
  3. Switch from using InProc to StateServer or SQLServer in the SessionState element in your web.config.

This way you will have persistent sessions that survive an app restart. However, these aren't "free" - everything you store in session must now be serializable, and you will incur a slight performance hit as each page load will now require additional network trips to get, and potentially release the session data.

There are a number of ways to handle what you're asking for, and a few different aspects to your question:

Handle small updates for promotions

What you're really after here is a content management system or similar that allows you to edit the content on the fly (think Wordpress/Drupal or from a .NET point of view N2 CMS, Umbraco, Orchard, etc.), however there are some things you could if you haven't gone down that route.

Because ASP.NET only really reloads if you touch certain types of file (web.config(s), the contents of the /bin/ and /app_code/ folders mostly) - and has a configurable limit for "other file changes" (basically once you've modified so many files within your site the application pool will restart - NumRecompilesBeforeAppRestart) you could look at doing something where you check a different folder for some static (i.e. .html) files that you pull in and display as needed, or utilise the LoadControl method that takes a string path to an .ascx user control and dynamically loads it - how you determine which to show however is a different question more suited to StackOverflow - however I'd recommend a naming convention based solution.

You could look into using something like the Managed Extensibility Framework (MEF) which allows you to write a plugin based architecture and specify a folder outside of your bin directory to monitor for new .DLLs, although I've not tried this to see if it will avoid the app restart issue - I have used this to good effect in a web environment for adding common functionality to a site.

How do I persist sessions across app restarts?

This is possibly an easier issue to solve and involves three key steps:

  1. Configure the MachineKey (IIS7, but still holds for 8) to be a constant value rather than AutoGenerate - this means that when the AppPool recycles it will use the same key, and so will be able to decrypt session cookies, viewstate, etc. from before the recycle.
  2. Either setup a State Server or configure a Database to hold Session State.
  3. Switch from using InProc to StateServer or SQLServer in the SessionState element in your web.config.

This way you will have persistent sessions that survive an app restart. However, these aren't "free" - everything you store in session must now be serializable, and you will incur a slight performance hit as each page load will now require additional network trips to get, and potentially release the session data.

There are a number of ways to handle what you're asking for, and a few different aspects to your question:

Handle small updates for promotions

What you're really after here is a content management system or similar that allows you to edit the content on the fly (think Wordpress/Drupal or from a .NET point of view N2 CMS, Umbraco, Orchard, etc.), however there are some things you could try if you haven't gone down that route.

Because ASP.NET only really reloads if you touch certain types of file (web.config(s), the contents of the /bin/ and /app_code/ folders mostly) - and has a configurable limit for "other file changes" (basically once you've modified so many files within your site the application pool will restart - NumRecompilesBeforeAppRestart) you could look at doing something where you check a different folder for some static (i.e. .html) files that you pull in and display as needed, or utilise the LoadControl method that takes a string path to an .ascx user control and dynamically loads it - how you determine which to show is a different question more suited to StackOverflow - however I'd recommend a naming convention based solution.

You could also look into using something like the Managed Extensibility Framework (MEF) which allows you to write a plugin based architecture and specify a folder outside of your /bin/ directory to monitor for new .DLLs - although I've not tried this to see if it will avoid the app restart issue, I have used this to good effect in a web environment for adding common functionality to a site.

How do I persist sessions across app restarts?

This is possibly an easier issue to solve and involves three key steps:

  1. Configure the MachineKey (IIS7, but still holds for 8) to be a constant value rather than AutoGenerate - this means that when the AppPool recycles it will use the same key, and so will be able to decrypt session cookies, viewstate, etc. from before the recycle.
  2. Either setup a State Server or configure a Database to hold Session State.
  3. Switch from using InProc to StateServer or SQLServer in the SessionState element in your web.config.

This way you will have persistent sessions that survive an app restart. However, these aren't "free" - everything you store in session must now be serializable, and you will incur a slight performance hit as each page load will now require additional network trips to get, and potentially release the session data.

1
source | link

There are a number of ways to handle what you're asking for, and a few different aspects to your question:

Handle small updates for promotions

What you're really after here is a content management system or similar that allows you to edit the content on the fly (think Wordpress/Drupal or from a .NET point of view N2 CMS, Umbraco, Orchard, etc.), however there are some things you could if you haven't gone down that route.

Because ASP.NET only really reloads if you touch certain types of file (web.config(s), the contents of the /bin/ and /app_code/ folders mostly) - and has a configurable limit for "other file changes" (basically once you've modified so many files within your site the application pool will restart - NumRecompilesBeforeAppRestart) you could look at doing something where you check a different folder for some static (i.e. .html) files that you pull in and display as needed, or utilise the LoadControl method that takes a string path to an .ascx user control and dynamically loads it - how you determine which to show however is a different question more suited to StackOverflow - however I'd recommend a naming convention based solution.

You could look into using something like the Managed Extensibility Framework (MEF) which allows you to write a plugin based architecture and specify a folder outside of your bin directory to monitor for new .DLLs, although I've not tried this to see if it will avoid the app restart issue - I have used this to good effect in a web environment for adding common functionality to a site.

How do I persist sessions across app restarts?

This is possibly an easier issue to solve and involves three key steps:

  1. Configure the MachineKey (IIS7, but still holds for 8) to be a constant value rather than AutoGenerate - this means that when the AppPool recycles it will use the same key, and so will be able to decrypt session cookies, viewstate, etc. from before the recycle.
  2. Either setup a State Server or configure a Database to hold Session State.
  3. Switch from using InProc to StateServer or SQLServer in the SessionState element in your web.config.

This way you will have persistent sessions that survive an app restart. However, these aren't "free" - everything you store in session must now be serializable, and you will incur a slight performance hit as each page load will now require additional network trips to get, and potentially release the session data.