Section 2.9. Extend the My Namespace | Visual Basic 2005: A Developers Notebook

2.9. Extend the My Namespace

The My objects aren't defined in a single place. Some come from classes defined in the Microsoft.VisualBasic.MyServices namespace, while others are generated dynamically as you add forms, web services, configuration settings, and embedded resources to your project. However, as a developer you can participate in the My namespace and extend it with your own ingredients (e.g., useful calculations and tasks that are specific to your application).

Note: Do you use the My objects so much you'd like to customize them yourself? VB 2005 lets you plug in your own classes.

2.9.1. How do I do that?

To plug a new class into the My object hierarchy, simply use a Namespace block with the name My. For example, you could add this code to create a new BusinessFunctions class that contains a company-specific function for generating custom identifiers (by joining the customer name to a new GUID):

Namespace My          Public Class BusinessFunctions         Public Shared Function GenerateNewCustomerID( _           ByVal name As String) As String             Return name & "_" & Guid.NewGuid.ToString( )         End Function     End Class      End Namespace

Once you've created the BusinessFunctions object in the right place, you can make use of it in your application just like any other My object. For example, to display a new customer ID:

Console.WriteLine(My.BusinessFunctions.GenerateNewCustomerID("matthew"))

Note that the My classes you add need to use shared methods and properties. That's because the My object won't be instantiated automatically. As a result, if you use ordinary instance members, you'll need to create the My object on your own, and you won't be able to manipulate it with the same syntax. Another solution is to create a module in the My namespace, because all the methods and properties in a module are always shared.

You can also extend some of the existing My objects thanks to partial classes. For example, using this feature you could add new information to the My.Computer object or new routines to the My.Application object. In this case, the approach is slightly different. My.Computer exposes an instance of the MyComputer object. My.Application exposes an instance of the MyApplication object. Thus, to add to either of these classes, you need to create a partial class with the appropriate name, and add the instance members you need. You should also declare this class with the accessibility keyword Friend in order to match the existing class.

Note: Shared members are members that are always available through the class name, even if you haven't created an object. If you use shared variables, there will be one copy of that variable, which is global to your whole application.

Here's an example you can use to extend My.Application with a method that checks for update versions:

Namespace My          Partial Friend Class MyApplication         Public Function IsNewVersionAvailable( ) As Boolean             ' Usually, you would read the latest available version number             ' from a web service or some other resource.             ' Here, it's hardcoded.             Dim LatestVersion As New Version(1, 2, 1, 1)             Return Application.Info.Version.CompareTo(LatestVersion)         End Function     End Class      End Namespace

And now you can use this method:

If My.Application.IsNewVersionAvailable( )     Console.WriteLine("A newer version is available.") Else     Console.WriteLine("This is the latest version.") End If

2.9.2. What about...

...using your My extensions in multiple applications? There's no reason you can't treat My classes in the same way that you treat any other useful class that you want to reuse in multiple applications. In other words, you can create a class library project, add some My extensions, and compile it to a DLL. You can then reference that DLL in other applications.

Of course, despite what Microsoft enthusiasts may tell you, extending the My namespace in that way has two potentially dangerous drawbacks:

It becomes more awkward to share your component with other languages. For example, C# does not provide a My feature. Although you could still use a custom My object in a C# application, it wouldn't plug in as neatly.
When you use the My namespace, you circumvent one of the great benefits of namespacesavoiding naming conflicts. For example, consider two companies who create components for logging. If you use the recommended .NET namespace standard (CompanyName.ApplicationName.ClassName), there's little chance these two components will have the same fully qualified names. One might be Acme.SuperLogger.Logger while the other is ComponentTech.LogMagic.Logger. However, if they both extend a My object, it's quite possible that they would both use the same name (like My.Application.Logger). As a result, you wouldn't be able to use both of them in the same application.