As mentioned in Part I, you might want to create class libraries for a lot of reasons and the techniques shown here can be used for any class libraries. Visual inheritance is one specialized way to use them and that's the only thing we show you here. But stay tuned! More articles are coming!

There is a way around the problem in VB.NET Standard and it's actually not too difficult. Besides, you'll learn a few tricks you can use in the future. The solution is to create the class library using the VB .NET command line compiler, VBC.EXE.

About Visual Basic contributor Elijah Taylor suggests a different way to get around this problem in this later article. You might want to try the technique described here just to learn how to use the compiler tools.

VBC (Visual Basic Compiler) is distributed free with the .NET SDK. It should already be installed on your computer. You can easily check by simply opening a Command Prompt window (otherwise known as a DOS window) and entering the command VBC. If it's installed correctly, you should get a fairly long list of the parameters that can be used with it.

(If you don't have the .NET SDK, you can download it for free, or get it on CD ROM at a nominal cost. Microsoft provides the details HERE.) It's also possible that VBC.EXE is not in the Path environment variable for your computer. You can enter the Path command at a DOS prompt to see what it is. Correcting this is fairly simple - see the illustration - but now we're getting into DOS commands which is a different (but fascinating!) subject all by itself.

VBC can do anything that the Visual Studio GUI can do. (And, as we're going to see, a few things that the version of Visual Studio shipped with VB.NET Standard can't do.) But the problem is that the long list of parameters for VBC is not particularly well documented. In fact, the main type of information you can find is simply the same list of the parameters - and a brief description - that you get by default when you enter just the VBC command. Documenting the entire list is well beyond this article, but we're going to look at a couple that are necessary for generating class libraries.

To get started, make sure that you have created the 'ancestor' form, that is, the base for inheritance. You do this by simply creating the form in Visual Studio. Next, open a command prompt window and use DOS commands to change the current directory to the one containing your ancestor form. This is the VB.NET program directory (the one that has the .VB source for your form).

Now ... just as a way of learning how the VBC compiler works ... let's see what happens when you try compiling your form without any parameters. Since my form was named AboutVB, I entered:

VBC AboutVB.vb

This generates several pages of errors, including:

vbc : error BC30420: 'Sub Main' was not found in 'AboutVB'.

And a whole list of errors similar to:

C:\AboutVB\AboutVB.vb(2) : error BC30002: Type 'System.Windows.Forms.Form' is not defined.

There are two things happening here. First, the default mode of VBC assumes that you're creating a "console application" and that requires a "Sub Main" entry point instead of the form that is used as the entry point in a Windows application. The second is that VBC detects that the code requires references to a bunch of objects that it can't find such as 'System.Windows.Forms.Form'.

To solve the first problem, we add a parameter to tell VBC that we want to generate a library assembly instead of a console application. There are four types of output "targets" that can be generated.

/target:exe Create a console application (default).
/target:winexe Create a Windows application.
/target:library Create a library assembly.
/target:module Create a module that can be added to an assembly.

We're interested in creating a class library, so let's use the library target. When we use this parameter, we also have to add an out parameter to name our output class library DLL. Now, our command looks like this:

VBC /target:library /out:AboutVBClass AboutVB.vb

If you want to try this new VBC command again, the first error disappears. Now that the compiler knows we're not trying to generate an exe, it stops looking for a Sub Main.

The rest of the errors (in this case) are generated because the compiler can't find the objects in the VB statements. Where are all these objects? If you go back into the Visual Studio and open the inherited (or "ancestor") form, the Visual Studio GUI tells you exactly where to look. Check the Solution Explorer in Visual Studio and you will see:

There is a list of all the references you'll need right there. All you have to do is repeat these names - slightly modified - in the VBC command line. You do this by using the reference parameter:

/reference: Reference metadata from the specified assembly.

Our VBC command now looks like this:

VBC /target:library /out:AboutVBClass /reference:System.dll,System.Data.dll,
System.Drawing.dll,System.Windows.Forms.dll,
System.XML.dll AboutVB.vb

Note: This is all one command with no spaces after the comma's. It's formatted this way to make it display correctly on the web page.

The VBC compiler must work on the principal that "no news is good news" because when you have it correct, nothing except the compiler copyright notice is displayed after you enter the command. But a check of the application folder will reveal that a new file has been added:

AboutVBClass.dll

We're one step away from being finished now.

Using the Visual Studio window again, start a completely new project in a new folder and let's try to add the inherited form AboutVB. Since it's in a different folder, this should give you the same error message, "There are no built assemblies ... " that you might have seen when you tried to do this in Part I of this article. Solve this problem by changing to the folder where the AboutVBClass.dll can be found using the Browse button in the dialog. After you add the new inherited form, note that Visual Studio automatically adds a Reference in Solution Explorer and also adds a second form, the inherited form, to the project.

You can add more controls to this inherited form now if you choose to. To demonstrate the application, a new button was added to the form and the form was displayed using the Show method in the first form:

Private Sub Button1_Click( _
    ByVal sender As System.Object, _
    ByVal e As System.EventArgs) _
    Handles Button1.Click
    Dim myInheritedForm As _
        New DescendantForm
    myInheritedForm.Show()
End Sub

The results speak for themselves:

The new AboutVBClass.dll can be added to any form you like now and the properties and components that are "hard coded" in it won't change. Congratulations! You just saved $600 and learned a lot too!