Re: Re: Re: Re: Re: .Net help
Yeah, it's a bit tricky. The way it works is: you create an ASPX page with a code-behind file usually called aspx.vb. That page needs to be compiled into the CRL (common runtime language). The result is a DLL. That DLL, along with all other compiled DLLs, like other objects you've written in VB for example, needs to be placed into the BIN directory. Then, you copy the new ASPX page into the appropriate directory too (you dno't need to copy the VB or RESX pages -- they're now compiled into the DLL). Once the IIS server senses that a user hits that new aspx page, it also sees a new DLL file in the BIN directory, it then copies it to it's temporary holding directory and further compiles it there, leaving the BIN directory free for you to copy another version later. In this way, it seems to compile "just in time" and not tie up the DLL, forcing you to stop the IIS services to replace it like in the old days.
The only downfall to this are session variables. Changing any DLL, web.config, or global.asax, forces the application to restart, blowing away your session variables. If you use session variables to remember who is logged on, now it's gone and they're seemingly logged off automatically. The only other way around that is to use Out of Process Session variables. You need to change your web.config sessionState section to use "StateServer" mode and ask JodoHost to start a service called ASP.Net State Server on their web server. Now you can restart your application all you want without disrupting your session variables.
A little neat trick... in fact, the .Net State Server runs in a parallel thread, so if JodoHost has multi-processor web servers, it might make for a performance improvement... or, maybe it's not noticable at all!
-Dave