Nimbus 5 Release Notes

• Nimbus now supports Visual Studio 2017 and Visual Studio 2019. Visual Studio Community, Professional, and Enterprise are all fully supported with all Nimbus features available.

• Nimbus now supports side-by-side installation. Multiple versions of Nimbus can be installed on a per-Visual Studio basis. For example, you can install Nimbus 4.2 into Visual Studio 2015 on the same computer where you have Nimbus 5 installed into Visual Studio 2017/2019. The same computer may also have multiple Visual Studio 2017/2019 installations. Each of those can house an independent version of Nimbus.

  No additional licenses are required to use multiple versions of Nimbus on the same computer, as long as all product instances are in use by the same person.

The Nimbus user interface has been completely re-written from scratch in WPF. This offers a host of benefits:

• Much better integration with Visual Studio itself. More and more of Visual Studio is WPF-based, so integrators need to use the same platform in order to maintain a seamless, embedded end-user experience with their tooling.

• Theming. Nimbus now dynamically inverts colors to match the currently select Visual Studio themes. Control colors, text, backgrounds, and icons are all tied to the selected theme and use colors native to the official Visual Studio official color palette.

• Scaling and High-DPI Support. Nimbus controls scale with any DPI. All icons and graphics assets are vectorized, themed, scalable, and crisp at all resolutions.

• The overall layout and spacing has been refreshed for usability. There is less dead space and better use of environment window real estate within Visual Studio itself.

Nimbus is now distributed via the Visual Studio Marketplace. This greatly simplifies acquiring and managing Nimbus installations and provides for additional features, such as prerequisite handling and automatic update notifications.

Roslyn is the new compiler platform from Microsoft. The Nimbus roundtripping engine has been completely re-written to use Roslyn to perform surgical code roundtripping that is much more reliable and transactional.

Another important benefit of this migration is that we have full fidelity C# language support in IVI.NET drivers. Previous versions of Nimbus would crash if any project in the solution contained any C# 5.0 (or greater) language syntax. This was a limitation that was becoming increasingly problematic, and the solution is to use the compiler itself as it has full knowledge on the syntax and semantics of code.

With the introduction of MSBuild 15.0 and Visual Studio 2017, Microsoft introduced the notion of a "project SDK", which is a package of binaries, tools, targets, and other assets required to build a project. Applications reference that use an SDK for their fundamental build definition are referred to as SDK-style projects. For example, projects that want to build a desktop application targeting a specific version of the .NET Framework simply declare the SDK and version required, and MSBuild handles all of the acquisition of binaries, injection of targets, and version management.

A fully functional .NET application targeting version 4.5 of the .NET Framework now only requires the following MSBuild code in the project file:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net45</TargetFramework>
  </PropertyGroup>
</Project>

Nimbus uses SDK-style projects for all .NET projects that it generates. This results in a dramatic reduction in the size and complexity of project files. Rather than explicitly referencing source files and other project file items, the project file defines file globs. These file globs allow you to use a simple, but powerful, wildcard syntax for defining the items in a project. A project file, such as the large Nimbus help project files, that would be hundreds of lines long, are often reduced to only a handful of lines.

SDK projects also greatly simplify version management of the Nimbus Build Tools. When a new project is created, or a project is converted, a global.json file is added that specifies the Nimbus Build Tools version.

The Nimbus Build Tools are now provided as a NuGet package on nuget.org.

This greatly simplifies build scenarios, as there is nothing to install and NuGet implicitly supports side-by-side versioning, as well as version range specifications and a host of other features.

Nimbus help is now provided online at docs.pacificmindworks.com/nimbus.

Online documentation allows Pacific MindWorks to provide richer, more up-to-date content quickly, without forcing users to install Nimbus upgrades themselves just to get documentation updates.

In previous versions of Nimbus, the .NET Target Framework was always set to 2.0 for IVI.NET drivers, C# unit tests, and C# and Visual Basic console applications. Changing to a newer version required a set of manual steps on each .NET project in the solution.

Though .NET 2.0 is still officially the "recommended" .NET Target Framework for IVI.NET drivers as per the IVI Foundation specifications, this is expected to change in the near future. This is primarily due to the fact that .NET 2.0 is not installed by default on most modern operating systems. To use a .NET 2.0 driver, end users must navigate to the Control Panel and add the Windows Feature for .NET Framework 3.5 (including .NET 2.0 and 3.0). Consequently, many vendors are already targeting .NET Framework 4.0 or greater.

