The Visual Basic .NET Experience

Sunday, 25 August 2002

It seems that Microsoft has admitted that their .NET marketing approach has caused confusion. It's now official. There has been too much of the .NET name, and not enough of the content. Well, I'm not sure what they intend to do to remedy the situation. Whatever they do, it won't change the minds of the Slashdotters. I am, perhaps, a little disappointed with the endless threads of, "Does anybody actually know what .NET is?" but then again, Slashdot is not the place to discuss Microsoft technology unless you're there the find out what's so darn wrong with it. Similarly don't go to www.microsoft.com to find out about the latest Linux kernel, unless you want to hear that open source is evil and a threat to the Western way of life.

Well, forget about that, I'm just padding this article. Late last month, I already had an idea of what .NET was supposed to do so the next step was clear. However, trying to get hold of an English copy of Visual Basic .NET in Japan is not the easiest thing to do. However, once I had the box in my hands I was joyous and anxious at the same time. Here it was, what I had been waiting for; the .NET stuff I had been spending so much time reading about. I could finally try my hand at this new technology. On second thoughts, I also considered that it was likely to be an uphill struggle and there was the installation process to worry about first.

Scareware

I backed up my primary Windows XP partition first and then launched the CD to install VB. NET. It didn't take long for the install to explain that I needed to install IIS on my PC first. To play with ASP.NET and all that stuff, Microsoft's web server needed to be activated on my PC. I had chosen to disable this particular puppy when I first installed XP. IIS is a web server and wants to broadcast its presence on the internet. As I was unfamiliar with IIS, I didn't want it resident on my machine, spitting packets out across the internet whenever I happen to be connected (yep, I don't have ADSL).

Caught between the need to play with Visual Studio and the comfort of a machine without IIS, I had to make a decision. There wasn't much to decide, really, so I opened the Add/Remove Programs icon in the control panel and told Windows to go ahead, inject my machine with IIS.

When the install was closing, my firewall ZoneAlarm popped up an alert, telling me that some new program wanted to be a server on the internet. Obviously, this was related to the IIS install. I wasn't connected to the internet, but I didn't want IIS thinking it go out and roam free, so I beat it over the head with a stick immediately. I told ZoneAlarm to deny access. Of course, the install then froze. After waiting a while, wondering whether the install might just spontaneously finish (pinning my hopes on the phrase "time out") I realized I had to kill the install with everybody's favourite Windows program, the Task Manager.

So I installed it again and decided - all right - IIS was going to win in the short term. I would let it access the internet just this once, but as I wasn't on-line I would have the last laugh. IIS installed, things quietened down and I finally went back to my Visual Studio install.

It wasn't as long as, say, a Windows OS install, but it wasn't short either. After conquering as much space as it could on my hard disk, Visual Studio .NET was ready and waiting.

Initial Impressions

I'd used the Visual Studio integrated debugging environment (IDE) before, through experience with VBA programming for Excel. There are some things I love about using the Visual Studio IDE. Firstly, it's so easy to debug. You can watch variables, put in breakpoints, step through code, even type commands directly into a window while execution is paused. Hover the pointer over variables and usually the contents of the variable will be shown as a tool tip. Secondly, Intellisense. As you type in commands or object names, then tool tips will appear highlighting possible arguments, methods or elements. This saves a lot of time if you can't quite remember the exact syntax. If this isn't good enough, you can jump into the object browser or use context-sensitive help by right-clicking the command.

These are good things which aren't going to go away but the IDE appears to have become more complicated since my experiences with VBA. There are now more windows than ever. Sure enough you can drag and drop everything around and get rid of what you don't want. However, I'm just starting out so I'm not sure what I don't want yet. Anyway, let me describe some of the new things that jump out at me.

There is a new feature that you can disable, but at the beginning you are likely to leave it active. Dynamic help. It's like an extension of Intellisense. As you type commands into the IDE window, a small dynamic help window will show help topics that are of immediate relevance to the command in question. This is not the demonic Office Assistant paperclip in another guise. The dynamic help window updates continuously, quietly, and if you feel a bit stuck you only have to look at the window. Already, all the help topics of interest are sitting there, available. If I start typing in the name of a text box object, then help for that object is immediately available in the window if I forget exactly how to use it.

