Andrew Whitten's .NET Blog

Asp.Net install blues

Installing our new server product onto a new machine should be a piece of cake, right? You install Sql Server 2000, give it a nice Service Pack (3), make sure IIS (5 or 6) is up and running, installing .Net Framework 1.1... make sure Asp.Net is running, and if not use aspnet_regiis.exe in C:\WINNT\Microsoft.NET\Framework\v1.1.4322... then you are just about ready to start installing our product. Two MSI install packages, one of which installs some web services to a virtual directory, and likewise for a web application comprising of Asp.Net pages.

Our last server product required one install, and no pre-requisites. It could also only handle a maximum of 7 TCP-IP requests at any one time.

Therefore, for our new server, we have a detailed install guide, but with all these extra steps, the things that can go wrong are multiplied accordingly.

Yesterday, one of our implementors couldn't install on site... and he was unable to get the web services running, even though the Asp.Net pages were fine and dandy. He wasn't able able to send screen shots, so in the end he brought the box down for examination.

The problem was that the Asp.Net user could not write its assemblies to the c:\windows\temp directory.

There is a detailed fix for this problem on the MSDN site.. however, I couldn't access the access permissions tag in the properties dialog. The reason for this was the presence of a Novell Network client, although I have no understanding of Novell networks, and couldn't say why this would be a problem.

Until I find out why, I cranked up Asp.Net's user to 'administrator'... just like in IIS 5, and it works fine.

I guess this goes to show, that no matter how well you test something on your own network, things are very different out there in the wild.

MSDE saves the day

Since our product is designed to handle hundreds, if not thousands of connections, our engine is based upon Sql Server 2000.

I had to throw together a working version of our web services product onto a standard Windows 2000 Professional box today. Since I knew that the customer was only going to use one client with it, and time was pressing, I installed MSDE , and I am happy to say it works perfectly with our C# web services and ASP.Net pages.

For basic demos and evaluations, this is great, but I hope the sales team doesn't find out and sell our product to some customers without a Sql Server licence!

By the way, the new Web based administrator works fine with it too.

Infopath Service Pack 1

I've been integrating Infopath as a solution for many of our customers, and quite frankly, it takes a fair deal of pestering for it to play ball. The COM objects are hardly exposed to the outside world, making is near impossible for seamless communication between our client application and Infopath sitting on the same machine.

Infopath templates ( that define the look and structure of the form ) have a suffix called .XSN, which in fact is just a .CAB file with a different suffix. Inside this CAB are various files including Xsd files (the form's structure) and VBScript or JScript script files (the form's validation, logic and whatever else you may want it to do).

Such is the direction of Microsoft, that it is now possible to use managed code as well. I have yet to investigate the full implications of this, but I will be testing them out in my forthcoming integration project. The fully usable preview Infopath SP1 can be found here :

http://www.microsoft.com/downloads/details.aspx?familyid=D5ADC839-73F4-4299-ABA0-E88C90B25144&displaylang=en