With this change, Nimbus now creates all of the .NET projects in a new solution according to the selection made in the Framework combo box in the New Project Dialog.

Caution

It is important to pay attention to the setting of the Framework combo box when creating new driver solutions. Visual Studio typically sets that value based on whatever value was previously selected the last time a project was created. Though many users have long expected this behavior because it is consistent with the behavior of all other project system in Visual Studio, some users may have become accustomed to the Nimbus default behavior, which was driven by official IVI recommendations. Thus, users may inadvertently create a driver that targets a higher .NET Framework version than intended.

Previous versions of Nimbus required any assembly referenced by the IVI.NET driver to be loaded in the Global Assembly Cache (GAC). This placed non-trivial limitations on driver developers. With Nimbus 5, IVI.NET drivers support the full range of reference types. Drivers can reference assemblies in the GAC, assemblies on disk, project references, and even NuGet package references. Types defined in assemblies in any of these locations can now be used in the Driver Designer.

Nimbus uses the same facilities within Visual Studio to resolve the set of assemblies an IVI.NET driver references. Consequently, it is no longer necessary to explicitly add an assembly reference using the Driver Designer. Nimbus is able to automatically resolve the name of any type in any assembly referenced by the driver. See the topic Understanding Type Name Resolution in Nimbus for additional details.

• Important
  No additional licenses or serial numbers are required for this release of Nimbus 5. A time-limit license is automatically applied. Customers will need to acquire a new license when the time-limit license expires on 6/1/2020. Pacific MindWorks will be releasing additional details on licensing in that timeframe.

• In previous Nimbus versions, the IVI.NET unit test method names would typically be longer than seemed necessary. For example, a method named Configure with three parameters, might have an associated unit test method that looked like the following:

  C#

  Copy

  [TestMethod]
  public void Configure_Int32_String_Double()
  {
    // ...
  }

  This was done to avoid collisions when such methods were overloaded. Since overloading is actually fairly rare in IVI.NET drivers, this long form of the name is only used when the method is actually overloaded in that interface. Otherwise, the short name Configure is used. Nimbus automatically switches from the long form to the short form (or vice versa) as appropriate when driver methods are modified, copy/pasted, etc.

  The net result is a much cleaner and easier-to-understand set of driver unit tests.

• The version of WiX used to create driver installers has been updated to WiX 3.11

• Nimbus now creates driver solutions that direct their build output to a unified build folder located as a sibling to the other projects in the solution. Intermediate build output is directed to the obj sub folder, with project-specific intermediate output segregated under that folder according to project name. The key project outputs are consolidated under build\<Configuration>\<Platform>, where the <Platform> folder may not exist for Any CPU projects. Consolidating build output under a unified folder greatly simplifies management of build artifacts, installer build operations, and facilitates better incremental build behavior.

  As an example, the folder structure of an IVI.NET driver after a build would look something like the following (not all files or folders shown):

  Acme4302.sln
  Acme4302.design
  global.json
  build
  build\obj\Acme4302Driver\Debug
  build\obj\Acme4302Help\Debug
  build\obj\Acme4302Setup\Debug
  build\obj\Acme4302UnitTest\Debug
  build\obj\Acme4302CsConsoleApplication\Debug\x86
  build\obj\Acme4302IviCDriver\Debug\x86
  build\Debug\Acme.Acme4302.Fx45.dll
  build\Debug\Acme.Acme4302.Fx45.xml
  build\Debug\Acme.Acme4302Version.dll
  build\Debug\Acme.Acme4302Version.dll
  build\Debug\Acme4302UnitTest.dll
  build\Debug\Acme4302.chm
  build\Debug\Acme4302.msha
  build\Debug\Acme4302.cab
  build\Debug\x86\Acme4302CsConsoleApplication.exe
  build\Debug\x86\Acme4302-x86.msi
  build\Debug\x64\Acme4302-x64.msi
  

• Nimbus now provides a single editor for modifying all of the driver's repeated capabilities. This new editor can be found on the Repeated Capabilities tab of the Driver Settings Editor editor. Previous versions of Nimbus displayed individual repeated capabilities under the Nimbus node in Solution Explorer, and a combination of gestures would take you from Solution Explorer to the Properties Window to a dialog window.

  The new Repeated Capabilities Editor makes it much easier to view and edit driver repeated capabilities.

