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!

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.

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."

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.