Click here to return to the Home Page

 

The .NET Platform
Tools & Components
COM & COM+
Data Access
Web Development
XML Technologies
Windows Servers
Wireless & Mobile
Security issues
Design & Process
Career Development
Analysis & Comment
Disposable Objects

Events Diary
Software Update

Contact Us
Advertisers

Search

 

And Another Thing

Server services, licensing, Terminal Services and Gobbledegook come under Jon Honeyball's scrutiny this month.

Server Services
"Wouldn't it be lovely if I could just...." This is the typical musings of a frustrated programmer, especially one who comes from the Visual Basic background. Multithreading, proper safe low level access and so forth have been just a few inches beyond our grasp in the past.
      However, I have been having great fun with the final release code of Visual Studio .NET. One thing I have always wanted to be able to do is to write my own monitoring tools to run on my server farm.
      Obviously, its best if these run as services rather than as applications, so they can survive without a logged in desktop session. In the past, you had to use hack-o-matic tools to get your application running as a service. With VS.NET, you just create the type of application you need - in my case a VB.NET Service Application.
      Being presented with the opportunity to write fully-fledged VB services is quite a thrill for an aging (and undoubtably sad!) Basic hacker like myself. Dammit, I did my Petzold initiation over a dozen years ago, and I see no reason to worry about WinMain() any more. Most of the things I want to monitor can be done via PerfMon scripts, or something equivalent. However, sometimes it is most useful to roll your own solution. VS.NET gives me the tools to do just that.
      I managed to get a server service running in not many minutes, mostly by stabbing at the dialog boxes until something appeared to install and run. It says something for the quality of the VS.NET user interface that such a cowboy approach can reap dividends.

Versioning
Can I put in a plea for some common sense? If you want your application to run on a desktop machine and not on servers, then make sure you are using the APIs in the OS which allow you to determine the version of the platform onto which you are installing and running. This is not hard, but it does pop up time and time again.
      It happened this morning. I had a blazing row with a solutions house. Their software installs perfectly happily onto Windows 2000 Server, but they are adamant it is licensed for 2000 Professional only. When pushed as to why this might be, they bleated on about how it was a desktop software solution and not aimed at the server marketplace. It appears that running the software on 2000 Server is considered a breach license.
      Yet there are many reasons why you might want to have Windows 2000 Server on a laptop, for example. Maybe you want to be able to demo a whole end-to-end line of business application which requires Server rather than Professional. In which case, logging into Server and tweaking the tasking settings will give you a Pro With Server Power Bits Attached. But no, according to the fools at this software house, that's a breach of contract. Some people seem to go out of their way to make it hard to do business!

Terminal Services
If you are deploying a server application out to a key customer, can I strongly recommend putting Terminal Services in Administrative Mode onto the target box? You will need to get the firewall managers to allow an incoming TS connection from your network to theirs, maybe via an encrypted VPN tunnel if you are really paranoid. But there is nothing quite like getting the real-time server loading information from a target server and seeing what is happening. It can be quite galling when you have developed a complex ASP/n-tier application and then have no real idea of what is happening out in the field.
      Of course, testing should have given good performance metrics, but there is nothing quite so sobering as a real-world test. Being able to TS onto the box in question is a godsend.

Gobbledegook
In the past, I had the warm comfortable feeling that I knew where everything was located on my desktop machine. All the folders made sense; everything had a structure and a place. Then along came the idea of redirected folders: 'My Documents' is somewhere on the hard disk, its position dictated by the login name.
      Now, with VS.NET, this has taken on a completely new and quite scary level. Can you work out where "c:\winnt\assembly\gac\system.drawing\
1.0.3300.0__b03f5f7f11d50a3a\systemdrawing.dll" is actually located? Isn't that a pathname that just trips off the tongue? Imagine having to tell that over the phone to someone fixing a dead computer. "No, I said 1.0.3300.0 and then TWO underscores, not THREE".
      There's even whole areas of your NTFS hard disk which you can't get into at all. Try attempting to get rid of old system breakpoint data by hand, for example. And what about those hidden files that Microsoft leave scattered all over the shop? Internet Explorer is notorious for this too.
      If things get much worse, we will have to start a Campaign For Clean Disks. Sign me up as a charter member, please!

Top of page
   Back to Articles

Copyright © 2002 Matt Publishing Limited. All rights reserved. No part of this site may be reproduced without the prior consent of the copyright holder.

 

 

 

 

 

 

Previous months

Nov 2002
Sept 2002
July 2002
May 2002

March 2002