Multi-project analysis - Introduction

Multi-project analysis analyzes several projects together. It supports .vbg and .sln files.

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. The Enterprise Edition is required if you want to

analyze several projects in one run
analyze .vbg or .sln files
discover dependencies between several projects
discover dependencies between VB code and binary files
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.

You can always analyze several classic VB projects together, and several VB.NET projects together. Analysis of mixed systems (both classic VB and VB.NET) is limited. The following table lists which combinations are supported and which ones are limited.

Source project	Classic VB	VB.NET
	Target project
Classic VB	Supported	To .tlb file only
VB.NET	Limited	Supported

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

Code written in other .NET languages than VB.NET is not analyzed.
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