Best of the ISP-Lists

The Complexity of a .NET Environment

Members of the ISP-Webhosting list examine the intricacies of enforcing policies on IIS/.NET servers, as they object to being serving as developers' guinea pigs.

[September 19, 2002]

On the ISP-Webhosting list in August, SL asked,

"When hosting Microsoft .NET applications, must the development happen on the client's own machine, or can the development happen directly on the production server? I have seen numerous examples of doing the development 'locally,' then copying only necessary files to the 'live' server, but I'm wondering if there is any reason not to host the VS.NET project file on the server. Can this be done?"

PJ warned that it's not a great idea:

"It is definitely a 'best practice' to develop on a system that is not running live on the Internet, and then publish to the production server."

SL followed up to inquire as to whether or not it's possible—regardless of whether or not it's advisable:

"I understand that it's not 'best practice,' but some people either don't have IIS/.NET installed locally, or prefer to do their work 'online.' After all, they are paying for hosting, so they should be able to do it on the server they are paying to use. What are the 'gotchas' that a provider might run into if users are doing .NET development on a shared, public IIS server?"

A number of respondents suggested that it could have some very noticeable effects:

[RM observed] "Developing code on a live server is just about the stupidest thing any host could allow. It's not a great idea to run a piece of code live for the first time, because it could take your site down or even crash your server—not to mention the fact that you have no debug output on a live shared server, or access to the server itself other than your shared directory, so how can you really develop like this? But people do it. I have a government client: they were doing it for years, using the same server for staged and live sites, and doing direct development on this server with no backup development copy of code."

[MB added] "If it is a shared server, you'll have a performance hit if you have people accessing the system for live development. I would also expect it to cost you more in licensing, with multiple people accessing the same software. If you seriously want to do it, be sure to charge a lot of money for it."

Others acknowledged that it's difficult to enforce:

[SD offered] "We are also offering .NET hosting, and we have no limits regarding development on our servers or not, but till now, we haven't had any problems. Most of our .NET clients are web developers (resellers for our services) and I assume that most of the time they develop their sites on their own machines, but I don't know."

[RM admitted] "Obviously, enforcing this is a problem. But it is usually obvious who is doing it, because you will see from the FTP logs that certain customers are connecting excessively and uploading the same files over and over. You can usually identify a site in IIS that is causing out of process errors and hogging resources-then you can isolate this site by putting it in HIGH process and monitoring their activity."

[MB agreed] "This is probably the best way to enforce it. I have seen many Windows servers go down where IIS crashes, or DLLHOST hogs up all the CPU, simply because a customer wrote bad code. Sometimes I really don't think that Microsoft wrote Windows 2000 or IIS with shared webhosting providers in mind. There is nothing stopping someone from uploading a file and testing if it works or not: the question is how much access to the server you're willing to give them."

Others recommended some ways to help out customers who don't have development servers:

[RM noted] "We actually offer development servers for customers that do not have their own. We expressly forbid development on live servers, and try to provide a solution to people or small companies that do not have the ability to run their own development environment. We can do this cheaply, as no one is hosting anything from these servers, and we just give them a development subdomain to work from. In fact we just set up an entire rack of cheap servers that is intended for this type of use. We are offering customers a 1U dedicated server for £99 per month with 5 GB bandwidth, which is cheap enough and perfect for a remote development server."

[SD agreed] "I think that is the right approach. We are also offering two kinds of dedicated servers: 'el cheapo' servers with low bandwidth volume, and then the 'real' dedicated servers (more expensive, more bandwidth, better hardware)."

—End