ASP .NET Programmer Online Bottleneck Resource: Performance of .NET applications that call native code components promises to be one of the most challenging issues faced by developers. In many cases, it is difficult to tell if a bottleneck resource performance problem is in the managed code or the native code. In some cases, it may even be in the interaction between the two, making it still more difficult to determine the exact cause of the bottleneck effect.

---

Performance of .NET applications that call native code components promises to be one of the most challenging issues faced by developers. In many cases, it is difficult to tell if a performance bottleneck is in the managed code or the native code. In some cases, it may even be in the interaction between the two, making it still more difficult to determine the exact cause of slow code.

This white paper looks at two mechanisms that can potentially be used to cal COM objects from .NET code, their advantages and disadvantages, and how Compuware’s BoundsChecker provides new and essential features for developers calling native code components from .NET applications.

Calling native code from Microsoft .NET applications brings error detection challenges

Microsoft is encouraging Windows developers to start building new applications in Visual Studio .NET, yet you’re not going to throw away perfectly good code in your existing applications to do so. In some cases, you may be able to migrate your code to one or more .NET languages. In many cases, however, what you’re going to do is take the existing logic, often encapsulated in COM/COM+ components, and use it “as is� with the new Microsoft .NET code.

While Microsoft makes this possible, it also makes it possible to introduce an entirely new class of potential errors into your applications. Finding and fixing these errors is crucial, because errors in your native code can have a subtle yet significant impact on the managed code in your application. These errors are entirely unlike those you are likely to encounter working within the .NET Framework, and are largely undetectable with the new and emerging .NET development tools from Microsoft and others.

There are two mechanisms that you can potentially use to call COM objects from .NET code. Both of these mechanisms work in the same way, so which you use depends on what .NET language you’re working in, and whether or not the COM component is being shared among multiple applications.

To download pdf version of this paper, click on link below