Every developer is familiar with indentation. That is, if you create a new procedure, function, loop or conditional block of code, it's standard practice to indent the code inside the structure, to mark it as separate from the rest. This is for readability more than anything else. The new VS IDE goes one step further by allowing you to collapse such sections. Down the left-hand side of the code window, each loop or code fragment will have a set of markers bracketing the code. Just like in a File Explorer window, you can collapse the section and shrink it to a single line. I'm not sure how this will work out in practice - annoying or clever - but it looks like a smart idea at the outset.

There is another window dedicated to Server Connections. Expecting databases to be part of a programmer's life, DB connections can be managed in a separate window. Once you've got a connection made, you can interrogate the database using the straightforward graphical Microsoft Query interface - also embedded in the IDE.

[Visual Studio Screenshot]

I notice that we now have projects and solutions. Previously, everything I built in VBA was a "project". A solution just looks like a collection of projects but why this is necessary I'm not sure yet. I guess I'll have to get into an actual coding experience to work out the difference. Maybe this distinction won't really become apparent unless I work on something extensive.

In general, the IDE looks a little more crowded and actually more threatening to begin with. However, I quickly created a simple project TestBase to build up my confidence with Visual Studio. I was quite happy I could create something simple without too much effort but...

Nightmare on Elm Street

It seemed like a fun idea to try the debugger, so I could practice stepping through the code and see how things work. After hitting the button, Visual Studio froze. Better than that, I noticed that my task bar froze too. I waited, again thinking that surely things would work themselves out. Perhaps it was merely initializing, I hoped.

After slaying the application with my old friend the task manager, I was a bit stuck as to what I was supposed to do. I poked around the system a little and then discovered the situation was worse than I had realized. IIS properties, Front Page extensions and the performance control panel entry didn't work. Even more sinister, right-clicking "Properties" on any folder yielded no pop-up window. It was serious and I was going to have to resolve it.

I searched the web and the only similar issue was a problem where IIS would freeze during install because of a ZoneAlarm conflict. The way to circumvent that problem was to change the startup dependencies so that ZoneAlarm would start after IIS, otherwise it was likely to interfere with IIS startup.

A few days passed. After picking up the problem, dropping it and picking it up again, I looked at the task manager list. I noticed that a process I wasn't familiar with was eating a lot of CPU time: inetinfo.exe. I killed it, perhaps just out of spite, and then Windows suddenly came to life. All of the folder properties windows appeared, as well as the services windows that had been frozen. I had found my culprit.

Surprise, surprise, I discovered that inetinfo.exe was my old nemesis, IIS. I had blocked it with ZoneAlarm, permanently, so it had gone into hibernation, waiting for the long winter to abate. Of course, this wasn't going to happen, so a better analogy would have been cryogenic suspension. However, it had infected a number of aspects of my WinXP setup, which means half my PC was stuck in the freezer, too.

The solution, of course, was to leave IIS alone. Let it do its thing. Don't block it through ZoneAlarm without good reason. Change the startup dependencies and let IIS free, otherwise it'll sulk and cause you grief. My next task was to find out more about running IIS. I wanted to know more about how it works, to make sure I wasn't publishing my presence on the internet.

Things seems safe and sound now and I've disabled much of IIS from the inside, rather than trying to lock it in a box. Still, taught me how much I didn't know about Windows. Read on; I hadn't learnt enough.

Fool Me Twice, Shame On Me

Not content with the extra complexity already running amok inside my PC, I knew that I would need to unleash Microsoft SQL Server as well. I've mentioned in a previous article that a special mechanism has been developed to access Microsoft SQL Server, instead of the standard OLE DB mechanism. Of course, I didn't have the full-blown SQL Server to install, but what I did have was Microsoft SQL Desktop Engine 2000 (MSDE), which comes with Visual Studio.

Basically, MSDE is a cut-down SQL Server, although it's still powerful. There's no cool GUI tools to interact with the server, and it has an inbuilt maximum database size of 2 GB (small for industrial-strength applications). The idea is that once your application has become quite big and your database is pushing the 2 GB limit... you need to buy a license for the full-blown SQL Server. Another interesting point, I guess, is that if you are using the special functions specifically targeted at SQL Server, you can't go changing that code later if you choose a different DB server as that's too dangerous. However, it means smaller applications can now benefit from a powerful server engine - without going an open source route, that is - without the typical price tag associated with database server software.

