Visual Basic .NET

Considering that Visual Studio .NET is really a Version 1.0 product (wellllll ... 1.1 now), it's pretty good. But, of course, the technology is still changing fast and VS.NET is going to change even more in the future.

The next version of VS.NET - due in 2004 - is now code named, "Whidbey" and you can already hear the Microsoft marketing drums beating about it. You can read the "top ten" list for Whidbey innovations from a couple of programmers by clicking here. And it's definitely by and for programmers rather than the sort of thing you get from the Microsoft marketing department. It's worth reading!

(By the way, one of the most anticipated new features that will be in Whidbey is "edit and continue" which was in VB 6 debug, but is missing in VB.NET. For those who might still be getting jazz from C# programmers, edit and continue was never part of C# and won't be in the Whidbey C# either!)

But the real reason that we're certain to get the Whidbey release of Visual Studio is that Microsoft is also going to be introducing a whole new SQL Server (code-named "Yukon") which will also have a Common Language Runtime (CLR) - the big .NET change for Visual Basic .NET - built into it. In other words, "Yukon" will become more like a development language than it already is. Visual Studio will have to be seriously upgraded to allow developers to take advantage of this change.

Smart TagsIn addition to "edit and continue", Microsoft is planning some "dazzle the demo" enchancements in Whidbey. For example, the Intellisense feature of VS.NET that suggests code for you as you type will be expanded to included the Smart Tags that you see in Office 2003 today. So in addition to being able to complete "Boolean" for you, if you persist in spelling it wrong, Smart Tags will suggest alternatives in a menu.

If that wasn't enough, Microsoft is also planning yet another version beyond that - due in 2005 - and they even have another code name for it. It's being called "Orcas" in the press releases. The reason this one will be necessary is that Microsoft is busily creating a whole new version of their Windows operating systems that will be as much of a revolution as .NET was for programming. They're calling the new version of the Windows OS "Longhorn" (named for the bugle that Microsoft PR people blow to try to get your attention, I guess).

With new Visual Studio versions scheduled every year, some of you might be saying, "Hey ... I think I'll just wait until the rush hour is over and then jump in!" In fact, a lot of you are saying that. It's a major problem for Microsoft marketing! But a lot of you are wrong. Here are some reasons why you're probably wiser to upgrade and start the learning process now. If you plan to continue programming, it really boils down to a question of whether you want to go to VB.NET at your own pace now, or be forced into it later.

* The big break happened when VS.NET was announced ... everything into the future as far as we can see is going to build on that base. Unless you plan on staying with Visual Studio 6, you might as well get on board anyplace you can.
* Microsoft is tilting their marketing plans to make it cheaper to upgrade. Actually, they always have. And they're tilting their technical support that way too. Gradually it will become harder and harder to find good reliable answers about VB 6.
* The new stuff is tough - no question. But it's never going to get any easier. All you accomplish by waiting is to pile up more new stuff to learn than there is now.

... and the knockout punch of a reason, as far as I'm concerned ...

* You can simply do so much more with .NET than you ever could with VB 6 level technology. If you don't move up, you just won't be competitive.



After you work with VS.NET, you will be convinced that it's one of the most 'configurable' systems you have ever seen. When you have selected a project to open after configuring options on the Start Page, you will see a screen somthing like this illustration of a typical VS.NET desktop. Since this view still shows only part of the windows that are available to you, it should be enough to convince anyone that it's a complex system just packed full of different programming tools and features.

The basic idea is the same as VB 6. In a standard Windows Application, you can drag and drop components from the Toolbox onto a design Form. Then you select Properties for components and enter program code into a code window. Like VS 6, VS.NET includes a full featured Debug environment where you can watch your code execute statement at a time. (There is not as much flexibility to change your code and continue executing as there is in VB 6. This is something Microsoft hears complaints about constantly - they call it "Edit and Continue" in their publicity - and they have pledged to fix it in the next major release called, "Whidbey".) Once your program runs the way you want it to, you can Build an executable version of your program.


But the "basic idea" doesn't begin to describe the new tricks available!

One way to look at all of the new stuff in VS.NET is to classify things into these two categories:

* IDE Features
* Language Features

The Language Features are the things you have to know about Visual Basic .NET and how to use it in Visual Studio. For example, how to add References, new program Modules, and what all the components in the Toolbox are for. Since "Language Features" are what most of the rest of the .NET focused articles at About Visual Basic are all about - and since this is an introduction to Visual Studio .NET - we're going to focus on the IDE Features in this lesson instead. If you're familiar with the Visual Studio 6 IDE, get ready for some kewl new tricks.

OptionsBuried in the General page of the Environment folder in the Options dialog box under the Tools menu item - (whew!) - you will find a little noticed setting which allows you to work in either Multiple Document Interface (MDI) or Tabbed Documents mode. The default is Tabbed Documents mode and that's what the rest of this lesson will assume. If you select the MDI mode, however, you can tile or cascade the windows but your ability to dock them is lost. If you want something that looks just a little more like the old Visual Studio 6, MDI mode will help, but MDI style windows seem to be losing popularity compared with docking windows.
VS.NET

In Tabbed Documents mode, the ability to rearrange all of your windows into docked or tabbed windows gives you as much control over how your development environment looks as you could ever wish for. You could undock all of the windows and have one that looks like this. Notice that these new windows overlap the borders of the parent. Microsoft calls these Floating windows.

Alternatively, you could dock all of the windows and then drag them to tabbed positions and end up with one "utility window" that looks something like this. All of this is done by dragging and dropping the windows using "click and hold" movements on the Title Bar with the left mouse button. If you haven't done it before, it will probably take some practice before you can do it quickly and easily. Remember ... your "Environment" must be set to Tabbed Documents mode before you can do this. And double clicking the Title Bar will reset the whole thing to tiled windows again. It's a dynamic environment!

When you first work with these sticky windows, you may be more confused than anything else. It's often very unclear when windows will dock and where they will dock. The Whidbey release of Visual Studio - due out in a few months - will add a visual indicator on the screen showing you where windows will dock.
Tabs instead of Windows

Another new trick is the use of the Auto Hide "push pin" to move windows to tabs that line up along the sides of the window, or expand out when you sweep the mouse over them. Clicking the push pin will "pin" the window in a displayed position so you can work with it. But if you just wanted to check some information in the window, it disappears back against the sides of the window when the mouse pointer isn't over it. When the window is expanded, you can click and drag the the inside border to make all the information visible just like you would a normal window.

This combination makes maximum use of your monitor area while still making all of the windows you need available in a single mouse motion and it's my favorite configuration for working.

If a window is floating and you want to move it into an Auto Hide position against one margin, you first have to dock it to the side you want it to be on. Then click the Auto Hide push pin to make it disappear into a tab on that margin.

One thing to keep in mind if you're moving windows around a lot is that you can normally only dock windows once they're "pinned" to the desktop. If they're in Auto Hide mode, then you just can't select them and move them around. So if you want to move a window, make sure it's pinned first.
Auto Hide windows

If you move a lot of windows to one margin (usually - more than three, depending on your monitor size and settings), you can't see the tabs for some of them because they don't resize automatically like, for example, the Windows XP Task Bar. VS.NET has another trick for this. Right click on the margin and you can select the window you want from a context menu.

And finally, after all this experimentation, you might find that you have such a confused configuration of windows, tabs, and pop out menus that you just want to get things back to normal. We've got you covered! Reset your window layout using Tools > Options > Environment > General. Click the Reset Window Layout button.

You'll read more about this later, but the next release of Visual Studio - Whidbey - will allow you to export your development settings so you can, for example, install settings from your main development computer into a laptop.


Another new thing about VB.NET ... and Visual Studio .NET ... is the file structure that is maintained behind the scenes. One of the benefits that this brings is the ability to deploy the app's that you write by simply copying the files to a directory - sometimes called XCopy deployment because it's just like the way we used to do it with the old DOS XCopy command. In fact, there's a new trend back to actually using XCopy in a DOS batch file to deploy simple applications.

Between the time of DOS ... the real DOS before Windows ... and .NET, DLL's had to be "registered" so the application would know how to find them. In this case, the DLL is known only by it's name and location to an app that needs to use it. If someone updates a DLL and copies it over the top of one with the same name (and this happens all too often when large and complex systems are installed), the system breaks.

As Cornell and Morrison wrote about "the old way" in their book, Programming VB.NET,

You have to register components in order to install programs and unregister them to remove the programs. When you try to uninstall a program, you run the risk that the changes the uninstaller might make to the Registry might affect lots of other programs. If you trash the Registry, nothing works.

That was ("is" for the many apps that still require it) a big hassle and it's called "DLL Hell" even by Microsoft. With VS.NET, there are no Registry changes that have to be made to deploy a simple application. Eliminating this problem is a major accomplishment of .NET and Visual Studio .NET handles it automatically.

Let's look at the file structures created for a typical Windows app to see how it works. You can see the structure created by a new Windows Application project as soon as it's opened at the top of the page. Compared to VB 6, this is a lot of structure!
Solution Files

If you're experienced with VB 6, this is related to another change in VS.NET that may catch you off guard. In VB 6, a lot of programmers are used to the idea of opening Visual Studio and "trying out some code" with confidence that as long as the project isn't saved, no files are saved on the hard drive. Visual Studio doesn't work that way! Not only is there a whole group of folders and files created as soon as a new project is opened, but changes to the project files are written as soon as you debug the application. If you "try out some code" in VS.NET, your experiment will become part of your program because it doesn't wait for you to click "Save" or "Save As". The Whidbey version of Visual Studio will solve this problem, and keep the benefits of a sophisticated file structure, by storing your projects in a temporary structure until you decide to save them.

We're going to look at the files saved by Visual Studio, but there are two things that need to be emphasized at this point.

* You won't be able to see all of the files unless you change your folder view options (Tools > Folder Options > View in Windows XP). The Windows default is to not be able to view "hidden" files and folders. Microsoft makes this the default because these files and folders are intended to be changed only with a tool ... like Visual Studio .NET!
* And this brings up the second thing you need to know. The main tool you will use to change some of these is the Solution Explorer window in VS.NET. So, although we're going to look the files and folders for purposes of understanding VS.NET, you should actually manage your programming solution in Visual Studio.

Before you write even one line of code, Visual Studio creates a couple of solution files at the top level of your application folder structure. These files keep track of the configuration of your solution and the options you have selected. A VS.NET Solutions contains projects (and some other information) and projects contain the references, data connections, folders, and files that you need to create your application. You should never have to change either of them except through VS.NET.

The rest of your solution is in the folder that is also created when you start a new project. The files here contain forms, source files, and classes in the project. So let's look at this next.
Project Files

The highlighted file contains Visual Basic code about your solution. You can open it in either a text editor (like Notepad) or in Visual Studio itself to see what it is. And, if you build a solution and then look at the Properties for the resulting EXE or DLL, you'll see the same information.

The Form1.vb file contains plain ASCII VB code for the Form. And the other three files all contain XML configuration data for the solution. Opening all of these files in Notepad just to see what they contain can give you a much better feeling for what is actually happening when you create and build VB.NET solutions.

Before you build a project, none of the other folders actually have a file in them. To see one of the most critical and important new innovations in VS.NET ... the manifest ... you have to actually build a solution.

Technically, an assembly in .NET is the smallest unit of deployable code. The minimum is one or more modules compiled into MSIL (Microsoft Intermediate Language) code and the associated metadata that decribes the assembly. When you build a project in VS.NET, the output is usually an executable program (.EXE), a dynamic-link library (.DLL) file. Most of the time, an assembly will be a single EXE or DLL file.

Every .NET assembly contains a collection of data that describes how the elements in the assembly relate to each other. The assembly manifest contains this assembly metadata and it can either be part of the EXE or DLL that results from a build, or it can be in an XML file by itself. An assembly manifest contains all the metadata needed to specify the assembly's version requirements and security identity, and all metadata needed to define the scope of the assembly and resolve references to resources and classes. J. P. Hamilton, in his excellent book, Object Oriented Programming with Visual Basic .NET describes the manifest file this way: "A block of metadata that describes everything in the assembly and how it relates to everything else."
ILDASM Manifest

An example showing how to use a standalone manifest to achieve some interesting results is described in the About Visual Basic article, Manifestly Xtra Pretty Forms.

If you try looking at an EXE or DLL using Notepad, you'll see that it's not in a form you can make sense of without some extensive programming experience. To see how to examine an internal manifest like this, let's use an example from the solution that was built to support the About Visual Basic article, The Google Web Service API. The ILDASM.EXE program can be downloaded from Microsoft along with the .NET SDK and can be used to examine a solution manifest. This is probably a lot more than you needed to know right now. The point is not that this is a tool that a beginner can use. The point is to give you an overall view about where things actually are in your VB solution that is grounded in an actual view of real programs. In other words, to take the "mystery" out of them.