As a follow up on this, I realized I could just use an out-of-process Session with very little headache (uses aspnet_state.exe instead of aspnet_wp.exe). I also found a way that I can push a single aspx page's class into the production DLL without needing to be synchronized with the trunk folder. You simply compile the .cs and designer.cs (and any dependent classes) and use il merge on (a copy of) the production DLL with the /allowDup option and the old version of the class will get renamed. Then just copy the modified DLL to the bin folder.
On Feb 5, 12:46 pm, jay <[email protected]> wrote: > Why do I need to repeatedly update classes during production server > uptimes? > > If I update it just once at any point in time, then all users will be > kicked off any page that relies on an in-process Session. By putting > the classes in a user control it allows me to deploy at any point in > time, and when a page that uses that class is refreshed, it will > recieve that new functionality. On the other hand, If I simply update > a class in App_Code and copy it to the production server, then all > users will be kicked off the page. While it is obviously not pretty, > and probably generates the page slower on the server, I find it more > flexible in terms of deployment. > > I would argue that they are not really two different elephants. > App_Code classes are JIT compiled, and so is the code within the User > Control whenever the page is requested. The difference is that the > AppDomain does not get recycled, and users do not lose their Session > (assuming an in-process session). > > On Feb 5, 1:11 am, Cerebrus <[email protected]> wrote: > > > > > You have not answered my (straightforward) question. > > > On Feb 4, 8:37 pm, jay <[email protected]> wrote: > > > > By putting common code in the ascx it allows two aspx files to share > > > that code without having to modify the contents of App_Code. > > > Modifying the contents of App_Code or modifying /bin results in the > > > Session being reset for all users (for "in-process" sessions). > > > However this is not the case if you modify just the ascx on the server > > > since it gets JIT compiled anyway. So, for example, if some users are > > > using an application that depends on Session, and another user is > > > using another application which he reports as broken, then using this > > > work-around, you could update the second application without affecting > > > the first application.- Hide quoted text - > > > - Show quoted text -- Hide quoted text - > > - Show quoted text -
