10-01-2013 10:58 AM
I have a 3rd party .Net assembly built against .Net 3.5 (CLR v 2.0.50727). I was able to load the assembly in LV 2012, but I can't seem to link to it in LV 2013. I've tried creating a LabVIEW.exe.config file as specified in the LabVIEW help to no avail. When I try browsing to the assembly in LabVIEW, I just get the message "An error occurred trying to load the assembly." Anyone have any suggestions on things to try or ways of diagnosing the problem?
Solved! Go to Solution.
10-02-2013 06:27 PM
Hey, codeman
I'll take a look into your issue with the .NET assembly shortly. If I find anything or have any questions for you I'll post back as soon as I can.
Ryan
10-03-2013 05:31 PM
Codeman,
I've done a little research into your issue with using your 3.5 .NET assembly in LabVIEW 2013. You mentioned making a LabVIEW.exe.config file which I assume you found in this Knowledge Base article: http://digital.ni.com/public.nsf/allkb/4742EB60B64BE22186257BCE0053B8FD?OpenDocument
It's important to remember that name and location are very important when loading a .NET library. If after following that KB article you are still having an issue you might try creating a config file for the specific project that will be using the assembly. Check out this article which is similar to the other: http://zone.ni.com/reference/en-XX/help/371361K-01/lvconcepts/config_net_app/
Beyond that it's possible your 3.5 assembly doesn't handle being promoted to 4.0 assembly very well by LabVIEW 2013. While that's unlikely, there is a way to tell LabVIEW to load the assembly as a specific version using Contrsuctor Nodes. An atricle detailing this process can be found here: http://zone.ni.com/reference/en-XX/help/371361K-01/lvhowto/net_specifying_assembly_version/
Finally, a good article detailing how an assembly is loaded when reference can be found here: http://zone.ni.com/reference/en-XX/help/371361K-01/lvconcepts/loading_assemblies/
3.5 and 4.0 assemblies use a different Common Language Runtime (CLR 2 vs CLR 4) and that could possibly affect the loading procedure which is why you see it work in 2012 vs. 2013. I recommend taking a look into the Knowledge Base articles if you haven't already, and feel free to include any other information about your assembly. I hope some of this information helps.
10-04-2013 08:43 AM
The first KB seems to have done the trick. I'm on Win 7. Apparently after downloading the assemblies from a cloud share, it was necessary for me to "Unblock" the assembly dlls on my local system. Gotta love these new security features. Thanks Ryan.
10-04-2013 11:01 AM
Glad I could help!