CBCR Ports Critical App to .NET
Careful prep work smoothed the way for the Central Bank of Costa Rica (CBCR) to migrate its mission-critical VB6 app to .NET.
by Lee Thé

August 2003 Issue

While it's important not to lose sight of the adage "If it ain't broke, don't fix it"—even in the fast-changing IT community—it's equally important to stay abreast of new technologies. Forward-thinking businesses often realize that by leveraging new technologies, they're able to not only provide customers and partners with new and improved services, but also increase their market share—even if that means upgrading an application that "ain't broke." This is true of the Central Bank of Costa Rica (CBCR) when it embarked on migrating its existing n-tier in-house app to .NET. It saw past the possible migration problems to the potential for greater application functionality. At the same time, it was able to leverage a substantial investment in an existing code base. The secret to CBCR's success was prepping the code base properly and bringing in outside expertise on .NET porting. It took work to migrate the application—but a lot less effort that it would have taken to completely rewrite it.

CBCR has a reputation for being technically aggressive, and it made an early decision to port its business-critical application—called SINPE (Sistema Interbancario de Negociación y Pagos Electrónicos or Interbank System for Negotiation and Electronic Payments)—to .NET. The application provides realtime settlements and clearance-house operations for inter-banking transactions throughout the country. It comprises a private network interconnecting Costa Rica's top 65 financial institutions with CBCR. Its 250-plus software assemblies span more than 1.3 million lines of (mainly Visual Basic 6) code in an n-tier architecture employing a SQL Server 2000 database (see Figure 1). The application supports around 100K transactions or half a billion dollars per day, with up to 500K transactions on especially active days.

As soon as CBCR's IT group learned about .NET they started thinking about migrating SINPE to the new technology so they could boost performance and developer productivity, and move to a Web services paradigm. However, the IT group was also under pressure to develop a number of new services at the time. They decided to delay the migration project, but began to prepare for doing the migration a few months later. They were assisted by ArtinSoft, which makes the porting tool incorporated in VS.NET,and offers migration consulting services.

ArtinSoft consultants worked with Harold Murillo and Mauricio Arroyo, project leaders for SINPE, and their team of 10 software engineers to evaluate the portability of SINPE's VB6 code base. This assessment turned up a number of areas where CBCR could improve the existing code to increase performance in the existing application and make the future migration easier.

For example, late binding in SINPE's code base made it possible to introduce errors into the code that are hard to debug. In VB6 you can define a variable without changing data types; your definition can simply say there's a variable "counter." It can take any data type later on. However, in .NET, data types are classes; you can't leave the data type hanging. So you need to add the data type to all the definitions/variables in your VB6 code—at least as a variant or an object. It's not a good programming practice anyway. And, in general, the changes you should make to VB6 code to prepare it for migration are changes you should make anyway to produce cleaner, easier-to-maintain code. It's often a case of removing programmer "shortcuts" that create more problems long-term than they solve in the short run.

Avoid Constant Confusion
For example, the CBCR IT team also had to root out using a constant's underlying value instead of naming the constant. This practice confuses Visual Studio .NET's migration tool program—it can't tell if a 1 was the number 1 or the value of True, especially if values and constants are mixed. So the team had to review the SINPE code to ensure that it used the words assigned to colors, mouse pointers, Booleans, and so on. Naming constants consistently makes development in .NET faster and safer. .NET does type checking, so it catches errors right away, whereas in VB6, you don't discover the errors until you're testing running code.

By the same token, the SINPE code base had to be checked for using date type. In VB6 you can do dating with a double number, storing a date in a variable of type double. .NET doesn't let you do that. The .NET Framework provides a date type that's a date, not a number. This means you don't need to program it.

The CBCR IT team also had to weed out other undesirable VB6 coding practices, such as using default properties, null propagation, and GOTO statements. And they had to make sure arrays were defined to start from zero. Assessing SINPE's code enabled the team to become familiar with differences between VB6 and .NET, which helped them prepare to port their skills along with the code.

As another example, visual data binding with Remote Data Objects (RDO) and Data Access Objects (DAO) aren't supported in .NET by and large. So the team made sure all the data access code in SINPE was migrated to ActiveX Data Objects (ADO) wherever possible, well before the port to .NET. This not only prepped the code for migration, but it also produced better performance immediately.

For database access, ArtinSoft recommends using controls that support ADO—especially ActiveX controls from ISVs. You can check each control manually while working in the VB6 Designer, using its drag and drop functionality. Simply drag each control into a VB6 Form, then drag in an ADO Data Control and verify that the controls let you select the ADO Data Control in the Data Source property.

