Assemblies

You combine assemblies to form .NET applications, and although we won't deal with them directly very often, we need to get the terminology down. An assembly holds the Intermediate Language modules for your application. When you create an application in VB .NET and run it, VB .NET creates one or more assemblies, which are run by the CLR. That is, assemblies are how your applications interact with the .NET framework instead of the EXE or DLL files of VB6.

Here's what's in a .NET assembly: first is the manifest-similar to a table of contents-giving the name and version of the assembly. The manifest also lists the other assemblies needed to support this one, and explains how to handle security issues. The actual meat of the assembly is made up of modules, which are internal files of IL code, ready to run. That's how VB .NET stores the IL it creates, in modules inside assemblies. Each module, in turn, contains types-the classes and interfaces that your code has defined, and that the assembly has to know about to let the various modules interact with each other.

We won't deal with assemblies directly much, because all that's needed happens behind the scenes with the CLR and the .NET framework-but we do have to know the terminology, because you'll hear these terms frequently when using VB .NET. For example, to set the version of a Visual Basic project, you edit its AssemblyInfo.vb file in the Visual Basic IDE.

Solutions and Projects

When you created applications in Visual Basic 6.0, you created projects. Each project held the code and data for an application, ActiveX control, or whatever else you wanted to build. If you wanted to combine projects together, you created a project group. In VB .NET, however, project groups have become far more integral to the development process, and now they're called solutions.

By default, when you create a new project in VB .NET, Visual Basic will create a new solution first, and then add a project to that solution. For example, look at the Solution Explorer window, at right in Figure 1.8, above the Properties window. In that case, we've created our Visual Basic project called WinHello, and you can see that project in the Solutions Explorer-but note that Visual Basic has also placed that project inside a solution with the same name, WinHello. If we were to add new projects to the current solution (which you can do with the New Project dialog box), those new projects would appear in the Solution Explorer as part of the current solution. This is a change from VB6, where you created projects by default, not project groups. It's also worth noting that Microsoft calls the files in each project, such as the files for a form, items. So the terminology here is that solutions contain projects, and these in turn contain items.

File Extensions Used in VB .NET

When you save a solution, it's given the file extension .sln (such as WinHello.sln), and all the projects in the solution are saved with the extension .vbproj. Here's a list of the types of file extensions you'll see in files in VB .NET, and the kinds of files they correspond to; the most popular file extension is .vb. This is a useful list, because if VB .NET has added files to your solution that you haven't expected, you often can figure them out by their file extension:

• .vb-Can be a basic Windows form, a code file, a module file for storing functions, a user control, a data form, a custom control, an inherited form, a Web custom control, an inherited user control, a Windows service, a custom setup file, an image file for creating a custom icon, or an AssemblyInfo file (used to store assembly information such as versioning and assembly name).

• .xsd-An XML schema provided to create typed datasets.

• .xml-An XML document file.

• .htm-An HTML document.

• .txt-A text file.

• .xslt-An XSLT stylesheet file, used to transform XML documents and XML schemas.

• .css-A cascading stylesheet file.

• .rpt-A Crystal Report.

• .bmp-A bitmap file.

• .js-A JScript file (Microsoft's version of JavaScript).

• .vbs-A VBScript file.

• .wsf-A Windows scripting file.

• .aspx-A Web form.

• .asp-An active server page.

• .asmx-A Web service class.

• .vsdisco-A dynamic discovery project; .vsdisco provides a means to enumerate all Web Services and all schemas in a Web project.

• .web-A Web configuration file, .web configures Web settings for a Web project.

• .asax-A global application class, used to handle global ASP.NET application-level events.

• .resx-A resource file used to store resource information.

Debug and Release Versions

Note that so far we've started our programs from the Debug menu's Start item. This causes Visual Basic to launch the program while staying in the background; if there's a problem, Visual Basic will reappear to let you debug the program's code. That's useful for development, of course, but when your program is ready to go and to be used by others, you hardly want them to have to launch your program from Visual Basic.

That's where the difference between debug and release versions of your program comes in. In a debug version of your program, Visual Basic stores a great deal of data needed to interface with the debugger in your program when it runs, and this not only makes the corresponding assembly larger, but also slower. In the release version of your program, the program doesn't have all that added data, and can run as a stand-alone program, without needing to be launched from Visual Basic (although it still needs the .NET Framework, of course).

When you create a new solution, Visual Basic creates it in debug mode, meaning that you launch it from the Debug menu as we've been doing. However, you can switch to release mode in several ways (like many things in VB .NET, there's more than one way to do it):

• Select the Configuration Manager item in the Build menu, then select Release in the Active Solution Configuration list box and click OK.

• Select the solution you want to set the mode for by clicking it in the Solution Explorer, and find its Active Config property in the properties window. When you click the right-hand column in the properties window next to this property, a drop-down list box will appear; select Release in that list box.

• Select the solution you want to set the mode for by clicking it in the Solution Explorer, and select the Properties item in the Project menu, opening the solution's property pages. Select the Configuration Properties folder in the box at left, and the Configuration item in that folder. Then select Release from the drop-down list box in the configuration column of the table that appears, and click OK.

• Probably the easiest way to set the solution mode to release or debug is simply to use the drop-down list box that appears in the Visual Basic .NET standard toolbar, at the top of the IDE. When you create a new solution or project, this list box displays the word Debug, and all you need to do to switch to release mode is to select Release instead.

When you've set the mode for a solution to Release, you build it using the Build menu's Build item (the Build menu item causes Visual Basic to compile only items it thinks have been newly changed; to force it to compile all items in the solution, choose the Rebuild All item instead of Build). This builds the solution in a way that others can use it, and you can deploy your program this way (usually with the help of a deployment project that you build in Visual Basic, as we'll do later in the book).

Now we have the background we need on VB .NET solutions and projects as we head into the following chapters, where we'll assume this knowledge and put it to work. We'll also take for granted that you know your way around Visual Basic .NET itself, so in this introductory chapter, I'll also take a look at the Visual Basic Integrated Development Environment-the VB IDE.