Help contents
Multi-project analysis - Introduction
Enterprise Edition only
Multi-project analysis analyzes .vbg and .sln files, several projects together, and the use of COM libraries in VB code.
The most fundamental entity in project analysis is the project. Visual Basic projects are described in .vbp, .vbproj, .vbdproj and .mak files, depending on the VB version. All editions of Project Analyzer support single-project analysis where you analyze one project at a time.
Larger systems may consist of several projects, for example, a standard executable project, a .dll library project, and several .ocx component projects. When you need to find out the dependencies between several projects, you need multi-project analysis.
What can you do with multi-project analysis?
Project Analyzer Enterprise Edition supports analysis of several projects at a time, and analysis of COM library files. Enterprise Edition is required if you want to
- analyze several projects in one run
- analyze .vbg or .sln files
- analyze contents of COM/ActiveX libraries (.exe, .dll, .ocx, .tlb, .olb)
- discover dependencies between several projects
- discover dependencies between VB code and COM libraries
- show up dead code in source code files shared by several projects (in the Standard and Pro Editions, this analysis is done with Super Project Analyzer)
Supported multi-project analyses
Multi-project analysis is typically used when a project calls other projects in the same project group or solution. It's also used when a project uses a library file or a binary control. The following table lists what kind of systems you can analyze with multi-project analysis.
|
Calls analyzed to |
|
| Main project written in |
-> VB Classic projects (.vbp) |
-> VB.NET projects (.vbproj, .vbdproj) |
-> COM libraries
(.ocx, .dll, .exe, .tlb, .olb) |
Project group file type |
| VB Classic |
Yes |
To .tlb file only |
Yes |
.vbg |
| VB.NET |
Limited |
Yes |
Limited |
.sln |
In addition, multi-project analysis is handy is if there are several projects that don't call each other, but that share some source code files. For example, two .exe projects that have common .bas or .cls files can be analyzed together to show up dead code that's not used by either of the projects. This arrangement often makes Super Project Analyzer redundant in the Enterprise Edition.
Unsupported analyses and limitations
- Compiled .NET assemblies are not analyzed.
- Code written with other .NET languages than VB.NET is not analyzed.
- Conventional DLL files are analyzed via DLL analysis, if enabled.
- The ASP.NET Web Reference infrastructure is not supported.
Client references are resolved up to the proxy class but not from the proxy to the web service project. Thus, you can see calls within the client and the server project, but not between them.
- Visual Basic 3.0 is a single-project environment. The use of multi-project analysis is limited to projects that share some source code files.
- Analysis of late-bound calls is limited. If you use the As Object data type to store objects, and/or if you instantiate objects via calls to the CreateObject() function, you're using late binding. Project Analyzer tries to resolve all late-bound calls, but it's not always possible. Source code analysis is at its best when the projects use early binding.
Limitations in mixed version analysis and COM Interop
Multi-project analysis can analyze systems consisting of
projects written with several VB versions. COM Interop in .NET is supported only partially. If you mix VB Classic and .NET projects, or .NET projects and COM files, there are some limitations.
- VB Classic to .NET (limited). A VB classic project calls a .NET project. In this setting, Visual Studio .NET generates a .tlb file, which will be referenced by the VB classic project. Project Analyzer detects the calls to this .tlb file, but doesn't map the calls to the actual .NET source code. Thus you're limited to analyzing the .vbp project and the .tlb.
- VB.NET to OCX (unsupported). A VB.NET project uses an ActiveX control (OCX). Project Analyzer doesn't correctly detect the use of the ActiveX controls on .NET forms.
- VB.NET to ActiveX control project (unsupported). A VB.NET project uses an ActiveX control developed in VB Classic. Project Analyzer doesn't correctly detect the use of ActiveX controls on .NET forms, and existing calls to the ActiveX control project will go undetected.
- VB.NET to COM (limited). A VB.NET project uses a COM file. The analysis detects most of the calls to the COM file, but ignores others. More about Interop
- VB.NET to VB Classic project (limited). A VB.NET project uses a VB Classic project (ActiveX OCX/EXE/DLL). The analysis detects most of the calls to the VB Classic project, but ignores others. More about Interop
©Aivosto Oy - Project Analyzer Help Contents