Limitations

This pages lists the limitations and known bugs in Project Analyzer.

Project Analyzer is of high quality. These limitations and bugs affect special cases and are of minor importance in most programs. We provide this list as an indication of our commitment to quality and honesty.

Recommendations for best results

Make sure your project compiles and there are no syntax errors.
Use Option Explicit. Declare your variables with Dim. Include "As Datatype" where possible.
Use good coding practices. Your code will be easier to read and analyze.
The VB.NET compiler generates VB code for certain project types, such as XAML. Compile your project before analyzing to make sure the most recent code is being analyzed. Compilation is required for XAML projects.

Demo limitations

The free demo analyzes max 10 source code files at a time. You can open projects of any size, but select max 10 source files to analyze.

Full version limitations

The full version of Project Analyzer processes systems of virtually unlimited size. It has been successfully run on source with over 2 million lines and over 100 MB in size.

Maximum number of files analyzed is 32,767.
Maximum number of projects is not limited in the Enterprise Edition. It handles more than 100 projects.
Maximum number of problems shown in the problem list at the bottom of the main window is 20,000. Project Analyzer is able to detect more problems, but will not display them at once. Create a more restrictive problem filter to work on less problems at a time.
Super Project Analyzer handles max 100 projects (.sud files) at a time.
The hypertext view shows a maximum of 32,767 lines at a time. Lines beyond 32,768 will be hidden. The code analysis is not affected.

Analyze directory tip. Analyzing a full directory path may cause too many extra files to be included, slowing the analysis down. Try analyzing project or solution files instead of a directory path. This ensures that just the source files in use will be analyzed.

Reporting tips. Certain reports may fail on very large systems due to out of memory conditions. You can overcome this by saving the reports in HTML, MHT or plain text format. For the same reason, if Project Printer should fail, run it without the "Create reports" option.

Analysis limitations

Late binding. Analysis of late-bound references is somewhat heuristic. Late binding occurs when calling a procedure or reading/writing a variable via an expression whose type is available only at run-time. Typically, this affects Variant or Object variables that are used to store object references, or Form variables that store form references. Example:

Forms(2).DoSomething

Since it's not obvious which form Forms(2) will be at run-time, Project Analyzer searches for all available methods named DoSomething and adds a call to each of them. Because of this, you may see extra calls in your call trees. These are calls that are syntactically possible, although they may look strange to you if you know which form Forms(2) will be. You can disable the analysis of late-bound references in the options.

Early binding is recommended instead of late binding wherever possible. Instead of As Form, type your variables As Form1. Instead of As Object use As MyObject, and so on. Be as specific as you can.

For a late-bound UserControl.Parent, all forms are assumed to be the possible parent form, regardless of which form(s) the control is on.

Unknown targets. Calls are ignored when the call target is unknown in the analysis. For example, the following calls are ignored in call trees:

OtherProject.Class.Method In this example, the entire statement is ignored when OtherProject was not analyzed.
Dim x As ClassA : x.Method In this example, the call to Method is ignored when the data type ClassA is unknown.

Unsupported VB features

Undeclared variables (implicit locals) are not detected nor analyzed. You need to add a Dim for all local variables. Use Option Explicit to force this. Exception: Undeclared dynamic arrays allocated via ReDim are detected. ReDim is not a declaration, but an array (re)sizing operation.

Event limitations. It is often hard or impossible to tell when a certain event fires. For example, Load MyForm often causes Form_Load, but not always. If MyForm is already loaded, Form_Load will not fire. For this reason, the execution order of event handlers is not detected. Event handlers are assumed live code when their firing is unknown.

[keyword] Support for the [keyword] syntax (where a VB keyword is used as an identifier) is not complete. Auto-fix may generate code that has [ ] stripped, resulting in compile errors. One should avoid using keywords or reserved words as variable or procedure names to keep the code less confusing and easier to maintain.

keywords as Type fields. VB keywords may be used as field names in user-defined Types. Use of these fields may not be detected.

Unsupported VB.NET features

Web References. Cross-project references via the ASP.NET Web Reference infrastructure are not detected. References are resolved up to the proxy class but not from the proxy to the web service project.

Multi-project analysis does not support all possible .NET analysis scenarios.

.NET and COM Interop analysis is limited.

Delegates are not analyzed.

Constructor limitations. Calls to parameterless Sub New() are not always detected, as there are several "invisible" ways to instantiate an object. Parameterless Sub New() is assumed live. This limitation does not affect constructors with parameters.

Attribute block code in VB.NET is analyzed as any other code. This limits the detection of references to custom attributes.

The syntax <MyData(field:=value)> is not handled as a reference to the variable or property MyData.field.
The syntax <MyData()> is not accepted as a reference to class MyDataAttribute.