• Nimbus generates a global.json file as part of a new driver solution. This file must be maintained in source control alongside the .sln and .design files. It specifies the version of the Nimbus Build Tools to use to build the driver.

  Use of the global.json allows the Nimbus Build Tools version to be different than the Nimbus version used to create the driver (as specified by the <NimbusVersion> element in the .design file and in various project files). Previous versions of Nimbus always required these versions to exactly match. With Nimbus 5, certain categories of fixes and updates can be quickly introduced into the build tools without requiring a new install of Nimbus itself. And, since the Nimbus Build Tools are delivered via NuGet, there is nothing to install. Indeed, no explicit action is required on the part of the user to consume such updates. The global.json is used to opt-in (or out) of version updates.

  The global.json file even has the ability to control an entire set of drivers arranged in a folder hierarchy on disk.

• Because Nimbus now installs as a VSIX package on a per-Visual Studio basis, it can no longer use the <ProgramFiles> folder to deploy the instrument class files (.iviproj) or the help template files. Instead, the instrument class files are and custom help templates are now deployed to <ProgramData>\Pacific MindWorks\Nimbus\<version>.

  Note

  In previous versions of Nimbus, the pre-built help templates were installed in the same folder as the custom help templates. Now, the <ProgramData> folder houses only custom help templates that the user defines. The pre-built templates installed with Nimbus must necessarily reside in the per-Visual Studio Extensions folder. To locate the pre-built help templates for purposes of creating custom help templates, navigate to the folowing folder: <ProgramFiles32>\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\Extensions There you will see a series of seemingly random folder names. Search for "MindWork.Nimbus.Core". This will take you to the Extensions folder that houses the Nimbus Visual Studio extension. The HelpTemplates folder is located in this folder.

• Nimbus driver help projects no longer support MSHelp 2. This help format targets Visual Studio 2005 and Visual Studio 2008, neither of which are supported any longer by Microsoft.

• Nimbus driver help projects no longer support MS Help Viewer 1.0. This version of the Help Viewer only services Visual Studio 2010 prior to Service Pack 1. All versions of the Help Viewer from Visual Studio 2010 with Service Pack 1 to Visual Studio 2019 are fully supported. Only Visual Studio 2010 users without Service Pack 1 installing a driver would be affected, and the mitigation would be to simply apply the Service Pack 1 upgrade.

• The driver help template that ships with Nimbus has been renamed from "VS2005" to "Classic".

• The Help Viewer content manifest file (.msha) was previously required by the Help Viewer to be named HelpContentSetup.msha. That restriction no longer exists, so Nimbus names this file <driverName>.msha.

• Previous versions of Nimbus used C++/CLI unit test projects. Nimbus 5 deprecates this style of unit test projects in favor of the newer and more robust native C++ unit test framework in Visual Studio. Nimbus IVI-C drivers have always used the native unit testing framework, and IVI-COM unit tests now use this same framework.

  Importantly, existing C++/CLI unit test projects remain fully supported. They will be roundtripped in an existing driver solution just as with previous versions of Nimbus. However, the New Project Wizard always creates native C++ unit tests for IVI-COM drivers. There is no longer a facility for creating C++/CLI unit tests.

  Pacific MindWorks has not established a timeline for obsolescence of C++/CLI unit tests, but all customers are encouraged to migrate to native C++ unit tests.

• Nimbus now includes embedded editors for directly editing implementation code as well as test code -- all from within the driver designer. New Code item editors and Test item editors host the native Visual Studio core editor and functions just as the standard non-embedded editors. All edits are automatically kept in sync with the underlying project source code.

  Editor for Implementation

  
  Editor for Unit Test

  

• Nimbus now implements a Visual Studio CodeLens provider that surfaces navigation commands directly within the Visual Studio code editor. The current release allows direct navigation to the Driver Designer, implementation code, and unit test code.

  Nimbus CodeLens Provider

  
  Nimbus CodeLens Navigation Commands

  

  Important
  The Nimbus CodeLens feature is only available in Visual Studio 2019. The Microsoft infrastructure for CodeLens for Visual Studio 2017 has a major design flaw that prevents extensions from supplying CodeLens customizations.

  Note
  The Nimbus CodeLens provider can be disabled separately for C# and C++ code files in the Tools -> Options settings under Nimbus Driver Studio.

