Determining if NIFGEN is installed in .NET

[dprice]

I have attached a small C# console app that detects if NIFGEN is installed. It works until the dispose method is called and I get an exception. Our application needs to determine at run-time if NIFGEN is installed and disable all testing related functionality.

Is there a way to force the dispose and capture the exception so no exception dialog is displayed? Is there another method of determining if NIFGEN is installed?

Thanks in advance!
Derek

[Glenn Burnside]

Derek,
This appears to be due to a small bug in the instrument driver wizard, which would only appear in the case that the underlying driver dll failed to load (which just happens to be the case you're testing for...) The call to the init function in the constructor throws the DllNotFoundException, so you never get a reference back to the created object - but there IS still an object being created. That exception is being caught by your program. The uncaught exception, coming from Dispose, is occuring at the end the program when the garbage collector goes through to dispose everything in memory. The exception thrown from the constructor leaves the niFgen object in a bad state, where it has no session handle, but thinks it has not been disposed
yet. The solution is, in your niFgen.cs file, modify the
definition for the _disposed field to read:
"private bool _disposed = true," and then modify the constructors to include a final line that says "_disposed = false;" I am attaching a fixed version of the niFgen.cs file which includes these changes. We will add this to our bug list for the next version of the instrument driver wizard as well.

[dprice]

Thanks for the fast reply *and* solution! I updated the niFgen and niScope files and all is well.

Thanks,
Derek

[Glenn Burnside]

Derek, I was thinking it might be simpler to check for the presence of niFgen by looking for the underlying driver dll, rather than relying on creating a temporary dummy object and then discarding it - for instance, you could look up the installed location of the dll by querying for the registry key "HKLM\Software\National Instruments\NI-FGEN\CurrentVersion\Path". If the registry entry is absent, or the dll doesn't exist at the specified location, it's not installed.

[dprice]

Hi Glenn,

Can I *always* count on that registry location as the definitive test for niFgen, niScope, etc.? Will the next version (or the version after that) of Measurement Studio change and I'll need to re-compile?

Thanks,
Derek

[Glenn Burnside]

Derek,
those registry keys are not tied Measurement Studio - they are part of the NI-FGEN (or scope, or Dmm, or Switch) product. I would expect them to be pretty stable across multiple product updates for the modular instruments. But, if you're worried about being tied to registry keys that might change, you could check for the presence of the dll by calling LoadLibrary on it through a P/Invoke call, and confirming that you get a non-zero HMODULE back.

[dprice]

Hi Glenn,

Is there a "NI Recommended" way? Registry or LoadLibrary or try/catch?

Thanks,
Derek

[Glenn Burnside]

Derek,
I talked with some other folks in the ni-fgen and ni-scope (and other modular instrument) groups, and they agreed that the registry keys could change at a later release (though they deemed it unlikely) They also agree that attempting a LoadLibrary on the driver dll would be a very stable way to determine its presence, even across multiple versions - we can't change the name of the dll without a serious backwards compatibility break.

Of course, your current solution works as well, but I think this might be a simple way to handle it, as there is a lot less exception handling/hiding to be done, and you don't have to worry about unexpected side effects of initializing an instrument driver session.