My Experiences with ASP.NET PDC bits

Now that the ASP.NET sdk "pre-beta" has been released to the masses. Many people are scrambling to get it installed and start to play with C#, ASP.NET and many other toys that come with the SDK. Being the webmaster of ASPFree, I've had the privilege to work with two versions of ASP.NET builds. And I may add, how stable both versions have been! Its definitely been an experience, this article I hope to express some of the things to help guide individuals who have to install and support this in their environment.

First of all, "DON'T INSTALL ON YOUR PRODUCTION SERVERS!!", I can't stress this enough, this is "pre-beta" software. Microsoft WILL NOT support pre-beta software. ASPFree is "production" I guess, but it doesn't hurt anything if the site crashes or some pages don't display. The world won't come to an end, I use this environment to learn new technology and share with others. I do have a development machine that I test things before installing on the server that runs ASPFree. Some of the tricks I share in this article are just my own experiences. These are the things I found helpful in keeping the samples up and working for my visitors on ASPFree.com.

How do I get ASP.NET installed then?

Before I'd do anything, do a complete backup...even on your development machine. I'd recommend a fresh built machine with Windows 2000 and IIS 5.0, then install IE 5.5 and lastly the PDC ASP.NET bits. Many of the newsgroups I monitor, some people are having issues if they installed the PDC Visual Studio 7 beta then trying to put on the ASP.NET sdk. I can't comment to this because I haven't installed VS 7 beta. All I can say install in this order, a fresh install of Windows 2000 w/IIS 5.0, IE 5.5 and PDC build of ASP.NET . Things should work fine!.

What if I have Classic ASP applications on my server?

If your installing ASP.NET on a development machine with existing traditional ASP applications, things will work just fine. I've installed the ASP.NET bits many times and have yet to blow up any of my ASP pages. ASP.NET is designed to run side-by-side with existing ASP pages. If you doubt this claim, view ASPFree.com. Since day one, I've mixed .asp and .aspx pages together with NO problems at all!

The First Build story

We had a couple of small issues with the first build that was installed on ASPFree. It ran pretty good for about a week or so then we had a few odd things happen. Being "Pre-beta", I'd expected this to happen sooner. I was very happy how stable the beta's were and the small amount of issues I really had! When the samples would die or some other error popped-up, I'd re-compile the samples and that would take care of them. Considering the traffic load ASPFree.com visitors put on them, they held up very well.

You ask how did I re-compile the samples?

1. Open a command prompt.
2 Map to the NGWSSDKsamples directory. If you took the default install, its c:program filesngwssdksamples directory.
3. run nmake /all This will compile all of the samples again.

Another trick I found helpful when weird errors would come up, I'd use the "KILL.EXE" command that comes with the NT/2000 resource kit. This allows you to terminate processes without restarting the server.

To "kill the ASP.NET" process,

1. Open the task manager (Right click on the start-bar)
2. Find the process xspwp.exe and/or the PID(Process Identifer)
3. open a command window (Start, run, cmd)
4. Type in "kill xspwp.exe" or "kill xxxx(4-digit id number)
5. Using the kill command has proved useful in both builds of the SDK that has been used on ASPFree. The 1st build was somewhat buggy and once in awhile things basically stopped working. The PDC build, the one Microsoft just released to the world this week, is much more stable and I haven't had any problems.

Other strange things such as "This EVIL Process, NULL String in XXX" or whatever the error. Usually killing the xspwp.exe process and letting another one start up usually fixes things. Please keep in mind this article is based on "Pre-beta" software, using the kill command to fix these problems are rare now with one exception.

What is the XSPWP.exe process?

This is the worker process that handles all of the ASP.NET tasks.

 

Using the KILL command to help clean up virtual memory

Now this part is my own twisted way I came up with to keep the virtual memory down on my server. Another thing you could do is add more memory. I however didn't have this luxury right away so I had to invent something. Because the PDC build is "pre-beta", bugs are bound to pop up. When the ASP.NET bits gets installed, under the c:winntcomplusv2000.14.1812 is the global config.web. There is a section in the config.web that is called IISProcessmodel. This part allows for configuring how much of the server resources is used, how long the xspwp.exe process will live before another one is spun up etc.. Now please don't take these numbers and ones to use. These are just samples!

After consulting with Microsoft, they suggested I try adjusting the timeout, requestlimit and memorylimit.

Timeout: is for how long before a new xspwp.exe will be spun up.
Requestlimit: is a way to configure how many requests are handled before another process is spun up.
MemoryLimit: is a way to constrain so it doesn't suck all your virtual memory.

The nice thing I've seen after playing with different settings is this nice little error "Evil process didn't release lock on file! UNDONE: Rip or fix this exception". We emailed this error into Microsoft and they fixed it. The fix is probably going to be incorporated into the beta that is coming out. Once I changed the numbers back to the default, which basically are infinite numbers. Things worked fine.

In the mean-time, I run a scheduled kill command to not only keep the xspwp.exe file from taking all available virtual memory. So far, this hasn't caused any adverse side affects to the samples and things seem to be running fine!

In conclusion

I hope these article doesn't scare you, I meant what I said. "DON'T INSTALL ON YOUR PRODUCTION SERVERS!!". Your administrators will probably wonder why are they being called to support a beta product. This article doesn't cover the many things that already work out of the gate, dynamically installing dll's on the fly, caching to name a few. My opinion of this beta is such that enough of the features work out of the box. Take advantage of this period to start learning how the "Next Generation" of web development will be done.

Would I run a production environment on the current build? NO!

Is the current build very stable? Yes!!

I'm in a unique position with having this installed on ASPFree. I'm not only learning how to be a developer of ASP.NET, but also how ASP.NET will live on the server. I'm confident in the future builds, Microsoft will have the performance and resource management needs taken care of. Again this is "Pre-beta" software, but this is such a revolution and so many of the features work now! This head start will help the developer community take advantage of this awesome new technology. Any questions or comments let me know!

Steve Schofield
steve@aspfree.com