• In addition to navigation using the CodeLens provider, Nimbus provides the same set of navigation commands directly from the code editor context menu. Simply right-click within a method implementation, a header file, a unit test method, or even from within an IDL file.

  Context Menu Navigation from a Driver Method

  
  Context Menu Navigation from a Unit Test

  

• The MSBuild Imports tree is now displayed for Nimbus help and setup projects when the Show All Files toggle button is enabled in Solution Explorer. The Imports tree is very useful in understanding the detailed structure of a project's build settings.

  Imports Tree

  

• Navigation from the Driver Designer to C++ code elements properly centers the desired code in the code editor. The name of the code element is also highlight for quick identification.

• Fix a build error that would occur in IVI.NET drivers when using repeated capability ranges.

• The .design file is no longer shown unless Show All Files is selected.

• The Models Selector is no longer shown by default, since most operations are not model-specific.

• Fix a bug where the previously selected item editor was not being restored after closing and then re-opening the driver designer.

• Fix a null reference exception that could occur in IVI.NET drivers in some circumstances when adding members directly to an interface instead of to the hierarchy.

• Don't throw an exception when marking a second instrument family as not being supported by a particular IVI.NET type member.

• Update licensing infrastructure for 2021.

• Fix a bug in IVI-COM drivers where the DriverSetup string could get wiped out when initializing with a logical name.

• Ensure that IVI.NET drivers update properly when the driver version is changed.

• Implement a workaround for a breaking change in the Roslyn parser introduced with Roslyn 3.7.0 and Visual Studio 16.7.X.

• Prevent invalid repeated capabilities from being added at any level beneath a repeated capability collection interface.

• Add virtual destructors to NRT DriverSession and IoSession to avoid potential memory leaks.

• Fix a null reference exception that would occur when using Navigate to All without a driver project document being active.

• Fix a bug in the setup designer whereby assemblies added to the GAC would not always include the correct attributes and would not always be in their own Component element.

• Fix a bug in NRT where all-numeric repcap identifiers were not being accepted.

• Update policy files when the driver version changes.

• Update the IVI-COM setup project appropriately when an instrument class is added or removed.

• Update the IVI-COM setup project appropriately when a class, interface, or enum is added, removed, or renamed.

• Fix a bug in the setup project properties where the DistributeDriverSource property would be persisted with the wrong casing.

• Fix a bug where the Nimbus node would not appear if all Nimbus projects were placed beneath a solution folder.

• Remove an unnecessary .bak file from the IVI-COM help template.

• Fix a crash that could occur when switching IVI-COM help projects to the "Classic" help template.

• Add more project type tags to the New Project Dialog to improve search within that dialog.

• Don't thrown an exception when creating an IVI-COM driver if no IVI-C prefix is specified and no IVI-C wrapper is desired.

• Fix driver designer navigation from IVI-C to IVI.NET when repeated capabilities are involved.

• Fix a deadlock in VS2017 when converting certain versions of IVI.NET drivers.

• Workaround an issue with Visual Studio project loading in VS2017 project loading where C# projects would not load properly immediately after creating an IVI-COM solution.

• Enable correct source control support when using TFVC source control.

• Fix a bug in the IVI-COM setup project targets where interop assembly policy files would not always get included after conversion.

• Automatically show scroll bars in the settings editor if the visible area does not show all of the controls.

• Generate a unique Id for IVI.NET enum members when copy/pasting.

• Refresh the driver designer when an exception is pasted.

• Fix exceptions that are thrown when creating IVI.NET driver solutions with setup projects included.

• Generate unit tests for IVI.NET classes (and other types) that are pasted.

• Fix a bug where copy/pasting an IVI.NET property immediately after creating it would not always create the associated IVI-C attribute.

• Don't produce a build error in the help and setup projects if a driver project references another driver project, such as IVI.NET wrapping IVI-C.

• Add mergemod.cub to the build tools NuGet package to enable building merge modules.

• Fix a bug in the user login dialog where the dialog could be shown with a white title bar and reduced visibility of error messages. This fix also addresses the issue with the dialog not being closeable from the Cancel button or Close button.

