Unable to load .NET 4.5 assembly in LabVIEW 2013

[DianeS]

Hi all,

Still working on the .NET issue...however, Greg, if you're still following the thread, there is something we can do about the installation window problem.  Please see this thread:

http://forums.ni.com/t5/LabVIEW/How-can-I-inslall-LV-2014-in-Windows-8-1/m-p/3018019#M862596.

The solution there worked for me, so I'm going to pop 2014 onto this machine and see if it'll load the .NET assembly.  It doesn't help with my client situation, but at least we'll have more information as to where the problem is.

d

[Wart]

If that doesn't help I'd be willing to try saving a file for you.  Maybe if we got it started with the correct .NET stuff working then it would keep working when you open it.

[DianeS]

Thanks Wart!  If it comes down to that, I'll take you up on it!  Assuming we can get it to load for you, of course...  🙂

LabVIEW 2014 is installing even as I type, so we'll see what happens...

[rolfk]

Does this .Net component your collegue wrote by any chance have dependencies that he may have installed on his machine (eitehr through the Visual Studio install itself or by another third party installer) and that your machine does not have?

Can your collegue write a small Test application in .Net that loads his assembly so you can try to test that .Net assembly on your machine too? That should help to get a better idea if really LabVIEW is the problem or if it is simply an unsatisfied dependency of your assembly (which would need to be solved by the assembly developer by providing a proper installer that installs the assembly and any needed dependency on a new machine).

[DianeS]

Hi Rolf,

There is indeed such a test application in .NET, and I do have it on this machine, and it runs fine, so there doesn't appear to be a dependencies problem.  It was a very good thought, though, and thanks for chiming in!  I seem to recall seeing your input on .NET threads in the past, so I'm pleased that you've joined this thread.

I've worked with this particular C++ / C# developer for a couple of years and he's written many .NET assemblies for me for use with LabVIEW.  So we both have a fair amount of experience with this kind of thing, and have worked our way through many quirks.  This is the only time we've seen this particular issue.  The assembly is configured for "Any CPU", so it should work with either 32-bit of 64-bit.  This has always worked for us in the past, and according to articles I've read on the subject (sent to me by my NI support engineer, Jonathan), configuring for "Any CPU" should work here as well. 

I'm wondering if the root cause of Hornless Rhino's problem was that he was running a 64-bit assembly with 32-bit LabVIEW.  I don't know, but he said that putting 64-bit LV onto his machine solved the problem, so it seems like that's at least possible.  Anyway, that's a side note.

All of our previous collaboration was done using LabVIEW 2012 on Win7.  I am beginning to suspect that the problem is something with LabVIEW's interaction with Win8.  I myself am not a fan of Win8, and neither is LabVIEW, it appears.  🙂  I installed LV 2014 on my Win8 machine last night, and the assembly still can't load.

I will borrow a Win7 machine this weekend, install LabVIEW 2013 on it, and try to load the assembly.  That should give us the final piece of the puzzle.  If this assembly loads on a Win7 machine with a clean install, then it's something about Win8 that's causing the problem.

Thanks everyone, and please keep tossing out ideas!

[rolfk]

I think I remember something about .Net 4.5 being not directly compatible with .Net 4 but I may misremember something here. While I have been forced in the past to dig into .Net assemblies to call from LabVIEW I do try to avoid .Net whenever possible. Besides that .Net is simply yet another HUUUUGEE framework to install on a computer besides the already overwhelming NI universe framework, it also has the additional drawback of only being usable on Windows alone. Designing an application to use any .Net component is a sure way to paint yourself into the corner where your application will never ever be possible to run on non-Windows systems without major efforts. That may seem like a small drawback to some, but with the ever more prominent RT systems this is getting a real issue.

[DianeS]

I've actually had very good success with .NET assemblies in the past.  They make terrific wrappers for hardware interfaces that are written in C++.  Each language has its own strengths.  I personally like C#, although I am by no means an accomplished C# programmer (I'm just starting to learn it).  LabVIEW works pretty well with .NET once you learn the quirks.

So, like Wart, my .NET 4.5 assembly magically started loading all of a sudden and I'm not sure why.  I did not rebuild the assembly locally.  I did not add it to the GAC.  I did delete the LabVIEW.exe.config file I'd created, then restored it from the Recycle Bin.  Why on earth that would have any effect is beyond me.

I hate Quadrant 3.

For those of you unfamiliar with the quadrant system:

Quadrant 1:  It works, and you know why.

Quadrant 2:  It does not work, and you know why.

Quadrant 3:  It works, and you don't know why.

Quadrant 4:  It doesn't work, and you don't know why.

Quadrant 3 is usually a short, unpredictable step from Quadrant 4...hence, it makes me very nervous.

At any rate, the assembly now loads on my Win8 machine.  Should I gain any further insight, I will post back to this thread.  I know that the conclusion is unsatisfactory.

I should also mention that I did put LabVIEW 2013 onto a Win7 machine and the .NET assembly loaded immediately, with no problems and no config file needed.  So Win8 appears to somehow be the culprit.