Unable to load DLL nianlys.dll after upgrading Measurement studio support for Visual Studio 2017

[aounmc]

I can confirm that using the older (MS2015) merge modules does work with MS2019. And if NI does not provide a solution, that will be what I'll go with for now. I think it is unlikely that installing MS2019 on a clean machine would cause the merge modules to be installed on the machine whereas they aren't when the machine is "not clean". But I suppose I have seen stranger things than that happen over the years. I am not able to wipe my machine at this point and try this idea at this time, especially since I think the likelihood of it making a difference is very low.

I'm sure that you find it as frustrating as I do that whoever you talk to at NI keeps simply typing keywords into the database and then blindly suggesting the administrator privileges/blaspak thing. Hopefully, this thread will cause some additional hits that will help future support engineers to be able to think more broadly than that. Thanks for starting the thread.

[BabaGoud]

Thank you for confirming that "using the older (MS2015) merge modules does work with MS2019", that sends a bit of confidence in our team to upgrade to MS2019. I truly understand your frustration :), our whole project deadlines were getting messed up due to the DLL issues. I hope with MS2019 things would be better.

[aounmc]

I just installed Measurement Studio 2019 on a completely clean install of Windows 10 x64. I can confirm that the NI suggestion to you of installing Measurement Studio 2019 on a clean install of Windows 10 DOES NOT INSTALL THE MISSING MERGE MODULES (nianlys.msm and nianlys_x64.msm) REQUIRED TO DISTRIBUTE A VISUAL STUDIO APPLICATION THAT USES THE MEASUREMENT STUDIO ANALYSIS LIBRARY.

Still no response from NI on this.

[aounmc]

By the way, in the interest of full disclosure, I found years ago when I first became aware of the fact that that I needed to manually add nianlys.msm in my setup project, I also became aware that wasn't the full extent of what was required. nianlys.msm (and _x64 version) have dependencies of some cryptic thing called mkl.1AB9A...(a bunch of cryptic characters follow) and nimetautils.msm. So when things still didn't work by adding the nianlys.msm merge module I noticed there was a mkl.msm in the directory as well. So I tried adding that to my setup project. After adding both of these the error loading nianlys.dll message went away. It is still the case now that mkl.msm (or mkl64.msm, as appropriate) needs to be added to the project. Not surprisingly, Measurement Studio 2019 also fails to install the MKL merge modules in the common files/merge modules directory. So I had to also grab that from my Measurement Studio 2015 installation. There are apparently other pieces of software that will install the MKL files as well (for example NI-VISA seems to do it), so depending on what else you are installing you may not need it. nimetautils.msm is automatically detected and added to my project, so I didn't need to include it (and incidentally Measurement Studio does in fact install this merge module along with some others).

So I'm still waiting on someone from NI to let me know how they plan on getting the required merge modules to their customers.

[RandallCrandall'sCandleHandle]

Hi Michael,

The reason that you're not seeing the merge modules is MStudio no longer ships them as of 2019. This is outlined in the MStudio 2019 Behavior Changes document.

That being said, here are a couple of alternatives to using merge modules:

1. Use NI's MSI runtime installers. The table in that help topic lists the ones to include. The installers themselves can normally be found at C:\ProgramData\NationalInstruments\MDF\ProductCache.
2. Simply XCopy the required .NET assemblies with your installer. I'm not sure if the setup project will support directly copying assemblies, but if it does, the table in that help topic will show you which ones to copy.

The other alternatives to this would require using an NI deployment technology instead of a setup project. The options here are MStudio Installer Builder or NI Package Builder.

I hope this helps you out, and please let me know if you run into issues with either of the approaches above.

Cheers,

Ryan Curtis

Product Support Engineer

Automated Test Software R&D

[aounmc]

Thanks for the "required .NET assemblies" document...  some information I can use! A very useful document that I didn't know existed. I will copy the files myself (now that I know what they are). 

Thanks!

[aounmc]

Ryan (Curtis),

Do you know why version 19.0.45.2 of the NationalInstruments.DAQmx.dll assembly has a dependency on version 17.5.40.49153 of NationalInstruments.Common? This causes the mstudiocommon.2010.msm merge module to be automatically detected and added to my setup project (instead of mstudiocommon.2013.msm). There is already an automatically detected dependency of version 19.0.40.49152 of NationalInstruments.Common.dll added to my setup project. Why doesn't version 19.x of the DAQmx assembly depend on the 19.x version of Common? Having both dependencies to the 17.x version and the 19.x version is somewhat problematic.

Thanks,

Mike

[RandallCrandall'sCandleHandle]

Hey Michael,

Some of our software/drivers depend on different versions of NationalInstruments.Common, so I would think that is the reason (although I'm not exactly sure what to expect for DAQmx). To make everything work with the same version of Common, you can use assembly redirection to make DAQmx work with the newer version.

The XCOPY document above mentions your problem:

However, if you XCOPY an application without a configuration file and the assemblies included in the application were built with an older version of NationalInstruments.Common.dll, deployment does not work. 

---

I haven't tried this, but I am pretty sure if you add an app.config file that redirects oldVersion 17.5.40.49153 to newVersion 19.0.40.49152, DAQmx will use the newVersion with no problems. There are some examples of that in the XCOPY document as well.

Let me know if that works correctly, and I can take a second look if I overlooked something.

Cheers,

Ryan Curtis

Product Support Engineer

Automated Test Software R&D

[aounmc]

I already have manually included the 19.x version of common and I have already set the project to automatically create binding redirects to the newer assemblies. Furthermore, I have excluded the auto detected 17.x version of common from my deployment project. However, the file keeps being automatically un-excluded. So I'm concerned that I may end up with the older version of common installed on the machine instead of the newer appropriate version. I'll just have to be diligent and make sure it is excluded every time I rebuild. I suspect that it is due to an oversight that the 19.x versions of DAQmx are somehow referencing the 17.x version of common (especially since it works with the 19.x version of common). Thanks.