Customizing the My Namespace |
 |
By Jack Vaughan
22 Nov 2005 | SearchVB.com |
|
|
The changes to VB for 2005 are designed to simplify common programming tasks for VB developers. In recent years, the lack of such hooks was an encumbrance to many developers, who, Microsoft surveys disclosed, found the original .NET Framework off-putting.
.NET was hard for some VB developers to penetrate, admitted Joe Binder, program manager, Visual Basic Team, Microsoft. Why? "Because it is structured as technology more than as tasks," he answered.
"What they needed was in the .NET Framework. But they couldn't find it easily," said Binder. Still, like any software enthusiasts, the VB crew does have interest in what goes on in the runtime.
In the new Visual Basic 2005, My Namespace is the clearest example of pre-packaged solutions to common developer tasks. It provides an application framework to expose methods and properties.
As much as they may welcome pre-packaging, noted Binder, VB developers want an idea of what goes on in the box, and he has of late set out to evangelize use of VB2005, and to show developers what is 'under the hood' and how they can customize My Namespace to meet unique needs. My Namespace extensibility points include the application model and events; computer device support and hardware events; user authorizations and authentications; and more.
"VB developers like what [VB2005, supporting .NET 2.0] does, and they were glad they didn't have to write so much code, but before they started sprinkling it in applications," said Binding, "they wanted to know how it works."
Special scenarios
Educated guesses about common deployment scenarios are key in VB2005. "Everything in "My" works out of the box," said Binder. "Nothing we put in "My" should require any configuration to get it working."
"You call a function and get the results desired," he continued, "but the desired results differ according to the scenario."
He points to log messages, user settings, and hardware configurations, as areas where you may want to alter the 'out of the box' function. Working with them also provides you with a view into the workings of the My Namespace.
My.Application.Log provides a simple entry point and default configuration, he noted. When developing, you may be writing log messages, and, out of the box, you can type 'My log.' The tool's embedded IntelliSense can take over, and the results can be useful in most scenarios. But in applications that may live in a broader enterprise scenarios, you may need extensions that link to existing services.
The My Namespace user is an encapsulation of a Windows user (whoever is logged on), says Binder. It encapsulates Window users by default. But you may need, in heterogeneous environments that include UNIX, for example, to create a program that can grab something out of an LDAP directory. This is supported by extensions to My Namespace. In a presentation at PDC 2005, Binder described how to create different configurations.
For more on this topic:
Simplify Common Tasks by Customizing the My Namespace - MSDN
My.Internals: Examining the Visual Basic My Feature - MSDN
My Namespace – MSDN
Visual Basic: Under the Hood on Extending the 'My' Namespace - Microsoft site
PDC Presentation: Under the Hood on Extending the 'My' Namespace - MSDN
|
|
|
|