• Fix a bug in the Nimbus converter where IVI-COM help projects templates were not getting updated with all IVI-C help template files requierd to build in some scenarios.

• Fix a bug where the prefix.nimbus.cpp file would not always be up-to-date immediately after changing an IVI-COM property type.

• The licensing system used by Nimbus is completely new. Nimbus licensing now relies upon user credentials to validate a license rather than serial numbers tied to specific machines. Serial numbers are no longer used at all starting with Nimbus 5.1. This model closely mimics the licensing and validation scheme used by Visual Studio itself, and Pacific MindWorks consulted with the Visual Studio team to align our methodology with that used by Visual Studio to ensure a frictionless experience for our users.

  When using Nimbus for the first time on a machine, you will be prompted for the email and password associated with your Pacific MindWorks online account. Our secure server will validate your credentials and license entitlements automatically. Typically, this will be done only once for a particular machine.

  As a consequence of this new user-based licensing mechanism, there is no "activate" or "deactivate" functionality, as that feature was linked to the use of serial numbers. Users can simply log on to their account on a different machine to enable usage of Nimbus on that machine for that user. As long as it is the same user working with Nimbus, usage across machines is allowed.

• Nimbus now provides the ability to automatically generate IVI-C getter and setter functions for each IVI-C driver attribute. These functions are automatically implemented by Nimbus and updated as the definition of the associated IVI-C attribute changes.

  IVI-C getter and setter functions greatly simplify usage of IVI-C drivers relative to the traditional technique of using the attribute accessors, such as GetAttributeViReal64.

  See the topic Adding Attribute Getter and Setter Functions for details.

• Nimbus now supports IVI-C callback functions as defined in the IVI specifications.

  See the topic Adding Callback Functions for additional details.

  Important
  For drivers that use IVI-C callback functions, the driver help template must be updated to the latest Classic help template that ships with Nimbus. The updated help templates include the required template files for generating help content for IVI-C callback functions.

• Nimbus now generates the IVI-C driver header file (<prefix>.h) based on a new Nimbus text template (.ntt) file. This provides a simple and flexible mechanism for customizing the contents of the IVI-C driver header. For example, additional include files or custom macro definitions can be added to the driver header file without disrupting any of the standard auto-generated code Nimbus produces.

  See the topic Customizing the Driver Header File for additional details.

• IVI-COM help templates that include an IVI-C wrapper now use template files from the IVI-C template for portions of the driver help file. This eliminates a large amount of duplication, as separate sets of IVI-C content templates prevously needed to be maintained for IVI-COM and IVI-C even though the content (and, hence, the desired customizations) would necessarily be the same.

  The following folders within the IVI-C template are used by the IVI-COM help template:

  • IviCAttribute

  • IviCBranch

  • IviCCallbackFunction

  • IviCErrorsWarnings

  • IviCFunction

  • IviCLibrary

• The Driver Designer now includes a search box for searching and filtering items in the design. You can quickly navigate to the search box by typing CTRL+E.

  See the topic Using the Nimbus Driver Designer for additional details.

• Nimbus now integrates directly with the native Visual Studio "Go To All" feature. By typing CTRL+, or CTRL+t, the Visual Studio "Go To All" dialog appears. In addition to locating standard Visual Studio files, classes, and other items, you can now navigate directly to a driver method, property, enum, or other item.

  See the topic Using the Nimbus Driver Designer for additional details.

• When adding enums, the enum and its members can be defined all at once. Similarly, multiple enum members can be added all at once to an existing enum.

  See the topic Adding an Enumeration for details.

• Enums can be created inline when editing property types, parameter types, and return value types.

  See the topic Defining New Data Types Inline for details.

• Enum members can now be added from the enum member context menu, instead of only from the parent enum context menu.

• The Driver Designer now allows the numeric values for enum members to be entered in hexadecimal format. It also allows displaying members in either hexadecimal or decimal format, independently of how the values are entered.

• The tree view control used throughout Nimbus previously only supported single selection. This release of Nimbus includes a completely re-written tree control with expanded capabilities, such as search, filtering, and, crucially, multi-selection.

• The help project properties page and Tools -> Options pages now include a Browse button for locating a certificate for signing Help Viewer content.

• Double-clicking an item in the Driver Designer now navigates to the definition or declaration of the item.

