Click or drag to resize

Release Notes

Nimbus 5.0 is a major new release of the product. This topic presents a summary of requirements, key features, and updates, as well as some known issues to be addressed in a future update.

Nimbus 5 Releases
Important note Important

When updating a driver to use a new version of Nimbus, the global.json file should be updated to refer to the latest version of the Nimbus Build Tools. For preview versions, the Nimbus Build Tools version uses SemVer 2.0. For example, for Nimbus version, the Nimbus Build Tools version in the global.json should be updated to 5.0.0-preview.631.

Nimbus Prerequisites
  • Windows 7 or newer (32-bit or 64-bit)

  • Microsoft .NET Framework 4.7 (or newer)

  • Microsoft .NET Framework 3.5

    Tip Tip

    The Microsoft .NET Framework 3.5 is not installed by default on Windows 10 systems. It can be installed via Control Panel -> Programs -> Programs and Features -> Turn Windows features on or off. There, check the box labeled .NET Framework 3.5 (includes .NET 2.0 and 3.0).

  • Microsoft .NET Core SDK 2.2 (or newer)

  • Visual Studio 2017 or Visual Studio 2019

    Any of Community, Professional, or Enterprise editions are supported.

    For Visual Studio 2019, version 16.1 or greater is required.

    For Visual Studio 2017, version 15.9 or greater is required.

    Note Note

    The exact set of Visual Studio components and workloads required is presented in the Visual Studio Extension Manager and automatically installed when the Nimbus package is installed.

  • IVI Shared Componenents 2.6.1 (or newer)

  • IVI.NET Shared Componenents 1.4.1 (or newer)

Key New Features and Updates

Visual Studio 2017 and 2019 Support

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

All New WPF-Based User Interface

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.

Visual Studio Marketplace Distribution

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-Based Refactoring

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.

SDK-Style Projects

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

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.

Nimbus Build Tools as a NuGet Package

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

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.

Online Help

Nimbus help is now provided online at

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.

Honoring the Selected .NET Target Framework

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

IVI.NET Driver Reference Capabilities

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.

Other Changes

  • Important note 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 11/1/2019. 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:

    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):


  • 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\5.0.

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

Known Issues
  • When creating a new driver project, the option to Create a directory for solution must always be chosen. Attempting to manage a Nimbus driver solution with the .sln file inside the driver project folder (or any other Nimbus project folder) could lead to unpredictable results.

    In Visual Studio 2019, the option is expressed as Place solution and project in the same directory. This option should not be checked.

  • When a driver solution is opened, there are a variety of asynchronous operations that Visual Studio performs. One important operation is NuGet restore, which populates the project with all of the critical binaries and targets it needs to operate. If Driver Designer operations are attempted before the NuGet restore completes, then strange errors such as Undefined type Int32 could result.

    In practice, this is rarely an issue, as the NuGet restore typically completes within the first few seconds of opening a solution. You can see the status of the NuGet restore in the Output Window.

  • Multi-selection is not yet supported in any of the Nimbus tree view controls.

  • There is a slight "jump" in the tree view selection in the Driver Designer when adding new items.

  • For IVI.NET drivers that used a custom ConfigStore.xml file to customize the driver's IVI Configuration Store registration process, the only change required is that the file must be included in the project as a <Content> item type. Previous versions of Nimbus would also process the custom ConfigStore.xml file if it was included as a <None> item type.

  • The FxCop-based analysis rules have been removed. Microsoft's new Roslyn-based compiler platform offers a far superior technology for creating code analyzers, including the ability for customers to author analyzers that enforce domain-specific rules on their own drivers. Pacific MindWorks will be migrating to Roslyn-based analyzers in a future release.

  • After re-opening a driver solution, the Nimbus node will sometimes not appear. This often happens, for instance, the first time a solution is re-opened after initial creation. This is caused by Visual Studio corrupting the .suo file. Deleting the the entire .vs folder (after closing Visual Studio) resolves this issue.

    Pacific MindWorks is currently working with the Visual Studio team to avoid this .suo file corruption issue altogether.

  • IVI-COM and IVI-C help and setup projects show "broken reference" annotations (yellow warning triangles) on the icon for their project references to the driver project. These references are required for these projects to operate, and the references are indeed intact, but MSBuild currently has a bug that manifests when any custom SDK-style project references a native (C++) project. The same driver project references appear normal in IVI.NET help and setup projects.

    These warning annotations are benign and can safely be ignored. Pacific MindWorks is working with Microsoft on mitigations for this MSBuild issue.

  • For a fresh machine that has never used Nimbus 5, the initial project creation requires internet access. The Nimbus build system resides in a NuGet package that is hosted on When a Nimbus project is created, the project is typically restored from the locally cached copy of the Nimbus Build Tools. However, in the unlikely event that an offline user has installed the Nimbus Driver Studio Visual Studio extensions, but has never created any project of that version of Nimbus and then attempts the first project creation while offline, then the project creation will fail with a General Exception (E_FAIL).

    Nimbus includes special facilities for handling this exact scenario. However, the NuGet client installed by Visual Studio does not function properly in this scenario. Pacific MindWorks is working with Microsoft on possible mitigations.

    There are two very simple workarounds for this issue:

    1. Always ensure a project has been created on any machine that will use Nimbus offline.

    2. Download the Nimbus Build Tools NuGet package (.nupkg) to the local system before going offline.

  • Merging of IVI.NET repeated capabilities is not currently supported in this release. All other aspects of IVI.NET repeated capabilities are fully implemented in this release.

Nimbus Preview

Issues fixed in Nimbus

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

Nimbus Preview

Issues fixed in Nimbus

  • 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 Preview

What's new in Nimbus

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

Issues fixed in Nimbus

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

Nimbus Preview

Issues fixed in Nimbus

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

Nimbus Preview

Issues fixed in Nimbus

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

Nimbus Preview

Issues fixed in Nimbus

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

Nimbus Preview
Important note Important

This release delivers a single VSIX package that provides support for both Visual Studio 2017 and Visual Studio 2019. To accomplish that, the VSIX ID was necessarily changed and the name of the package appears as simply Nimbus Driver Studio in both Visual Studio 2017 and Visual Studio 2019. Consequently, the previous VSIX extension must be explicitly uninstalled before installing this version.

What's new in Nimbus

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

Issues fixed in Nimbus

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

Download a complete CHM version of this documentation here.