Known Issues

Very long type names

NDoc creates an HTML file on your hard drive for each topic it generates. Currently the name of this file is derived directly from the full name of the type or member being documented. If the total number of characters in an item's full name (namespace + type + member name) exceed the value of _MAX_FNAME (256 characters), NDoc will fail because it attempts to create a file with a name that is longer than the file system supports. In addition, the fully qualified path to a file cannot exceed _MAX_PATH (260 characters).

For fully qualified names under about 200 characters, the work around for this issue is to set the OutputDirectory setting to a location as close to the root of a volume as possible. This will reduce the likelyhood of the full path to the html files exceeding 260 characters.

There is no work around for names that exceed these lengths.

We will address this issue in a future version of NDoc.

Case-sensitivity

When the MSDN and JavaDoc documenters create files, problems can arise when there are Types or Members that differ only by case.

It is possible to work around this problem by avoiding types and members that differ only by case; for example use public property Thing and private field _thing, instead of Thing and thing.

We will address this issue in a future version of NDoc.

StrongNameIdentityPermissionAttribute

To work around this issue, conditionally compile a version of the assembly that does not include the StrongNameIdentityPermission attribute.

Compact Framework incompatibilities

When an assembly compiled to run on the .NET Compact Framework is added to an NDoc project, the GUI may throw an exception, especially if the assembly references Microsoft.WindowsCE.Forms or SqlServerCe.

There is no work around for this issue.

We will address this issue in a future version of NDoc.

Localisation

NDoc does not currently support Localisation of headings and predefined text.

We *may* address this issue in a future version of NDoc.