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 -