• Keyboard navigation within the Driver Designer has been improved to facilitate more efficient editing of driver designs.

  See the section Keyboard Navigation for details.

• Nimbus now validates that the minimum IVI and IVI.NET Shared Components are installed.

• The required Introduction.rtf is now generated and integrated with newly created setup projects.

• Renaming of IVI.NET drivers is now supported.

• When a driver solution is upgraded, the Nimbus converter automatically updates the global.json to refer to the appropriate version of the Nimbus Build Tools NuGet package.

• Scrolling through tree nodes in the Driver Designer is notably faster.

• Fix IntelliSense in the embedded HTML help editor in Visual Studio 2019.

• Sort overloaded IVI.NET method nodes with lower-parameter-count methods first.

• Rename IVI-C repcap identifier parameters when a repcap is renamed.

• Create IVI-C repcap identifier parameters according to the convention <repcapName>Name.

• Auto-correct IVI-C parameter label editing to ensure Pascal casing rather than reporting an error.

• Don't throw an exception in the IVI-C options editor if IVI-C is not enabled on an IVI-COM or IVI-NET driver project.

• Sort enum members by value in the Driver Designer, the header file (for IVI-C), and the generated help content.

• Don't throw an exception when renaming an IVI-C attribute to an attribute name that already exists.

• Update the IVI-COM and IVI-C parameter info panels when a new parameter is added.

• Don't show delete and rename commands for IVI-C container nodes in the Driver Designer.

• Newly created drivers can now be re-opened without having to delete the .vs folder.

• Sign IVI.NET drivers with a strong name by default.

• Refresh Driver Designer tree node labels when an enum is renamed.

• Allow IVI-C-only enum members to be added to enums in an IVI-COM driver with an IVI-C wrapper.

• Remove #pragma once from .cpp files in IVI-COM and IVI-C drivers.

• Change casing of include files in IVI-COM and IVI-C drivers to match actual casing of file on disk.

• Fix bug in Nrt.h where some statically declared local variables incorrectly established the value for all subsequent calls.

• Show the driver "Source" folder in the 64-bit hierarchy within the setup designer.

• Fix issue where property pages windows persisted via the .suo file would sometimes display an error when initially opened.

• Qualify the setup editor document window title with "IVI.NET" or "IVI-C" for IVI.NET drivers with a linked IVI-C driver.

• Enable adding a linked IVI-C driver to an IVI.NET driver after initial creation of the solution.

• Initialize linked IVI-C driver in new project wizard with IVI.NET or IVI-COM instrument class.

• Don't throw an exception when changing an indexer type.

• Allow changing the access (read-only, write-only, read-write) of indexers.

• Create linked IVI-C attributes when pasting IVI.NET and IVI-COM properties.

• Fixed project converter deadlock.

• Extended time limit for licensing to 6/1/2020.

• Fixed bug where duplicate IVI.NET assemby references could get added to a project leading to methods and properties with unresolvable types.

• Updated assembly version for IVI-defined assemblies to 1.4.0.0.

• Extended time limit for licensing to 6/2/2020.

• Fixed bug where duplicate IVI.NET assemby references could get added to a project leading to methods and properties with unresolvable types.

• Updated assembly version for IVI-defined assemblies to 1.4.0.0.

• Use a 3-digit version number for the VSIX version in public releases.

• Fix some bugs in IVI-C enum member editing.

• Don't throw an exception when a help project is added to an existing driver..

• Fix a broken link on the IVI-C driver help page for "inherent capabilities"..

• Fix some minor spacing issues in the standardized help summaries.

• Fix a broken link to the IVI Shared Components page on the IVI Foundation web site.

• Don't allow collection-style repcaps in the "Add Repeated Capability" dialog in IVI-C-only drivers.

• Change the help summary of IVI-C session parameters so that they use the actual IVI-C prefix in the name of the init and InitWithOptions functions.

• Don't throw an exception when renaming IVI.NET enums from the tree view.

• Don't throw an exception when re-naming an IVI.NET free-standing interface with a unit test project is in the solution.

• Don't show "IVI-C: None" in the info panel when there is no IVI-C driver or wrapper linked to the IVI.NET and IVI-COM driver.

• Don't throw an exception if a struct is deleted and there is no unit test for it.

• Don't generate unit tests for structs.

