In this column, I want to touch on a couple of topics that I've discussed in the past. First, I want to update the "Refactoring: C#'s Cool New Feature" column (http://www.windowsitpro.com/articles/articleid/44259/44259.html), which ran last October. Refactoring is a new feature in Visual Studio 2005. When I wrote that column, you could use refactoring with C# but not Visual Basic .NET. Well, several weeks ago, Microsoft's Visual Basic .NET product team announced support for refactoring as part of Visual Studio 2005.
To achieve this support, the development team decided to integrate a third-party product--Developer Express's Refactor!--rather than trying to build in the refactoring capability. This plug-in is available for Visual Studio 2005 beta 2. You can download a free copy at http://msdn.microsoft.com/vbasic/downloads/2005/tools/refactor/default.aspx. For a quick demonstration on how to refactor Visual Basic .NET code, check out the following link:
With Visual Studio 2005, I'm hoping that Microsoft has learned a valuable lesson: Keep the primary .NET languages equal. Having features such as refactoring in only one .NET language can cause uproars. When the Windows .NET Framework was introduced, one of the biggest cheers was for the fact that Visual Basic .NET would be a first-class language like every other .NET language. The key part of that statement is "like every other .NET language." I realize that this statement could be interpreted with respect to the runtime environment the reality is that the developer community expects the same features across all the .NET language development tools. Although Microsoft might not agree, I'm hopeful that with the next release of Visual Studio, both C# and Visual Basic .NET will essentially get a matching list of features.
Integrating the Refactor! plug-in is a step in the right direction. However, the free Refactor! is a community version that doesn't have all the features of the professional version. The professional version currently has a $99 price tag, so hopefully the community version will have all the features you need. If it doesn't, the sooner you start telling Microsoft about those missing features, the better.
This brings me to another topic I want to touch on. There's a trend that I think has lost its focus (if it even had one): petitioning. In my recent "Is Chicken Little a VB 6.0 Developer?" column (http://www.windowsitpro.com/windows/article/articleid/45920/45920.html), I mentioned that some developers were petitioning Microsoft to extend the mainstream support for Visual Basic 6.0 (VB 6.0). From what I can tell, Microsoft has received petitions on everything from consumer products (e.g., Xbox) to unrefined standards on developer technology (e.g., XQuery). So, I want to take a moment to explain why petitioning is, in my opinion, not the best way to get a constructive response from Microsoft.
First, note that Microsoft didn't add support for refactoring in Visual Basic .NET because of a petition (there was none). Microsoft responded because developers immediately contacted the company when they learned that this support was missing from Visual Studio 2005.
Second, Microsoft has set up many mechanisms for providing feedback. If you're a Microsoft Most Valuable Professional (MVP), you can go through your assigned MVP contact, participate in private discussions with Microsoft employees, or try to contact others within the Microsoft community. If you aren't an MVP, you have several options, including talking with a Developer Evangelist at Microsoft or a Developer Community Champion (DCC). To find the DCC in your area, go to http://www.microsoft.com/events/dcc/default.mspx. You can also post comments on Microsoft forums (http://forums.microsoft.com/msdn) or newsgroups (http://msdn.microsoft.com/netframework/community/newsgroups/default.aspx). You also have the option of participating in user groups. In these groups, you can share your experiences, complaints, and ideas with others in the Microsoft community and build consensus.
No matter which mechanism you use, you have to realize that Microsoft won't follow every suggestion you make or fix every bug you report. Heck, I've sent in bug reports and Microsoft responded by letting me know that the problem wasn't enough of a priority to fix. (I then worked around those bugs and, in many cases, found a better way of doing something as a result.) The point is that Microsoft provides many avenues for feedback, most of which are open to everyone. Whether you believe it or not, Microsoft is listening. But Microsoft would rather get feedback directly and not receive a generic, easily manipulated list of names.
Finally, I want to end this column by introducing you to my next big topic--Visual Studio 2005 Team System--which, by the way, already has at least one petition associated with it. Team System is essentially a new product family designed to provide code screening, testing, and architectural analysis. Microsoft is essentially bringing together several different products under this heading, then putting these tools into three task- oriented packages.
There's a Team System package that helps architects design solutions using components and define the deployment of those components. For software developers, there's a Team System package that contains tools designed to improve the quality of source code. Finally, there's a Team System package for testing applications. Team System is a large topic, so I'll spend the next few columns discussing everything from the new Team Foundation Server to changes in Microsoft Developer Network (MSDN) subscriptions. For now, you can start to learn more about Team System at the following URL: