Project Analyzer Help

Limitations and known bugs

This pages lists the known bugs and limitations 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.

Please report any new bugs to Aivosto. If you can, attach a short code file or test project to facilitate debugging. Sample code is essential to get bugs fixed.

Recommendations for best results

Make sure your project compiles and there are no syntax errors.
Use Option Explicit. Always declare your variables with the correct data type.
For VB3 programs, save your files as text.
Use good coding practices. Your code will be easier to read and analyze.

Demo limitations

The free demo is limited to analyses with 10 source code files. You can analyze projects of any size, but max 10 source files at a time.

Full version limitations

How many lines can Project Analyzer handle?

Project Analyzer is designed to work regardless of code size. It has been successfully used with single projects that are over 100 MB in size and have over 2 million lines. What is more, it can handle large systems with more than 100 projects via multi-project analysis.

RAM requirements. Project Analyzer stores all your code in RAM, requiring double the megabytes of the source code. This could affect you if you analyze a very large number of huge projects via multi-project analysis. Binary files are not stored in RAM.
The number of files in an analysis is limited to 32767.
Super Project Analyzer can handle a group of max 100 projects (.sud files) at once.
The hypertext view shows a maximum of 32767 lines at a time. Lines 32768- will be hidden. The code analysis is not affected.
The maximum number of problems shown in the problem list at the bottom of the main window is 5000. This is not the maximum number of problems that Project Analyzer can detect, though. You can create more restrictive problem filters and handle problems in smaller groups. In practice, it is easier to work with a limited number of problems at a time.
A COM file can rarely contain tens of thousands of procedures. This is not a problem but may require a large amount of system resources when loading it in the treeview of the main window. You can overcome this by either leaving the COM file unanalyzed or analyzing it but not viewing its contents.

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.

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. You should not reuse keywords as variable or procedure names to avoid confusion.

Non-standard declarations. Each variable and procedure declaration is expected to exist on its own line. Detection of variable and procedure declarations is not correct if you write several statements on one line. Examples of problematic cases:

Function MyFunc(x) : MyFunc = 1 : End Function
Dim x: Dim y

If this causes problems, split the function declaration on several lines and rewrite the Dim as Dim x, y.

Line continuation _ is fully supported by the analysis, but not by the hypertext view or Project Printer. This has the following effects:

Only the first line of multiline comments appears as comment. Multiline comments are rare. You should rather write several single-line comments than continue a comment with the _ syntax.
Some procedure calls may be mishandled. This happens if there's a line break after a procedure name, and the exact target of the procedure call depends on code following the line break. For example, choosing between property Get or Set depends on whether there is an assignment operator = later on the line. Or, selection from overloaded procedures depends on the call arguments.

Unsupported VB.NET features

Block-level local variables and constants are treated as procedure-level variables and constants. VB.NET allows you to redefine a local variable/constant several times within a single procedure. Project Analyzer considers only the first such declaration of each name. Any additional block-level declarations are ignored. Example of redefinition of variable y:

Function MyFunc(x)
Dim y As Integer = 1
Do 
   Dim y As String = "abc"
Loop

Redefined locals cause loss in the ability to detect dead variables and constants in that procedure. If the redefined locals are of different object data types, some procedure calls may also go undetected. You should not redefine variables/constants within a procedure to avoid confusion and errors.

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 supported.

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.

VB.NET character limitations

For VB.NET source files, Project Analyzer can handle the following encodings: Default Ansi codepage, Unicode, Unicode (Big-Endian) and UTF-8 with signature. Other encodings are not supported by Project Analyzer (and can cause problems with Visual Studio too). You can set the encoding in Visual Studio by choosing File|Save file.vb As and selecting Save with Encoding.

Unicode/UTF-8 limitation. Characters other than those in the system's Ansi codepage will display as their closest Ansi equivalent. As an example, the Greek character alpha (α) may display as "a" on a non-Greek system.

VB 2005 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.

Parametrized classes (generic classes Of Type) are supported to the extent that is possible without considering the Of Type parameters.

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:

TextBox1 = "string" ' Not resolved, write TextBox1.Text = "string"
MyCollection(123)   ' Resolved OK, calls MyCollection.DefaultMember(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 anyway, they should be replaced by properties.

ReDim is not an array declaration! It is an executable statement that allocates memory for an array. Classic VB allows you to ReDim an array for which there is no corresponding Dim. Even though this is possible, it should be avoided, because such an array is an implicit variable with no early-bound data type. Always Dim first, then ReDim. Project Analyzer will ignore arrays without a Dim.

.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.

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.

Multiple statements on one line problem is reported for time literals: dteStartTime = #12:00:00 AM#

Get => Set. No calls are allowed from Property Get => 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.

Conditional error handling such as If Not DebugMode Then On Error Goto x is reported as a missing error handler.

If all fields of a .NET Structure are dead but the Structure is live, autofix removes the fields leaving an empty Structure block. In this case, the project may not compile as a Structure must have at least one instance field or event.

Super Project Analyzer treats two files in different directories but with the same filename as one file.

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.

In the hypertext window, letters in DefType statements may be mistaken for one-letter variable names
In the hypertext window, if you have two different definitions with the same name (e.g. Form1.MyVar and Form2.MyVar), the program may highlight the both in red when only the other one should be highlighted. This bug has no effect on the real analysis.
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.