There's a new namespace that's coming with Visual Studio 2005. But before I discuss this namespace, I want to tell you about some of the feedback and events that have occurred since my last commentary "Is Chicken Little a VB 6.0 Developer?" (http://www.windowsitpro.com/article/articleid/45920/45920.html).
In "Is Chicken Little a VB 6.0 Developer?" I discussed how some developers are panicking because Visual Basic 6.0 (VB 6.0) is aging. Microsoft heard about the panicking developers' concerns. Jay Roxe, Microsoft's Program Manager for Visual Basic, took action and created VBRun: The Visual Basic 6.0 Resource Center (http://msdn.microsoft.com/vbrun) to address developers' concerns. This Web site is devoted to helping VB 6.0 developers migrate both their skills and their applications to VB.NET.
Now back to Visual Studio 2005's new namespace. When I was working on an article for SQL Server Magazine, a fellow author claimed that transactions--in particular, distributed transactions--aren't something that most developers are interested in. I happen to disagree with him because I feel that most developers are very interested in transactions. However, I also feel that up until now distributed transactions have been difficult and in most cases not worth the effort.
Let me defend that position. How many of you are using COM+ to create distributed transactions? More important, how many of you are taking .NET assemblies and placing them under COM+? I don't see many hands when I ask these questions during a presentation. The reason is that integrating COM+ with .NET is difficult.
When developing with .NET, the only feature of COM+ you ever need is to manage a transaction that spans multiple data sources. As a result, most developers have reached the same conclusion: It's easier to create an architecture that lets you use a single transaction database than to implement distributed transactions. At the extreme, I've seen applications that commit transactions to one database from which another process then transfers the committed data to all the other databases, where the data permanently resides.
Let's face it, most developers quickly learn that there are so many challenges in working with COM+ from .NET that they look for ways to avoid it. After all, trying to work out all the deployment, installation, and permission issues associated with a COM+ transaction chews up a lot of resources. Up until Visual Studio 2005, writing a custom and often unsafe distributed transaction manager was the only option. However, with Visual Studio 2005, Microsoft is introducing a new namespace: System.Transactions.
The System.Transactions namespace doesn't directly replace what I'll refer to as the old Enterprise Services namespace. Instead, the System.Transactions namespace is similar to the System.Data.Common namespace in that it provides a more generic namespace for defining transactions. Unlike the Enterprise Services namespace, which was designed with the expectation that developers would create custom classes inheriting attributes from that namespace, the System.Transactions namespace is oriented toward providing classes that encapsulate the logic of a transaction. The result is that instead of defining a class and exposing it to COM+, you can add a reference to the System.Transactions namespace and create an object such as CommittableTransaction. The CommittableTransaction object encapsulates the logic to provide a distributed transaction. You don't need to be concerned with details about interfacing the distributed transaction coordinator; .NET has encapsulated those capabilities. More information about this namespace is available on the Microsoft Developer Network (MSDN) at http://msdn2.microsoft.com/library/system.transactions.aspx. Note that the classes in the System.Transactions namespace have changed significantly since beta 1.
The System.Transactions.ComittableTransaction class is only the tip of the iceberg. The System.Transactions namespace goes beyond this one class, and that's part of what I explore in an upcoming article in SQL Server Magazine. That article, which will appear in the June issue, will focus on several of the features that bind Visual Studio 2005 and SQL Server 2005. As Microsoft moves toward the joint release of Visual Studio 2005 and SQL Server 2005, SQL Server Magazine (the primary sponsor of this newsletter) is making an effort to better cover how developers can leverage the power of SQL Server 2005 in their applications. So I hope you'll take a few moments to check out SQL Server Magazine and read that article, which will focus on Visual Studio 2005 beta 2.
