Version 11.2
(26 Jan 2022)
- NEW: The highlighted notice "API is not CLS-compliant" is displayed for members with CLSCompliant(false) attribute.
- NEW: Added support for private protected code members. They were incorrectly recognized as protected previously.
- FIX: Visual Studio 2022 could crash if "Browse" button was pressed for Output Folder, External Files Folder or Templates Folder in VSdocman "Output" project properties. Other VS versions were not affected.
Version 11.1
(23 Dec 2021)
- FIX: Some links were not resolved correctly when a "using" statement in C# or "Imports" in VB was used. The issue was introduced in version 11.
- FIX: The "Select reference" dialog in the comment editor didn't contain members from referenced assemblies. The issue was introduced in version 11.
-
FIX: In rare cases, some class diagrams, and possibly also some source files, failed to compile if the documentation was compiled from command line using VSdocmanCmdLine.exe utility.
Version 11.0
(16 Dec 2021)
- NEW: Added support for VS 2022.
- CHANGE: Removed support for VS 2013 and VS 2015. Only VS 2022, 2019 and 2017 are supported now.
- CHANGE: Removed /vs parameter from VSdocmanCmdLine.exe command line utility. This parameter was used only with VS 2013 and 2015 that are no longer supported.
- CHANGE: VSdocman now installs to "C:\Program Files" folder by default, instead of "C:\Program Files (x86)". So if you are using the command line version, change the path to VSdocmanCmdLine.exe utility or install VSdocman to the original x86 folder.
- FIX: The WYSIWYG comment editor added an extra newline at the end of a <code> block in some cases.
- FIX: The html_msdn2019 output was not rendered correctly (the left tree was missing) if it was viewed online in Chrome with some extensions installed. For example, Grammarly was such a problematic extension.
- FIX: Improved search results in html_msdn2019 output format. If a topic title contained the searched word, it was not listed at the beginning of the search results if there were other topics that contained this word too many times in their text.
Version 10.0
(30 Mar 2021)
- NEW: The WYSIWYG comment editor is now available also for external XML doc files that are included with <include> XML doc tag. It is available from the comment editor, Advanced tab. There's new "Editor" button in the include section.
- NEW: The option to always open VSdocman window with SOLUTION-WIDE PROPERTIES instead of the project that is active in Visual Studio. It's in VSdocman Options > Miscellanous > General.
- CHANGE: XML comments, such as <summary><!-- this is comment --></summary> inside XML doc comments are allowed now. Unlike before, they are not outputted in the generated documentation now. The WYSIWYG comment editor will preserve such XML comments too.
- CHANGE: The comment editor will generate   entity for a non-breaking space. This is to easily distinguish it from a normal space.
- CHANGE: The comment editor will no longer generate " and ' entities for " and ' characters in XML text. Such escaping is needed only in XML attributes and not doing it in the text will make XML comments more readable.
- CHANGE: The comment editor did not open if the active document was under source control (TFS) and was not checked out. The editor will now check out automatically, if the "Check out automatically" when editing is selected in VS source control options.
- CHANGE: When the user inserts a table or a code block in the comment editor, an empty paragraph is added before and after it if needed, to ensure that it's possible to enter text there.
- CHANGE: Links to enum items, such as <see cref="MyEnum.Value1"/>, are no longer generated as non-link bold text. The link to the owner enum is generated now.
- CHANGE: The values of enum fields are now displayed in generated html_msdn2019 and chm_msdn2019 output formats.
- FIX: If a type, e.g. a class, was excluded because it had no XML comment and "Compile also non-commented members" option was not selected, its members such as methods and properties were still included in the documentation. They were not available in the contents tree, but they could be visible in search results.
- FIX: The errors in external XML doc files were not reported during compilation. Such external XML files are included with <include> XML doc tags and they can cause various problems - IO error, invalid XML syntax, etc.
- FIX: XML errors in custom topics were not reported during compilation. This could happen if the user edited the XML source of the topics directly instead of in the WYSIWYG editor.
- FIX: "Dead link" warnings in custom topics were not reported during compilation.
- FIX: In custom topics (not in code members), the links to methods with parameters were not generated correctly in the final documentation, for example <see cref="Ns1.Class1.Method1(Ns1.Class1)"/>.
- FIX: "Dead link" warnings occurred for incomplete links to generic methods with parameters excluded. For example, <see cref="Ns1.Class1.Method1{T}"/>.
- FIX: Visual Basic properties, that had no explicit access modifier (Public, Private, ....) and were not auto-implemented (had Get and Set parts), were not included in the generated documentation.
- FIX: Whitespaces between inline tags in XML doc comments were removed in the WYSIWYG comment editor and in the comments coming from external XML files included with <include> tag. For example, the space between A and B in: <summary><b>A</b> <u>B</u><.summary>.
- FIX: The WYSIWYG comment editor added an extra space character after a <br/> tag.
- FIX: When the user added an exception or a permission in the WYSIWYG comment editor, it was not possible to edit the text in it and the <exception> or <permission> tag was not inserted in the generated XML comment.
- FIX: An extra empty <see> tag could be added after editing an existing link in the WYSIWYG comment editor.
- FIX: When the user clicked on a link in the WYSIWYG comment editor, the page was scrolled down to the end of the editable section in some cases.
- FIX: Some combinations of special XML characters in XML comments could produce wrong result in the generated documentation. For example, <summary>&lt;</summary> would produce "<" instead of "<".
Version 9.10
(30 Oct 2020)
- FIX: Improved processing of an empty <inheritdoc/> tag when it was inlined within another XML doc tag, for example, <remarks><inheritdoc/></remarks>. In such a case, any plain text from the base member was lost and only child XML elements were inherited, e.g. <para>. Moreover, if the <inheritdoc/> tag was used inside a <param> tag, the aggregated contents from all <param> tags in the base member was included.
- FIX: A dead link was generated for a <see> or <seealso> link in VB that was in form of cref="AAA.BBB.BBB" for class BBB in namespace AAA.BBB.
- FIX: An error occurred during documentation compilation, if there was a type with no namespace (e.g. a class directly in the empty <default> namespace) and no language was selected for generating the syntax in VSdocman options.
Version 9.9
(25 Sep 2020)
- CHANGE: Removed "Find interesting links" button in the comment editor in non-WYSIWYG mode. It was not used and reliable. And it is not needed anymore as most of these links are generated automatically in parameters, see also and other sections of documentation page.
- FIX: A "dead link" warning occurred for <see> or <seealso> links that contained a method parameter of type that was declared in multiple namespaces. For example, the link was <see cref="Method(MyClass)"> and there were two classes defined: Namespace1.MyClass and Namespace2.MyClass. VSdocman ignored the 'using' (or 'Imports' in VB) statements in this case.
- FIX: Sometimes, an XML comment was not inherited (whether using <inheritdoc> tag or automatically), if the base code member with the comment to be inherited was generic and stored in an external assembly.
- FIX: A "Couldn't resolve the <inheritdoc> tag because a circular reference was found" warning was reported incorrectly sometimes. This happened if an XML comment contained <inheritdoc> tag, the base code member also had <inheritdoc> tag and so on and the final member with a real comment was in an external assembly.
Version 9.8
(21 Sep 2020)
- NEW: New chm_msdn2019 output format was added. It has a modern look like the current online MSDN.
- NEW: The command line utility VSdocmanCmdLine.exe displays the VSdocman version and the version of Visual Studio that is used in the background.
- FIX: Visual Studio could crash when VSdocman tried to compile documentation for .NET Core 3.1 projects. This could also happen also for other project types but only in very specific cases. For example, an UWP application that targets Win 1809 and uses HockeySDK.UWP 4.1.6 Nuget package. The problem was related to a VS issue and occurred only when some specific versions of assemblies were referenced by the documented project. For example, it was not present with some .NET Core 3.1 updates.
- FIX: A "dead link" warning occurred for <see> or <seealso> links in some cases.
Case 1: the cref pointed to a method with a ref/out (ByRef in VB) array parameter, for example cref="Method(ref int[])".
Case 2: the cref pointed to a method with a multidimensional array parameter, for example cref="Method(int[,])".
Case 3: the cref contained some of the language specific data types - sbyte, uint, ulong, ushort in C# and Date, SByte, UInteger, ULong, UShort in VB.
Case 4: the cref was a link to a constructor in a language specific format, for example "Object.Object()" in C# or "Object.New()" in VB.
Version 9.7
(18 Jun 2020)
- NEW: Added new macros that can be used in the output templates or in XML comments (the latter needs a setting, see manual). The new macros are: $DATE$, $TIME$, $COMPUTER-NAME$, $USER-NAME$ and $%ENVIRONMENT-VARIABLE%$, e.g. $%TMP%$. These macros were already available in the comment templates for adding XML comments.
- FIX: Some inherited fields were listed in the generated Fields lists even if the 'List inherited members on "Class members" page' option was deselected. The problem applied only to the inherited fields that were defined in the solution. External inherited fields were not listed.
- FIX: Improved responsiveness when working with the files tree in Code Members - Files settings. When there were many source code files available (thousands), checking or unchecking a folder with many files or pressing the Select All/Deselect All buttons was slow.
Version 9.6
(9 Jun 2020)
- FIX: In the generated list of class constructors, there were listed also the constructors from the base classes. This was wrong because constructors cannot be inherited.
- FIX: Some inherited methods and properties were listed in the generated Methods or Properties lists even if the 'List inherited members on "Class members" page' option was deselected. The problem applied only to the inherited members that were defined in the solution. External inherited members were not listed, e.g. ToString() method from Object class.
- FIX: If you created a new solution profile with VSdocman profile manager as a copy of another profile, the solution-wide properties were not copied. The default properties were applied instead.
- FIX: Wrong formatting after pasting parts of ordered or bulleted lists in the WYSIWYG comment editor. If only some items of a list were copied in the clipboard, then they were incorrectly rendered if they were pasted in the edited text that was not a list.
- FIX: A linebreak entered with Shift+Enter was displayed as an unknown <br/> XML doc tag with the blue highlighting when it was reopened in the WYSIWYG comment editor. Now there's a correct new line displayed.
- FIX: Improved pasting of a source code to a code section in the WYSIWYG comment editor. For example, if a source code sample was pasted, e.g. from VS editor, empty lines were removed. Or when lines from one code section were copied to another one, the linebreaks were lost.
- FIX: In some cases, a dead link could be generated for <see> or <seealso> links containing methods with specified parameters. This happened in two cases. The first one was, if there existed a method or a property with the same name as the parameter type of the referenced method. For example, the link was <see cref="Method1(Action)"/> and there was also a method like the following one defined in the same class: void Action(). The second case was, if the referenced method was in another class than the comment with the link and the link was not in a full format, i.e. including the namespace.
- FIX: In Visual Basic code, a dead link was generated for <see> links containing the names inside square brackets. This syntax is used in VB for symbols that are same as the VB reserved words, such as Enum, ByVal, etc. For example, there was a method defined as follows: Sub [Enum](x As [Enum]). The corresponding link could be: <see cref="[Enum]([Enum])"/>. Such links are processed correctly now.
Version 9.5
(14 Jan 2020)
- NEW: Added new /outputPath parameter for the VSdocmanCmdLine.exe utility. It allows you to override the output location that was set in the project properties in the GUI.
- FIX: In the WYSIWYG comment editor, some unsupported formatting could be displayed right after pasting a formatted text, e.g. from MS Word. An example of such unsupported formatting could be merged table cells or a background color. Previously, it was necessary to close and open the editor again to fix it and display only allowed formatting.
- FIX: In the WYSIWYG comment editor, underscore characters were sometimes removed in the Syntax section, for example, if the commented class or method name contained an underscore. This was just a cosmetic issue in the read-only section in the editor. The syntax section in the generated documentation was correct.
Version 9.4
(28 Oct 2019)
- CHANGE: Cosmetic enhancements in the html_msdn2019 output format.
- FIX: If the cursor was placed on an event definition in C#, adding an XML comment or opening the comment editor was done for the parent class instead for the event.
- FIX: Sometimes, the pasting in the WYSIWYG comment editor didn't work and you had to press Ctrl+V multiple times to actually paste anything.
Version 9.3
(7 Sep 2019)
- NEW: You can generate a report file with detailed statistics about all documented projects. This is disabled by default, you can enable it in the Output - General options.
- CHANGE: Improved the html_msdn2019 output. Much faster search, especially when the documentation has more than 10000 topics. Force "whole words" mode in the full-text search even without the need to put the search phrase inside quotes, for more details, search for "searchAlwaysWholeWord" in the VSdocman manual. Improved customization with the vsdocman_overrides.css file.
- FIX: The comment editor window could be empty in Visual Studio 2019 version 16.1 and higher, if the editor is shown as a modeless tool window and not a modal window.
- FIX: When compiling documentation from command line with VSdocmanCmdLine.exe, a 'Could not load file or assembly EnvDTE' exception could occur.
- FIX: Application could crash when pasting a text copied from MS Word or Wordpad (and maybe some other applications too) into WYSIWYG comment editor.
- FIX: The following error could occur when generating a documentation: "1 is not a supported code page. Parameter name: codepage". This happened very rarely and only on systems with specific regional settings.
- FIX: In rare cases, "The registration code you entered is invalid" error could occur when you pasted the registration code from the formatted email that you received after your purchase of VSdocman.
Version 9.2
(26 Jun 2019)
- NEW: Improved custom topics. There are three types of custom topics, one of them was Chapter without text. This type is now extended to Topic or chapter without text. As a new thing, you can specify a target external file or URL that will be opened when such a topic is clicked in TOC.
- FIX: When a hyperlink to a URL was specified in the short format without a text, for example <see href="https://www.helixoft.com"/>, an incorrect text was generated for the link in the documentation, such as "https://com".
- FIX: When a generic C# method had a generic return type, then incorrect type parameters were produced in the XML comment or generated documentation. For example, for the method "IList<int> Method1<T1, T2>()", there was only one type parameter "int" instead of two type parameters "T1" and "T2". This only affected C#, not VB code.
- FIX: Better handling of situation, when compilation from command line with VSdocmanCmdLine.exe sometimes failed for .SDK style projects (.NET Core projects and .NET Standard projects). This is a confirmed issue in Visual Studio. This problem shows itself in that the generated documentation is empty, only custom topics are generated but no code documentation is compiled. As a temporary workaround, you can use new /solutionLoadedWait parameter of VSdocmanCmdLine.exe utility. See VSdocman manual for more information in Using VSdocman > Using VSdocman from Command Line.
Version 9.1
(30 Apr 2019)
- CHANGE: Generated CHM files are now able to show HTML5 and CSS3 content. This will affect only users who customize their CHM output. The CHM viewer in Windows uses very old IE7 mode by default. This is the reason why HTML topics in a CHM file cannot use many modern HTML and CSS features. This change instructs the viewer to use the latest IE version installed, which is IE11 in most cases. This allows you to customize the CHM output, for example with vsdocman_overrides.css file (see VSdcoman manual for details) and use e.g. the :before CSS selector for inserting a custom text or image in the header.
- FIX: In VS 2019, the VSdocman context menu entries for C# or VB files were sometimes not present, if VSdocman was not loaded yet. Moreover, this fix can improve your VS performance in VS 2019, 2017 and 2015. Previously, VSdocman was automatically loaded when a solution was opened. Even if VSdocman wasn't used at all. Now it is loaded only when you click on VSdcoman button or menu item.
- FIX: The incorrect "internal" accessibility was assigned to partial class, struct or interface definitions that had no explicit access modifier, e.g. "partial class C1". Instead, the accessibility should be taken from other partial definitions with an explicit access modifier, e.g. "public partial class C1". This could cause problems, if you selected not to include internal members in the documentation. In such a case, all members and comments from these partial definitions were not compiled. This problem only affected C#, it worked fine in VB.
Version 9.0
(24 Apr 2019)
- NEW: Added support for Visual Studio 2019.
- NEW: Added new html_msdn2019 output format. It has modern look and frameless layout.
- NEW: It's possible to use HTML code directly in XML doc comments. You can use any HTML tag, such as <span id="5" style="font-size: 50px;">, <div class="abc">, etc. These elements, that are unknown to VSdocman as XML doc elements, will be passed to HTML-based output (HTML, CHM, MS Help Viewer). In other outputs, such as Docx, these unknown tags will be stripped and only their content will be displayed as a plain text. Note that the HTML tags cannot be edited in the WYSIWYG comment editor, you need to insert them manually in the source comment. But the editor will display them and it will not remove them once they are present.
- NEW: VSdocman has a new menu. It's a top level menu in VS 2017 and lower. In VS 2019, the menu is under EXTENSIONS top menu. Previously, there was only a menu entry under TOOLS menu. Now you can also directly compile your documentation or edit comments, if possible.
- NEW: You can customize your HTML-based output (HTML, CHM, MS Help Viewer) more easily, without the need of modifying the output templates. Just put a file named "vsdocman_overrides.css" in your External files folder and VSdocman will automatically link it to all HTML pages. You can define your own styles or override the existing ones in that CSS file. For more details see the manual in "Using VSdocman > Tips & Tricks > Customizing HTML Output" topic.
- CHANGE: Removed support for VS 2012. Only VS 2019, 2017, 2015 and 2013 are supported now.
- CHANGE: Greatly improved the launch speed of the comment editor and partially also of the main VSdocman window, when they are opened for large solutions and projects.
- FIX: If a source code file is read only (e.g. in a run mode), it's no longer possible to open the comment editor. If a modeless comment editor is already open, it's not possible to make any changes in it. This is to prevent from loosing your changes that couldn't be written back to the file.
- FIX: When an XML comment was missing at a method with parameters or at a property, it was not automatically extracted from an implemented interface. Only VSdocman 8.5 and 8.6 were affected.
- FIX: Compilation from command line with VSdocmanCmdLine.exe sometimes failed for .NET Standard and .NET Core projects. No topics were generated in the documentation.
- FIX: Inserting an XML comment with the comment editor or from the "Add XML comment" menu has triggered reformatting of the commented code element, even if the auto-formatting was turned off in the VS options.
- FIX: In Docx and PDF outputs, if the "Constants and enumerations value display" option was set to "No value", the values were still displayed for enum items that had no explicit value set.
- FIX: An error occurred when processing a class diagram in some rare cases.
Version 8.6
(2 Oct 2018)
- CHANGE: Improved speed of the "Select reference" dialog box of the comment editor. Each time you re-opened the editor and then opened the "Select reference" dialog box, the tree with all available code members was rebuilt. This could take a significant amount of time. Now, the tree is cached for each project and the dialog opening is instant. You can still refresh the tree manually with a new button in the dialog.
- FIX: VSdocman now recognizes cref links in C# and VB specific syntax. There are three types of cref syntaxes that VSdocman accepts in XML comments. The first one is language neutral, where generic types and members use syntax: `1 and ``1. The ref and out parameters have a '@' character appended: Method(int@). The second one is C# syntax. Generic types and members use syntax: {T} or {String} for constructed types. The ref and out parameters have C# syntax: Method(ref int, out string). The last one is VB syntax, where generic types and members use syntax: (Of T) or (Of String) for constructed types. The ref and out parameters have VB syntax: Method(ByRef Integer). Until now, VSdocman only accepted the language neutral cref. However, Visual Studio only supports C# syntax in C# code and VB syntax in VB code. The language neutral syntax is used only by VSdocman internally and in external XML doc files.
- FIX: The comment editor now generates cref links in C# and VB specific syntax instead of the language neutral cref format. This fix is related to the previous one.
- FIX: When producing a documentation in the "MS Help Viewer" format, the generated unregister_<projectname>.bat script didn't unregister the documentation from VS 2017 help (Microsoft Help Viewer 2.3).
Version 8.5.2
(8 Jul 2018)
- FIX: After editing a method with parameters in the WYSIWYG comment editor, there was the "{additionalAttributes}" text included in the generated <param> comment tag. The issue was introduced in version 8.5.
Version 8.5
(25 Jun 2018)
- NEW: Added new <inheritdoc> XML comment tag. In addition to the automatic comment inheritance, this tag will allow you to control the inheritance of XML comments more precisely. For example, you can inherit only some parts of the comment or override some tags in it.
- NEW: Added three new macros that you can use in the project properties to specify the output path, templates path and external files path. The new macros are: $(ProjectName), $(SolutionName) and $(ProfileName).
- NEW: Added the option to disable listing of extension methods on Members page. This option is on Code Members - Member Types options page.
- NEW: Allowed also VB variants as values of the langword attribute in the <see langword="..."/> tag, such as Nothing, True, False, Shared, MustInherit, NotInheritable, Overridable. Moreover, you can use any text as a langword and it will be displayed and not ignored as before.
- NEW: In the comment editor, a tooltip with details is displayed when you hover over a link or a langword, such as 'null'.
- IMPROVEMENT: Significantly improved the startup speed of the comment editor when it's launched for the first time in the session. This applies to most but not all cases. When you open the editor for the first time in the session for a particular project, it is almost instant if it's done for a member with an existing XML comment. If there is no comment and the "Try inherit" option is enabled in the comment templates, then there's still a delay for the first time. It's because VSdocman tries to inherit the comment from types from referenced external DLLs, which may take some time if there are many references in the project. All successive openings or updates of the editor should be instant.
- CHANGE: It's now possible to use incomplete type names or language specific type names (e.g. int) as parameters in <see> links. Previously you needed to specify fully qualified type names or omit the parameters. Now you can use <see cref="int.CompareTo(object)" />.
- CHANGE: The WYSIWYG comment editor no longer removes custom inline XML tags that are not supported by VSdocman. For example, you can have a text <span id="1">some text</span> inside your <summary> block and it will be kept untouched by the editor. This is especially useful for <inheritdoc> tags that may have be nested inside top level blocks, such as <summary> or <remarks>. Similarly, the editor will keep custom attributes in supported XML tags, for example <summary locale="en">.
- FIX: Generation of a PDF documentation failed for the "Compile Solution to Single Documentation" operation.
- FIX: If the cursor was placed on a field, a constant or a single line property, that had some trailing comment (e.g. 'int Field1; //comment'), adding an XML comment or opening the comment editor was done for the parent class instead for the field.
- FIX: It was possible to select "Try to inherit from overridden member" in the comment template for constructors. This option was ignored and the comments for constructors were never inherited. So the option is removed now. It is still possible to inherit constructor comment with <inheritdoc/> comment tag.
- FIX: The generated text for a self-closed <see> link was incorrect, if the link pointed to an external method with arguments specified with full names, i.e. with dots in them. For example, <see cref="System.String.CompareTo(System.String)" /> was displayed as "String)" instead of "CompareTo(System.String)".
Version 8.4
(11 Jan 2018)
- NEW: Added new supported platforms whose versions you can specify and display in the generated documentation. These are: .NET Core, .NET Standard, Xamarin.Android, Xamarin.iOS and Xamarin.Mac.
- NEW: You can now specify what value will be displayed for constants and enums in the generated documentation. For example, if you have a constant const int C = 2+2, you can display the evaluated expression result "4", as before. But this may be time consuming if you have hundreds of constants or enum items. So you can also choose to display the original expression "2+2" or nothing.
- CHANGE: The specified supported platforms (such as Windows 10) are no longer listed in generated html_msdn2017 and chm_msdn2017 output formats. Only the frameworks versions are listed. If you don't want to include the platforms in other output formats, just leave the "Platforms shown in documentation" field empty on the Output - Platforms & Frameworks page of project properties.
- FIX: Generation or registration of Docx, PDF, XML and MS Help Viewer output formats failed, if there was an invalid XML character used. This could happen for example in the syntax section. If you had a constant such as "const char ACK = (char)0x6;" then VSdocman generated the 0x6 ASCII character in the syntax section. This character is not allowed in the intermediate XML files.
Version 8.3
(12 Dec 2017)
- NEW: Added F# declaration of a member in the generated Syntax section. Useful, if your class library is consumed by an F# client.
- CHANGE: Generic types, inherited and extension methods in the Methods list are listed in C# syntax instead of the unfriendly cref syntax. For example, IEnumerable<T> instead of IEnumerable`1.
- CHANGE: Inserted comments that were automatically inherited from referenced projects or assemblies had normalized links with prefixes. For example, <see cref="T:System.String"/>. While this was correct, IntelliSense didn't work for such links in XML comments. Now the prefixes are not inserted, for example, <see cref="System.String"/>.
- CHANGE: A single <para>...</para> block is no longer generated if it's the only paragraph in an XML comment section. This may happen if you had multiple paragraphs and then you deleted all except the one.
- FIX: The full-text search in HTML outputs didn't work if the search term contained a dot, for example "MyNamespace.MyClass".
- FIX: Applying a bulleted or a numbered list in the Exceptions in the WYSIWYG comment editor has caused that entire Exceptions section was lost in then XML comment.
- FIX: When using the comment editor in non-WYSIWYG mode, changes in user-defined fields were not saved to the edited XML comment.
- FIX: The method comment was not inherited from a referenced DLL, if the method had parameters of a generic constructed type, e.g. MyOverridenMethod(Ilist<string> x).
- FIX: Some unwanted methods from referenced DLLs were listed as inherited in the Methods list. For example, static methods were listed, such as Object.ReferenceEquals. Or both shadowed and shadowing methods were listed. For example, if you have your own class that inherits from the Exception class, there were two methods listed - Object.GetType and Exception.GetType. Moreover, these methods could be listed also in other unrelated classes.
- FIX: Some unwanted extension methods were listed in the Extension Methods list. For example, if your class implemented IList<String>, the Average(this IEnumerable<Double>) extension method was incorrectly listed too.
- FIX: Sometimes, not all member descriptions from referenced DLLs were found. For example, System.Linq.Enumerable.Aggregate methods listed in the Extension Methods list had no summary in .NET 4.0 projects.
Version 8.2
(12 Jul 2017)
- NEW: VSdocman XML comments can be inserted by typing triple /// or '''. This is disabled by default and can be enabled in VSdocman Options > Comments > General. When enabled, the VSdocman XML comments are inserted instead of the default Visual Studio XML comments when you type /// or '''.
- CHANGE: Removed the "Show $EOL$ as new line. Write new line as $EOL$" comment editor option. It has been obsolete for very long time.
- FIX: Installing VSdocman 8.x over an older version didn't uninstall the existing version in some cases. This happened, if there was an existing installation of VSdocman 7.6 or older and it was installed per user (Just me). The older versions allowed to be installed for "Just me" or "Everyone". If a previous version wasn't uninstalled, VSdocman didn't work correctly, for example the comment editor was empty, with just "aa" text.
- FIX: If VSdocman was opened while the solution was still loading, there could be some problems. VSdocman now waits until the solution is loaded.
- FIX: Missing comments were not inherited during compilation (whether from overridden or from implemented members) if "Compile Solution to Single Documentation" was executed.
- FIX: If there was a type (e.g. a class) that had no namespace, Visual Studio could crash during documentation compilation. This happened if a type was not inside namespace block in C#, or if it was not inside Namespace block in VB .NET and no Root namespace was defined at the project level. Such types are listed under <default> namespace now.
- FIX: If a type, e.g. a class, was excluded with <compilewhen> comment element, its members such as methods and properties were still included in the documentation. They were not available in TOC, but they could be visible in Index.
- FIX: If the cursor was on a field or a constant, but not directly on the field name, adding an XML comment or opening the comment editor was done for the parent class instead for the field.
- FIX: In the comment editor, when a link was pasted, unwanted <u> and <font color=...> tags were added for the link text.
- FIX: In the comment editor, when a link was pasted from outside, e.g. from a web page, it was not recognized as a link and only a plain text was created.
Version 8.1
(16 May 2017)
- NEW: Added support for .NET Core and .NET Standard projects in Visual Studio 2017.
- NEW: The generated documentation shows the return type of a method return value or a property and field value, similarly as it's been shown for method parameters.
- NEW: Added syntax highlighting for VSdocman output templates (.vbdt files). You only need to edit the output templates if you want to customize the look and feel of your generated documentation. You can now do it directly in Visual Studio with highlighted macros and comments. See <VSdocman folder>\Templates\Vbdt editing\readme.txt for more details.
- NEW: Added ability to generate an improved Index in CHM output formats. Such index allows for better context help invocation from external applications. See Viewing and Deploying Documentation > View and Deploy CHM Documentation page in VSdocman help for more details.
- CHANGE: The link selector in the Comment editor no longer generates <see> links with a prefix, e.g. T:System.String. This way the Intellisense will work fine for such links in VS code editor.
- CHANGE: The links generated in the default comments (e.g. after Add XML comment for constructor) no longer contain a prefix, e.g. T:System.String. This way the Intellisense will work fine for such links in VS code editor. Moreover, the links are created in the short format, e.g. <see cref="System.String"/> instead of longer <see cref="System.String">String</see>. You can apply these new options by pressing Reset button in VSdocman Options. You can backup your current options with the Export button first.
- CHANGE: Indexers in C# (properties with parameters in VB .NET) were always listed as 'this[...]' in generated TOC and member list tables. Now, this is changed to Item(...), or to the value of the System.Runtime.CompilerServices.IndexerName attribute, if this attribute is applied or to the property name, if it is a VB property.
- CHANGE: Previously, it was possible to create more than two columns only at the time when a table was created in WYSIWYG comment editor. The "Insert column" menu item is no longer disabled if a table has 2 or more columns so you can add a column at any time now.
- FIX: Smarter resolving of incomplete cref links. The search is performed also in all parent namespaces/types of the current type. For example, the link cref="Class1" in A.B.C.D.Class2.Class3 will be correctly resolved to A.B.Class1.
Version 8.0
(27 Feb 2017)
- NEW: Added support for Visual Studio 2017.
- NEW: Added MSDN 2017 HTML and CHM output formats for generated documentation. They have newer look, list of members is located on a class page and all overloaded members are directly accessible from the TOC and members list.
- NEW: Added PDF output format for generated documentation. MS Office 2010 or newer is required for the PDF creation.
- NEW: Added /devenvPath parameter for VSdocmanCmdLine.exe utility. It replaces /vs in case of VS 2017.
- CHANGE: Removed support for VS 2005, 2008 and 2010. VSdocman now works only with VS 2012 and newer.
- CHANGE: Removed RTF and Help&Manual documentation output formats. They were obsolete. Please use Docx instead of RTF.
- CHANGE: Better detection of the active project. If there is no project selected in Solution explorer (e.g. the solution is selected), then the active document, if any, is used to get the project. This mechanism is used when you open VSdocman window. On the other hand, if you open the comment editor, the project of the active document is preferred to the one selected in Solution explorer. This project is used in Add/edit link dialog to show the project members.
- CHANGE: Simplified licensing mechanism. The purchased license is not bound to VSdocman major version anymore. The registration key now works with any VSdocman version released before the end of the free update period, which is normally one year after the purchase. In simple words, you'll get free updates for the period of one year. After that time, you can keep using the last updated version forever, because the license is perpetual.
- CHANGE: Sometimes, the command line compilation of documentation was significantly slower than from VSdocman GUI. They are equally fast now.
- FIX: In C#, if a class contained an indexer defined in a shortcut form (e.g. public string this[long id] => "abc";), VSdocman threw an exception during documentation compilation.
- FIX: In VS 2015, if the cursor was inside XML comments of a type (class, enum, ...) and the type had an attribute, the "Comment Editor" operation from the context menu didn't work.
- FIX: Slow Select/Deselect All files on Project Properties pane, Code Members - Files page. With several hundreds of files (e.g. in a web application), it could take several minutes. Now it's a few seconds.
- FIX: If there was no .NET 2.0 or 3.5 installed, the .NET 3.5 installation prompt might be displayed during generation of documentation.