• Don't show a warning for incompatible IVI-C types when adding an IVI.NET method if there is no linked IVI-C driver.

• Fix bug in IVI.NET paste where some operations would leave the source and target members sharing the same implementation data.

• Show IVI.NET parameters as grayed out if the parent method has a read-only signature.

• Introduce a text box style for instrument commands and responses so that they are more legible when an error is shown.

• Update the driver help page on building source to say that .NET 4.7.2 is installed.

• Fix a bug in the help editor focus handling that would cause the wrong tree node content to get updated on edit.

• Make help content validation tasks display interface name instead of class name.

• Make IVI.NET "Instrument Command Reference" page use interface name and not class name.

• Fix a bug whereby changing the help editor tab does not always preserve the content entered in the previous tab.

• Ensure that at least one help editor tab is selected when changing selection in the Driver Designer tree view.

• Don't throw an exception when adding parameters that are arrays or pointers of generic types.

• Don't throw exceptions when adding IVI.NET driver constructors.

• Allow constructors to be deleted.

• Refresh the Driver Designer when IVI.NET constructors are deleted.

• Refresh IVI.NET method and parameter labels in the Driver Designer when a generic parameter is renamed.

• Rename IVI.NET unit test file and class when a generic type parameter is renamed.

• Refresh Driver Designer class, exception, interface, and struct container nodes when a type is added or removed.

• Don't allow circular base interface references in IVI.NET Driver Designer.

• Don't throw an exception when adding a base interface after a previous add base interface operation was cancelled.

• Don't throw an exception when adding a base interface to an IVI.NET struct.

• Remove the base types node when the last base interface of a type is removed.

• Don't throw an exception when a generic base interface was removed and then re-added to another generic interface.

• Don't throw an exception when adding unit tests for new base interface methods that are overloaded.

• Show expansion arrow for indexers in the Driver Designer.

• Sort IVI.NET interface reference property child nodes using the same logic as other type member containers (e.g. the Hierarchy node).

• Don't allow copying inherent capabilities in the Driver Designer.

• Don't allow duplicate repcap management methods and properties to be pasted.

• Extended time-limit license to expire on 2/1/2020.

• Updated NCL to use some of the newer C# language features.

  Note
  This change may require a change to your IVI.NET driver project properties to set the C# language version used by the compiler. If the <LangVersion> property has not be directly set in the driver project file, then the Nimbus build tools will specify a value of latest. IVI.NET drivers currently require C# 7.2 or greater to build.

• Disable IVI-C state caching, range checking, and simulation editors when the IVI-C attribute or function is linked to IVI.NET.

• Update IVI.NET editor so that IVI-C attribute display names have spaces.

• Update enabled state of IVI.NET enum member editor Response field whenever Command field changes.

• Update NCL so that the default model is used in simulation mode if no Model option is specified.

• Help and setup project property pages fail to load if opened before the Driver Designer or settings editor.

• Nimbus fails to load on non-English versions of Windows.

• Help project fails to build after switching help templates.

• Driver conversion fails of .sln file is not in the same folder as the .design file.

• Arrays are displayed with an extra set of brackets in the info panel.

• Output and reference parameters are not persisted properly when typed into the Driver Designer as a single line in the tree view.

• Instrument models that start with numerics are not allowed.

• Roundtripping operations fail if the Driver Designer or settings editor is opened, closed, and then re-opened within a single Visual Studio session.

• Nimbus can now convert driver solutions created with Nimbus version 2.0.10 and later.

• Driver settings designer window appears blank when opening some projects.

• Driver converter fails if the .design file is not located in the same folder as the driver solution file.

• Help project crashes if it contains an item with a None MSBuild item type.

• Converted setup project references Help Viewer manifest file without the .msha file extension.

• Setup project converter does not remove policy files, which are now included via the file globs in the setup targets file.

• Update the ToolsVersion in the IVI-C unit tests to be 15.0.

• Settings editor crashes if an instrument family or model is edited and a non-valid C# identifier is used.

• Refresh the capabilities group editor when adding/removing instrument classes or changing LXI settings.

• Updating the help template in the help project properties is slow.

• Applying a new IVI.NET help template mistakenly copies over the IVI-COM help template.

• Nimbus throws exceptions for IVI.NET solutions where the linked IVI-C driver project appears before the IVI.NET driver project in the solution file.

