IVI.NET driver installation path standardized?
Hello,
I downloaded and installed some IVI.NET drivers registered on IVI official website, and noticed for different vendors, there are some differences on driver installation. below are some example:
- ·Keysight and NI drivers (32 bits) are installed in <IviNetStandardRootDir> \Framework32\vxxxx\driver name. I can see this comply with the Specification IVI 3-17. But drivers provided by Rohde-Schwarz are installed to C:\Program Files\Rohde-Schwarz, which is not under <IviNetStandardRootDir>.
- ·In Keysight and Rohde-Schwarz drivers directories, there are binary DLLs, samples and source code in the folder, but in National Instrment’s folder, only DLLs are provided, the documentation can be found in other place in C:\Users\Public\Documents\National Instruments.
- ·Keysight drivers DLLs are registered to GAC, but NI and RS driver DLLs are not.
My questions are:
- ·Are the installation directories standardized?
- ·Are the documentation file and their install directories standardized?
- ·Is it mandatory for vendors to register driver DLLs GAC?
We are investigation a feature that load driver and their documentation automatically just from the ConfigurationStore xml file. that's the reason of above concern. hope can get some information here, thanks!
Best Answer
Hi Vincent,
Indeed, the directories all IVI drivers use (IVI-COM, IVI-C, and IVI.NET) are standardized. If you are building tooling, definitely use IVI 3.17 as a reference. If you see that a driver does not comply, then feel free to report it here and the Foundation (which monitors this list) will work with the driver supplier to rectify the issue.
In terms of the variability you are seeing, let me address that. First, the Rohde driver has already been reported as non-compliant, so the IVI Foundation is already working with them to have their drivers updated to comply. You can ignore the variations there.
As for the Keysight and NI driver differences, indeed, IVI.NET drivers are required to be installed in the GAC. But, keep in mind that there are (currently) two GACs -- one for .NET 2.0 and one for .NET 4.0 (runtime versions). IVI.NET drivers may target the .NET 2.0 runtime, as I believe the Keysight drivers do, while the NI drivers probably target the .NET 4.0 runtime. You'll find the .NET 2.0 GAC in c:\windows\assembly and the .NET 4.0 GAC in c:\windows\Microsoft.NET\assembly.
The XML IntelliSense file, which is really the only loadable documentation your tool could use, should be located right next to DLL. My hunch is that both the NI and Keysight drivers are fully compliant, given the above. If you are not observing the same, please do report back.
Thanks for your question.
Thanks a lot for the prompt reply. Hope you can give some suggestions regarding to how to load the assemblies. To use these driver assemblies, one way is to get the type via AssemblyQualifiedClassName retrieved from IviConfigurationStore from GAC, the other way is that we can load the assembly from the DLL located in the install Dir. which is the recommended style?
another small point:
To load type from GAC, AssemblyQualifiedClassName is required right? I noticed in IviConfigurationStore, one Keysight Driver KtIntegraVision, the AssemblyQualifiedClassName is incomplete missing Culture and PublicKeyToken, Is this non-compliant?
<AssemblyQualifiedClassName>Keysight.KtIntegraVision.KtIntegraVision, Keysight.KtIntegraVision.Fx20, Version=1.0.0.0, Culture=, PublicKeyToken=System.Byte[]</AssemblyQualifiedClassName>
Hi,
it is true, that at the moment all Rohde & Schwarz IVI.NET drivers are installed in the
C:\Program Files\Rohde-Schwarz folder.
From this point onwards we are changing all our new installers to be compliant with IVI 3-17.
Regarding the GAC registration, as Kirk mentioned, there are two GAC, Rohde & Schwarz IVI.NET drivers are registered in .NET 4.0 GAC.
Best Regards
Milo Macko, Rohde & Schwarz
Hi Vincent,
That entry is a bug, sadly. It's caused by the Nimbus tool that Keysight uses for their drivers. We've since fixed that bug in Nimbus, so you should not be seeing this in future.
@Vincent - send me your email, and I'll let you know when this issue is fixed - alan_copeland@keysight.com