Of course, if you have a lot of controls to check this can be time consuming. If so, you can create an app that passes through the code and moves everything that can be moved without changes. This isn't part of the VS.NET migration tool, but ArtinSoft wrote such a program for its consultants to use in migration projects. Just realize that some older controls don't let you use ADO, so not all of them can be replaced in VB6. Those will have to wait for the .NET migration.

Even the Clipboard's Different
CBCR's IT staff had to adapt SINPE, and themselves, to more than specific coding rules. .NET also changes the way you use seemingly familiar functionality such as the clipboard. The .NET clipboard object supports copying items in more file formats but you pay a price: Using the clipboard object requires three lines of code to do what takes one line in VB6. However, you can create a class for anything you want to grab using the clipboard, and that takes only one line to call. And the .NET clipboard model works in any .NET language.

This is one example of how .NET's object orientation might require more code on a onesy-twosy basis, but is quite efficient overall. The change from VB6 forms to .NET Winforms is another example. In VB6 the forms model was a property of VB, and you put lines and circles in it that aren't supported by .NET (in .NET, things are drawn using classes). Although the CBCR project migrated VB6 code to VB.NET, preparing VB6 code to migrate to Visual C# .NET requires the same steps, because both C# and VB.NET compile to the same intermediate code.

CBCR could have waited to make all these changes at the same time as migrating the code base to .NET. The VS.NET migration tool provides an upgrade report that shows what needs fixing. But ArtinSoft argues for solving the problems in VB6 first, because cleaning up the code provides benefits even if you don't migrate right away. Also, migration is hard enough; there's no need to complicate it further with additional tasks that can be done earlier.

By the time VS.NET was launched in February 2002, the CBCR code prep project was well underway. At that point, the IT group brought in an ArtinSoft consultant to help them prepare a detailed migration plan and provide .NET training for the developers. When migration began in May, CBCR planned to move the existing functionality to .NET—nothing more. This plan ensured unintentional changes weren't introduced to a business-critical system, and allowed the team to meet deadlines. The CBCR team decided improvements could come in the next phase.

Using the VS.NET migration tool, CBCR was able to migrate 90 percent of the code automatically; however, the remaining 10 percent required manual work and substantive changes. Murillo says, "We wanted the functional equivalence [to the original app], and that meant we needed to change code for everything to working .NET." In testing, the CBCR team found that some interrupts weren't working as expected. So they had to rewrite them—especially the XML interrupts—to use the new classes of the .NET Framework. They also had to move from ADO to ADO.NET, and change DCOM to use .NET remoting.

Houston, We Have Liftoff?
The migration had looked simpler at the start. Even under VB6, SINPE boasted a componentized architecture providing a set of services. Everyone on the team agreed they'd start the migration with just one SINPE service—a vertical slice of the system. But due to the componentization, each service uses many components shared by the other services, including many user controls. They had some trouble with one of the controls, but eventually reached a plateau where all the components were working. This enabled the team to start migrating the rest of the system earlier than they'd planned.

Then they ran into some integration problems when trying to use .NET's interoperability feature to provide backwards compatibility with ADO and DCOM. This imposed a big performance hit, so the team decided to use ADO.NET and Remoting, which let them minimize the amount of code invoked in the process. Remoting lets apps communicate on different computers by establishing separate comm channels between machines. However it didn't work right at first. This turned out to involve a bug in .NET Remoting, and the team wound up getting a patch from Microsoft that fixed it.

They also needed a patch for COM+ services. In VB6 the programmer explicitly provides object removal (garbage collection) for COM+ applications. However, .NET has a Garbage Collector that manages memory. And, in this case, garbage collection for the COM+ classes wasn't working properly. Apparently while a COM+ application was running, the system wasn't passing the proper references for memory allocation. As a consequence the server was consuming a huge amount of memory. The problem was detected after large datasets were loaded into server memory. When their references were removed, the Garbage Collector didn't free the entire amount of memory, so part of the memory was kept nonreferenced and unusable. The problem was fixed when Microsoft shipped CBCR a new version of the System.EnterpriseServices.dll (which implements COM+ in .NET). In general, ArtinSoft reports that a lot of COM+ or DCOM in an application complicates a porting project.

On the other hand, the change from DCOM to remoting let CBCR expand the classes to include data compression. And Murillo says remoting simplifies future changes: "Everyone uses the same remoting functionality so we don't have to worry about it. Change it just once and it works."

After the system was ported to a single server, then moved onto a Microsoft Application Center cluster, the team found load balancing didn't work well. Sometimes, when a client called for a service, it would start and return a result, but not finish the transaction completely. Fixing this required another patch from Microsoft for the .NET load-balancing feature.