• Adding new IVI.NET enum members sometimes throws an exception.

• Setup project converter does not update occurrences of HelpContentSetup.msha in the Common.wxs file.

• Remove usage of undefined VCUnitTestDir MSBuild property in the IVI-C unit test project file.

• Fix bug in the setup targets that would case IVI-C wrapper files to not be deployed.

• Adding an IVI.NET method with out or ref parameters does not retain the parameter direction.

• Don't show "Add Constructor" command on reference properties.

• Update the DriverVersion MSBuild property when changing the driver version in the driver settings editor.

• Refresh the IVI.NET info panel when linked IVI-C items are deleted.

• An incorrect data type is used in the LXI GetNextEventLogEntry IVI-C unit test.

• Nimbus crashes when using whitespace in an instrument family or model name.

• Don't add the .design file as a project item to the IVI-C driver project when the IVI-C driver is linked to IVI.NET.

• Converting Nimbus 4 IVI.NET drivers that don't have a linked IVI-C driver throws an exception.

• Adding an instrument class to an IVI-COM solution with a unit test fails.

• The TargetFramework of IVI.NET help and setup projects does not match the value in the driver project.

• Don't require the .design file to be located in the same folder as the .sln file.

• Specify the -restore flag for msbuild.exe in the driver boilerplate help when explaining how to build driver source code in end-user systems.

• The setup designer opens when any file in the setup project is double-clicked.

• The help project would sometimes fail to build due to the .msha file being missing from the obj folder.

• The return value field does not appear in the help editor.

• Some custom fields do not appear in the help editor.

• Linked IVI-C functions and attributes do not display the correct implementation style in the Implementation Style combo box.

• IVI-C files in a linked IVI-C driver are not regenerated when the Regenerate Files command is executed on the master IVI.NET driver.

• IVI-C enum command maps do not include both the SCPI long and short form of the associated commands.

• Changing an IVI.NET method response can result in the associated command being updated instead.

• Don't delete the implementation of IEnumerable.GetEnumerator in NCL when removing the instrument-specific clone of a class-compliant repeated capability.

• Don't show the Remarks tab in the help editor for items to which it does not apply.

• Linked IVI-C attributes are not created for IVI.NET properties when a project is initially created.

• Renaming an IVI.NET property from the item editor does not work.

• Exception is thrown in "Go To Unit Test" command if a unit test project is not present in the solution.

• Warning dialog claiming the implementation code has changed is mistakenly shown when changing the implementation type.

• Don't show Create IVI-C property commands on IVI-COM and IVI.NET properties when no IVI-C driver is present.

• Adding or removing a repeated capability physical name throws an error when an IVI.NET unit test is present in the solution.

• Support for Visual Studio 2019 has been added.

• Nimbus now appears in the Project Type combo box in the Visual Studio 2019 New Project Dialog.

• The number of prerequisite Visual Studio components has been reduced.

• Updated Setup Designer to offer context menu commands from the tree view or the list view.

• The ItemDefinitionGroups defined in IVI-COM and IVI-C targets could not be overridden as easily as in previous Nimbus versions.

• Linked IVI-C enums do not show up in the IVI.NET enum info panel.

• Source files should not automatically be opened when a new driver solution is created.

• Disable the Paste menu command when the clipboard contains data from a different Nimbus project.

• Incorrect TargetFrameworkVersion is stored in the .design file when creating new driver solutions.

• View Help command does not work when changing between different solution configurations.

• IVI-C help and setup output files overwrite IVI.NET output files if linked and the project name matches the IVI-C prefix.

• The Go To IVI.NET commands do not work when executed from the IVI-C designer.

• Don't add the {value} tag to the instrumment response of a method if the return type is not compatible with automatic command formatting.

• Help editor displays summary information for the previously selected item.

• Renaming an IVI.NET property with a linked IVI-C attribute fails.

• Changing an IVI.NET property access does not always round-trip the implementation code properly.

• Don't attempt to add a unit test when adding a property to a free-standing interface.

• All unit test classes associated with an instrument class are not removed when removing support from an instrument class.

• Rename repeated capability fails if the ActiveXXX property is displayed when the rename is performed.

• Renaming the IVI-C prefix in an IVI.NET or IVI-COM driver project does not rename all functions in the <prefix>.cpp file.

• IVI-COM indexers do not display the Name parameter.