Enterprise Edition only
Project Analyzer can analyze COM files used in any Visual Basic project. It requires that the used COM files are correctly registered in the system registry.
COM analysis reads information stored in a type library in a COM file. A type library describes the public interface that is available for others to call. It stores information on public classes, methods, properties, parameters, events, user-defined types, constants, enums and aliases. Unions, which cannot be used in VB, are not shown.
When you include a COM file in your analysis, its contents appear in Project Analyzer as regular classes, procedures, events, enums etc. For example, the summary report will include COM procedures in its procedures count. Because of this, you might not always want to include COM files in your analyses. COM analysis is most useful for files that you or your colleagues wrote.
The COM information you get is limited to the public interface. COM analysis doesn't reveal anything about the internals, such as private procedures that actually implement the interface. Thus, when you have the source code for a COM file available, it's better to analyze the source rather than the COM file. The information available in a COM file is limited to the interface it exposes to other projects. However, by analyzing the source code you can also understand the internals.
COM analysis reveals the dependencies between your code and a COM file. For any procedure you can see where it's being used by viewing the call trees. In a file dependency tree, you can see which source code files actually call the COM file. Or, for a given source code file or procedure, you can see exactly which COM files it requires.
Finding dead code, or other programming problems, is not part of COM analysis. Dead code and other problem information is useless for binary files for which you have no source code. If you have the source, you can analyze it instead of the COM file. Just do a multi-project analysis with the user project(s) and the COM project(s). This way you can find out which procedures are dead and what other problems there may be in the code.
Analysis of .exe/.dll files is limited to COM (ActiveX) files. In VB 5.0 and 6.0, ActiveX OCX/DLL/EXE projects compile to a COM file. In VB 4.0, the same effect is achieved via an OLE Server project. VB.NET supports COM file creation. COM files may also be developed with other languages, such as C++ or C#.
To keep the results correct, make sure that any COM files are correctly registered in the system registry. Although Project Analyzer is able to analyze unregistered COM files, it might not always be able to find the correct file because it's not registered. This happens especially if you analyze your system on another computer than where you developed or compiled it. Use regsvr32.exe to register COM files that don't show up in Project Analyzer.
Version issues might affect you if you have an ActiveX project that other projects use. When you compile the ActiveX project into, say, an OCX file, you have a new OCX file version on the disk. Now, the existing projects may still refer to the old version, which is now replaced by the new one. VB will automatically upgrade the other projects to use the new OCX, but Project Analyzer might not necessarily detect the new version. If this happens, open the other projects in VB and save them to store the changed version info.
Project Analyzer can analyze .NET projects that consume COM libraries. There are limitations, though. The most notable limitation is that Project Analyzer doesn't analyze ActiveX controls placed on .NET forms.
Visual Studio .NET uses special rules to import types from a COM file. For example, it may use tlbimp.exe or aximp.exe. The process results in names that don't exist in the original COM file. If you use these names, they are not understood by Project Analyzer. As long as you use the names as defined in the COM library (or the original source code), Project Analyzer works correctly.
Example 1: Class BankAccount exists in the original COM file. Tlbimp.exe generates an interface BankAccount and a class BankAccountClass. Project Analyzer will notice only BankAccount, as it's defined in the original file. BankAccountClass will be ignored.
Example 2: Control MyCoolControl exists in the original OCX file. Aximp.exe generates two libraries, MyCoolControl and AxMyCoolControl. You put AxMyCoolControl on a .NET form. Project Analyzer will not notice nor analyze AxMyCoolControl.
Make sure that you have selected the file for analysis when you start the analysis.
To analyze a COM file, you need a project that actually uses the COM file, as Component or Referenced file. You cannot analyze a single COM file without a VB project.
This analysis is not supported.
Read more about COM Interop and the limitations.
This analysis is not supported.
COM analysis is not to be confused with conventional DLL file analysis, even though a COM file can have the .dll extension. Project Analyzer can find much more information on COM files than conventional DLL files.