Despite the bumps in the road along the way, Murillo and Arroyo's team updated the SINPE system to .NET in a record 40 developer months. They were able to resolve all the issues and put one .NET client in every institution using SINPE. The .NET version of the application went live in September 2002.

Web Services Are Coming
Since this time, Murillo and Arroyo have modified SINPE to exploit .NET's capabilities. To start with, they changed some VB6 user controls in the client for .NET controls that offer better style and integration with stateless components (see Figure 2). They've also found deploying new components with .NET is simpler, making developers more productive. Now they can have many versions of the DLLs without the Registry issues and binary compatibility errors they'd had to contend with in earlier versions of VB.

They're also looking forward to extending SINPE with the .NET Framework security tools to reinforce CBCR's security. And they expect to leverage .NET's true object-oriented programming (OOP) architecture. "We can have inheritance and polymorphism, which provide better code management," Murillo says. "The use of the same common language runtime (CLR) to run the app and .NET offers great performance improvements."

SINPE relies heavily on XML, which the team has leveraged to create XML-based Web services—one of the main reasons they decided to upgrade to .NET. At press time, they've already added several Web services, added inheritance to some components, and introduced .NET notification services that inform clients about their business transactions.

New Web services include a funds liquidation information system that connects Java systems to SINPE. This lets companies outside the bank liquidate funds, moving them from one reserve account to another. The Java systems record the value of the fund market that needs to be paid off with CBCR money. Another Web service acts as an agent for the settlement system, and a third Web service provides a messaging application. Whenever a financial institution gets a new funds transfer, this Web service delivers information about the new transaction to the main application.

Murillo and Arroyo have advice for others contemplating porting an application to .NET. In the migration process, they dealt with memory leaks during the changes from DCOM to remoting and from DAO to ADO.NET. They took advantage of Microsoft Product Support Services to resolve these issues and advise, "Before you migrate a big system, get support from organizations like ArtinSoft and Microsoft." Especially because as early adopters "we found nine or more problems in the .NET development framework and Microsoft fixed them." For example, the memory leaks came from a bug in .NET Framework 1.0's garbage collector.

Harold Murillo (left) and Manuel Vera Llontop (right) are project leaders for SINPE, the application the Central Bank of Costa Rica uses to manage electronic funds transfers and more between 65 financial institutions in Costa Rica. In SINPE's Operations Center, operations personnel monitor the availability and transaction flow of the SINPE network.

Do Unitary Testing
Murillo and Arroyo also recommend adding an extra month or two into a migration plan to deal with unanticipated problems. They like the migration methodology Microsoft proposes, including unitary testing for each component being migrated. They found a lot of errors in the migrated code, but using the recommended methodology let them catch those errors before integrating the components into the complete system. And because the deployment was incremental, they were able to correct the memory leak problem before it became a problem across the entire application.

You can also benefit from reviewing Microsoft's recommendations regarding necessary syntax changes and other coding practices that won't work in VB.NET. If your app is fully integrated with Windows OS, you'll use a lot of API functions, as SINPE does. But the Windows 2000 API isn't managed code, so in the CBCR IT group's case, they had to change it to the equivalent classes in the .NET Framework. Murillo says, "The APIs can cause real havoc if you don't manage them carefully [while using the migration tool]".

For example, the type Any can represent any type in VB, but it doesn't exist in VB.NET. And although a lot of the API libraries have equivalents in the CLR classes, you need to know the CLR classes to change them to their equivalents should you find problems in the migration.

Finally, Murillo and Arroyo stress the importance of training. CBCR's software engineers had had OOP training in their university education—not in a .NET language, but Murillo says this isn't important. For .NET migration specifically they all received a week's training from ArtinSoft consultants that focused on what needed to be upgraded manually. Murillo and Arroyo also went to Puerto Rico for a two-week course from Microsoft in the .NET Framework (one week on the Framework basics, one week on C#). The team also did peer reviews regularly as they got up to speed. Murillo summarizes the training process: "Once you know the base classes of .NET and OOP principles, you have a lot of knowledge to go and enjoy good productivity." He adds, "What .NET language you learn doesn't matter so much as the classes of the framework. And knowledge of OO is a must if you want to get the most from the technology."

Despite the bumps in the road, Murillo and Arroyo are pleased with the migration project. It took a month longer than they'd anticipated, but it still beat rewriting 1.3M lines of code. Best of all, the migration has enabled them to boost performance and start providing Web services and other advanced functionality. The .NET migration also prepared them for their next migration project: Windows 2003 Server. This move will let them take advantage of this server's shared framework with .NET and capability to run managed code natively.

About the Author
Former Visual Studio Magazine executive editor Lee Thé writes occasional technology pieces to pay for scuba diving trips for his wife and himself while he works on a science fiction trilogy. Reach him at .