Although I wasn't going to use it immediately, I wanted MSDE up and running as soon as possible. I wanted to start coding and get past all of this installation, configuration and tweaking. The install files had already been copied to my hard drive by the VB .NET install, so I just clicked on the install and let it fly. The progress bar moved up, bit by bit. It paused. It paused some more. Then the progress bar moved up to 100% - and dropped back to 0%! The window closed and I had this horrible feeling that the install had failed. No messages, no clues. Nothing.

There seemed to be nothing on my PC that suggested that the server had been installed, so I tried again. I rebooted, tried again. I tried switching off various processes like my virus scanner and firewall. All to no avail. Something was stopping it install and I had no idea what. I wasn't have much success searching for problems with MSDE installs on the web and I was beginning to think I might have to give up. The only success I had was to find an official announcement in the Windows event log that the install had failed.

It took a week for me to try something completely different. I noticed there were some log files in the Windows directory - all of which were useless, a bunch of red herrings. After I had finished exploring all of the red herrings, it occurred to me that perhaps there were some error messages being emitted by the installer that I couldn't see. Perhaps I should run the installer in a command window, see if it was trying to speak to me. It turned out that, no, it told me nothing, but I found something else of far more interest.

The installer had two command line options and one of them was supposed to generate a log file. I was ecstatic at finding this. I didn't hesitate; I ran it straight away and found myself the lucky recipient of a giant log file. It didn't take a long time to find out where the install had failed. At the end it was rolling back the install, so I just had to find out at which point it switched from installing to rolling back. I discovered that the SQLSecurityAgent install had failed. That was it, I had no idea why it had failed, but it had given me something else to go on. I took the message to Google and, sure enough, I found a bunch of posts on a web forum about this problem. As expected, I wasn't the first to experience it.

Turns out that there are a number of potential causes. Most of them are due to people tinkering with their Windows setup, like me. I had disabled the Server service, also known as File and Print Sharing, because I didn't need it. For some reason, without this service active, the install failed. Of course, I didn't get any nice bold messages why, which would have been nice. The install had simply disappeared in a puff of smoke.

After starting up the service, the next attempt at the MSDE install actually finished instead of winding back. Very quietly. MSDE almost feels like a hacked SQL Server implementation. There are barely any tools or documentation. There's no explanation about how to get the test databases up and running (like pubs2). It feels cold and unfriendly, an application with no voice, and I don't like that. Yes, sure I'm used to playing with Sybase on a UNIX operating system, but this is a Microsoft product which is supposed to be verbose through the language of the Windows GUI. It's not UNIX. There aren't any tools except the SQL Server Service Manager. There's nothing here. I can barely feel a pulse.

However, bear in mind that I'm just starting out, so in a year you may find me shouting about how great MSDE is.

Preview

I eventually decided to restore my Windows XP partition. I had been messing around so much to get Visual Studio to work, that I felt I should install again. It's been a few weeks now and I've just reinstalled. In fact, the VB .NET install failed first time, throwing up a dreaded blue screen with the message PROCESS_HAS_LOCKED_PAGES, but went through fine on the second time after a fresh reboot.

I want to get to grips with .NET and the best way to do that is to build some pet projects. I have two projects that I'd like to work on.

The first project is a sequel to the Word Master Excel project I built in 2000-01. They'll be another page up on Wander soon enough, covering Word Master. Word Master was a foreign language learning program; the "database" of the program was an Excel spreadsheet. The sequel project will be written in VB .NET, have a different design and backed up by, possibly, an Access database. The objective is to become familiar with Windows Forms and ADO.NET (for generic databases) within VB .NET.

The second project I'd like to try is a tool that creates an intranet site whose purpose is to distribute software project information. Admittedly, I could probably produce this kind of intranet site with City Desk, but that isn't the point. The web site would be dynamic not static, generated by Microsoft IIS and backed up with a MSDE 2000 engine. The objective is to become familiar with ASP.NET and ADO.NET for SQL server databases; a bonus will be to learn how to deploy and maintain an instance of Microsoft SQL Server.

So, the long and short of it is that I haven't really got anywhere yet, but hopefully the main teething problems are out of the way. Fingers crossed.

End