.NET Now Positioned to Replace COM
by Bill Sheldon
Several years ago when Microsoft introduced its .NET technology, there were many discussions about whether this was a sign of the end of COM. After all, .NET isn't based on COM but instead on a runtime environment and byte code. At the time, most everyone, including Microsoft officials, concluded that .NET isn't the end for COM. But the world of technology keeps changing. As we prepare to take another step forward, so does the likelihood that COM is, in fact, reaching its end of life for most business applications. Don't get me wrong--I'm not saying that Microsoft's product support for COM or COM's use as a standard (and one used by key Microsoft products) is coming to an end. However, we're fast approaching a point at which most business applications won't be implemented with COM. This distinction is important. Simply put, Microsoft isn't ending its support for COM but rather the market is bringing about the effective end of COM. In this case, it comes down to the demand for applications that have more memory and faster processors.
If you've been developing applications for more than a couple years, you might recall the last big jump: the migration from Windows 3.1 to Windows 95, which is better known in the technical world as the transition from 16-bit to 32-bit OSs. I don't know of a single developer who found this transition to be a pleasant experience. Perhaps it was profitable for some consultants, but nevertheless it wasn't pleasant, even for them. We're now approaching the next big jump: the migration from 32-bit to 64- bit OSs. When people hear "64-bit," they often think of servers. After all, it was the overburdened database servers of companies' Web-based applications that first showed the strain on 32-bit OSs. However, as we continue to move forward, we're seeing that high-end users (e.g., developers who develop for 64-bit platforms, gamers who want more memory to make games run faster) are eyeing the move to 64 bits. Although 64 bits might not be a priority on the average Web server yet, as more servers are used to host multiple sites, even Web servers will eventually look for 64-bit processing. The result is a challenge for COM in that COM is a binary protocol.
COM- based applications base their communications on data contained and formatted in their compiled state. Thus, when you compile your code to run on a 32-bit OS, the code implements the protocol based on a 32-bit environment. The problem is that an object that worked well in a 32-bit environment might not work as well in a 64-bit world. Microsoft and many hardware manufacturers are making their 64-bit products compatible with existing 32-bit applications. However, compatibility is a far cry from having a platform that runs 32-bit and 64-bit applications equally well. The Windows .NET Framework is such a platform. More important, Microsoft made the .NET Framework available several years ago, which means that the transition from 32-bit to 64-bit OSs will be far less painful than the transition from 16-bit to 32-bit OSs. Although there will still be companies that use COM-based interfaces to build applications, these companies will be the exception rather than the rule in the not-too-distant future. Most companies will use .NET 2.0 and the upcoming .NET 3.0 to build code so that their applications can be effortlessly ported to the new 64-bit world.
Enhance SQL Reporting and Increase Server Performance: Revolutionize the Way You Work with Data Increase your SQL production server's performance by offloading Reporting Services to a secondary server. Gain additional insight into your important business data quickly and effectively.
Confused by SQL Server 2005's Many Editions?
Help Has Arrived Although differences in SQL Server 2000 editions can be confusing, implementing a production database boils down to three choices: the Enterprise Edition, the Standard Edition, and Microsoft SQL Server Desktop Engine (MSDE). With SQL Server 2005, the implementation choices have grown substantially more complicated. More so than in any previous release, the different SQL Server 2005 editions have a clear delineation of features that address the needs of distinct customers. However, new customers need to be careful to get the right version. Learn about the available editions and how to choose the one that will best meet your needs in the article "Making Sense of the Editions" in the September issue of SQL Server Magazine.
Glad You Asked: Two Sides of the Same Coin
by Bill Sheldon
Q: Earlier this year, you wrote the article "Source Control Basics: Shelving, Branching, and Merging" in which you made it clear that you weren't a fan of merging changes in source control. I agree. I recently installed Team Foundation Server (TFS) and set it up to be our corporate source-control library. Soon thereafter we found that multiple developers could, by default, access the same source file at the same time. Then at check-in, they were suddenly presented with a requirement to merge these changes. In some cases, the merge was relatively painless. In other cases, the merge was painful and has introduced errors. How do we disable this default?
A: I received several email messages about the "Source Control Basics: Shelving, Branching, and Merging" article. Another reader had wrote and said, "In your article 'Source Control Basics: Shelving, Branching, and Merging,' you claim that merging is bad. I completely disagree. My organization couldn't function effectively if multiple people weren't working on the same source files." As you can tell, these two readers' merging experiences and opinions are diametrically opposed. The good news for the first reader is that you can avoid the situation entirely. When you install TFS, the default is to allow for shared check-out of code files. This means that if developer Andrew has started editing a file on his local machine, then developer Betty also starts independently editing the same file on her machine, TFS, by default, lets them.
Andrew and Betty might be completely unaware that someone else is editing the file because TFS doesn't tell them when a file is already checked out. However, one of the developers will become aware of the situation during check-in. Suppose that Betty finishes editing the file first. She checks in her code with no problem. But when Andrew goes to check in his code, TFS will stop the check-in process and ask him to merge the changes. At this point, he'll generally have a couple options related to merging.
The first option is to allow TFS to automatically merge the changes. When this option appears, it means that the developers who had simultaneously checked out the source file had changed different lines of code. From TFS's standpoint, this type of merging is easy, but selecting this option isn't risk free. For example, Andrew and Betty might have both added the same line of code, but Andrew put his line of code at the top of a function whereas Betty put her line of code at the bottom of the function. Because they put the same line of code at different locations, TFS will include two copies of that line of code, which is an error waiting to happen. The second option is to use the Merge Tool to manually merge changes.
The bad news is that one developer (Andrew in this case) gets stuck with extra work. The good news is that the Merge Tool is fairly powerful. The tool highlights those changes it feels incapable of merging so that the person merging the code can select the change he or she wants to apply. That person can actually edit the resulting choice. In theory, being able to manually merge changes sounds great. In the real world, however, I've found that manually merging changes can result in new errors and lost changes. In one instance, a client started experiencing problems after a mere 40 hours of development time. The problems started within the first day or two, but reached a head on the day of software cutoff. We had to spend so much time merging one developer's changes that the cost of making those changes to the application doubled.
Some developers also claimed their changes were lost because of merging. The net result was chaos at a time when we were trying to manage what should have been a simple software cutoff scenario. Because of this experience and similar experiences with other clients, our policy as of last week is to always turn off shared check-out. Here's how to disable shared check-out: Within Team Explorer (aka Visual Studio 2005) go to the Team menu. (You'll have this menu only if you've installed Team Explorer and are connected to a TFS server.) Select Team Foundation Server Settings, then the Source Control File Types option. A dialog box listing a variety of file types will appear. This dialog box has three columns, the first two of which contain the name of the file type (e.g., VB Files) and file extensions associated with that type of file (e.g., .vb). In the third column, which is labeled File Merging, you can specify whether you want to allow shared check-outs for that file type. To change the value in this column, click the Edit button. In the dialog box that appears, clear the "Enable file merging and multiple check out" check box. That's it. You've now prevented multiple check-outs for files of that type. Even if a developer specifically requests a shared check-out, TFS won't let it happen.
