This page describes how gmStudio creates and uses runtime-callable Interop assemblies for your .NET migration. This information is only relevant to migrations that are using the "External=Interop" handling strategy.
Living with Interop
Despite its simple premise, COM Interop is one of the more difficult areas of .NET development. If your migration team is planning to use Interop, we recommend that you fully understand the implications in terms of debugging, builds, deploying, and security; in fact, you may want to conduct some proof of concept work early on to identify specific limitations or issues. MSDN has extensive information on this, and several outstanding books were published in the early days of .NET:
- Adam Nathan's: .NET and COM the Complete Interoperability Guide
- Andrew Troelsen's: COM and .NET Interoperability
We understand that Interop may be required for some components, so gmStudio has specific features to help automate and simplify the use of Interop in migrations.
gmStudio creates Interop Assemblies for your migration project when you select [Tools/Author Interop Assemblies] from the menu. This operation is included by default in batch migrations of the "Interop" type.
Behind the scenes, gmStudio uses MSBuild to create Interop assemblies. It does this by creating a csproj file that references the desired components and then running MSBuild to build the project file. We found this was the most robust way to reproduce the de facto "standard" importing behavior.
Local and External Components
COM dependencies can be classified as being either local or external:
- A Local component is based on a migration unit that is part of the migration project.
- An External component is based on a reference to a COM type library file (TLB, DLL, OCX, etc.) that is external to the migration project.
Typically you will use interop only for external COM components that cannot be replaced with a .NET component. Local components will almost always become their one .NET replacement.
Validating Interop Assemblies
If you are working on a machine where the COM components referenced by your migration are properly registered, then creating and using Interop assemblies should be a completely automatic process. However, if that is not the case, you will have to identify missing Interop assemblies and create them manually. This can be done using the tlbimp.exe/aximp.exe tools or by using the GenInterop project files created by gmStudio.
The RefStat field for each migration task can be used to indicate the status of Interop assemblies for the COM components it references:
- RefStat=READY means all the Interop assemblies required for the migration unit are found in the Interop folder.
- RefStat=~ASM means at least one Interop assembly required for the migration unit could not be found in the Interop folder.
Key Point:
Controlling RefStat behavior | The meaning of RefStat=READY is controlled by the RefStatFlags setting in the application config file. RefStatFlags = "IDF"; require IDF only.
RefStatFlags = "ASM"; require Interop only.
RefStatFlags = "IDF+ASM"; require both IDF and Interop |
The References Panel
The RefStat field in the task list can tell you if you are missing an Interop assembly, but it cannot tell you which one. In order to do that you will have to look at the References Panel.
The references panel provides detailed information about all the components referenced by each migration unit. One piece of this information is the AsmStat field:
- AsmStat=READY means the Interop assembly is in the Interop folder.
- AsmStat=NOTFOUND means the Interop assembly is not found in the Interop folder.
Click [Rebuild Interop Assembly] from the reference context menu to rebuild an Interop assembly.
When gmStudio creates an Interop assembly it produces a log file in the workspace\log folder. The name of the file is derived from the COM filename with the extension .import.log.