Resource files (files referenced by .resx file) are not considered part of a project. After auto-fix, you will need to copy such files manually to destination directory before compiling.

VB 2005/2008/2010/2012/2013 limitations

ASP.NET code is analyzed for the .vb files (codebehind classes). The web page files are not analyzed.

Operator limitations. Calls to Operators are not resolved. Operators are assumed live.

Generic types, the (Of Type) syntax, are supported. The support is limited so that the Of Type parameters itself are not analyzed.

VB 2008/2010/2012/2013 limitations

Implicit For index variables are supported. However, if several different For index variables exist in the same procedure, and each variable has the same name, Project Analyzer does not support that.

Lambda Subs and Functions are supported partially. Calls and argument passing to lambdas are not analyzed.

Variables declared in LINQ expressions are ignored. In the following example, LINQ variable cust is ignored:

Dim customersByCountry = From cust In 
   customers Order By cust.Country

XAML projects need to be compiled before analysis.

VB 2012/2013 limitation

Global Namespace blocks (Namespace Global .. End Namespace) are not fully supported. The Global keyword is supported.

Unsupported VB 3-6 features

Parameterless default members calls. Classic VB allows you to mark a method or a variable of a class as the default member. You can then call the default member implicitly by leaving the member name out of your code. Project Analyzer will not analyze such a reference unless there are parameters in the call. Examples:

' Not resolved, write TextBox1.Text = "string"
TextBox1 = "string"

' Resolved OK, 
' calls MyCollection.DefaultMember(123)
MyCollection(123)

Implements variables. If a VB 4-6 interface class is implemented via the Implements statement and there is a public variable in the interface class, implementor classes must implement the variable as property procedures. No calls are shown to the properties from places where the variable is used, although there is a call at run-time. Use of public member variables is not recommended, they should be replaced by properties.

.dsr/.dsx file limitation: Controls are not detected on ActiveX Designer Forms.

.frx file limitation: If a .frx file has a different name than the corresponding .frm file, the .frx file is ignored.

FRX window limitations. You can view most data stored in .frx files for the VB intrinsic controls. Examples of supported properties: PictureBox.Picture, ListBox.List, ListBox.ItemData, TextBox.Text, MouseIcon. Not all properties are supported, though. This applies mostly to 3rd-party controls using non-standard data storage. Examples of unsupported properties: AniButton.Picture, SSCommand.Picture.

object.method parameter. The method call syntax object.method parameter may cause the reference to parameter be ignored if method is a VB6 keyword. You can overcome this limitation by using the syntax Call object.method(parameter). This bug may also affect you when analyzing VB6 code that calls COM objects having method names similar to VB6 keywords.

Write reference to a UDT variable may turn to a read. This happens when passing a UDT field to a procedure that writes to the field. Affected syntax: Input #1, myudt.field. In this code, field is written to, but myudt is "read" instead of written to. This leads to extra "Variable read, not written to" problems.

VB3 binary source files cannot be analyzed. Save your .frm and .bas files as text.

Known misbehavior

Excess scope problem may be reported on a Public member of a class if the following conditions are true:

The member is called within its own class but with a qualifier such as object.member, AND
The member is not called outside of its own class.

Get => Set. No calls are allowed from Property Get to Property Set or Let within the same property. Normally this does no harm, because that kind of programming is rare.

Auto-fix may rarely delete live code because of the above reasons. Use the comment out option to get code back in case of problems.

Character set issues. Project Analyzer supports Unicode. Display and reporting often limits us to the current Windows ANSI codepage. That is, Japanese code displays best when the Windows locale is set to Japan, and Greek letters show up best when running as Greece. You can change the locale in the Regional Settings of the Windows Control Panel. If some national characters display oddly, change the Default source codepage setting.

Duplicate name bugs

Project Analyzer is designed to detect the scope of names and handle cases where different things have identical names. However, in some cases two identical names may cause subtle errors.

If a local var/const has the same name as the procedure it's in, the procedure name will be mistaken for the var/const name in the Hypertext window and Project Printer. This has no effect on the analysis, though.
If a module and a public procedure/variable/constant have the same name, this may lead to incorrect detection of the reference and thus incorrect dead code detection. This bug doesn't affect UDTs or Enums, because they can't have the same name as a module.
Calls to Overloads procedures are resolved where possible. Unfortunately the actual behavior of VB.NET is ill-defined, and the behavior doesn't always match Microsoft's documentation. In specific, what VB.NET picks as the call target is not clear where two Overloads procedures have the same number of parameters, the parameters differ by their data types, but a 3rd data type is being passed as an argument. Therefore, Project Analyzer cannot always resolve a call to the correct Overloads procedure. Where it cannot, it makes an educated guess of the possible calls.
Overloaded extension methods are not fully supported.