.NET constructors don't show up in LV 8.5

[JonathanN]

Hi Rich,

Its probably best if I get our web suppor team to give me your contact information and then I can email you off-line. I just need your permission.

Thanks

Best Regards,

[samwarr12]

Yes, feel free.  I called earlier today with request #7171174.  

To make matters worse I recently purchased Base 8.5 and App builder for 8.5 but I can't use either until I figure out the .NET problem.  I'm getting a lot of heat from mgmt so any help would be GREATLY appreciated!

[samwarr12]

Just a post to the world to share the final solution. After several exchanged with Jonathan he sent this email:

Hmmmm....... I noticed from your screenshots that you had your files stored on a Z:\ drive. Is that a network drive? (Yes, it was)

You may already now this but .NET provides several layers of security for .NET applications. One of these layers is very similiar to the Zone concept in IE.  When an assembly is loaded into .NET, where the file came from is very important. If it's loaded from the local disk, it's assumed to be fully trusted. However, if it comes from the network (even a mapped drive), it isn't. Thus you need to increase the asembly trust.

To increase the assembly trust in WindowsXP:
1.        Run the .NET Framework Configuration Utility "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorcfg.msc" (Or just go to Control Panel >> Administrative Tools >> Microsoft .NET Framework 2.0 Configuration)
2.        Expand My Computer, right-click Runtime Security Policy and select Trust Assembly...
3.        Select Make changes to this computer
4.        Enter the path to the assembly on the network drive
5.        Grant Full Trust
6.        Select Finish

Its actually better to do grant trust to specific zones by right-clicking RUntime Secuirty Policy and selecting Adjust Security. Then choose Full Trust for the necessary zones.

There is a handy little tool that ships with the .NET framework called caspol.exe. This creates security policy settings that tell .NET to consider a given network drive to have full trust. For example, since your code is on the Z: drive, you can add it to the trusted list by the following command:

caspol -q -machine -addgroup 1 -url file://z:/* FullTrust -name "Z Drive"

He also iterated that All of the assemblies need to be in the same directory as the project or subdirectory unless they are stored in the GAC.

After moving all my assemblies and builds to a local drive I was able to to get everything running.

[JonathanN]

Check out Microsoft's guide to the .NET Framework Configuration Tool. This site discusses the tool as well as assembly trust.  If you don't have this tool, make sure you have installed the .NET Framework SDK.

Best Regards,

[remywizard]

I still have the problem.  If I have the, lvproj file in a couple directories above where the dll and vis are then it wont load the constructors.  But if I put the ,lvproj file in the same directory that the other dlls and vis are in then it will load the constructors.

This is all on the local drive too.

[JonathanN]

Hi remenakb,

In this case it helps to understand how the .NET CLR actually finds the requested assemblies. I could go into detail, but I would rather have Microsoft explain it to you. See the topic How the Runtime Locates Assemblies and then particularly the probing section (explains how the .NET CLR probes for assemblies using its heuristic chain).

Basically, you are putting the .NET assemblies in locations that the .NET CLR doesn't probe and thus it can't load the needed assemblies. This in turn doesn't allow LabVIEW to load the assemblies for reflection.

To resolve this issue, you need to help out the CLR by providing a configuration file that uses the privatePath attribute. This privatePath attribute allows the .NET CLR to search user-defined lists of subdirectories under the root location (in this case the root location is the LabVIEW project directory). In your case, you would set the attribute to your subdirectories.

So you would create a project configuration file named MyApp.lvproj.config (where MyApp is the name of your project) and put that configuration file in the same directory as the actual lvproj file. Then you would edit that file in some text-editor and put the syntax

<configuration>
    <runtime>
       <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <probing privatePath="bin;bin2\subbin;bin3"/>
       </assemblyBinding>
     </runtime>
</configuration>

Then close and re-open your LabVIEW project so that it can use the configuration file. You should now be able to open a VI that uses your .NET assemblies. You should also be able to browse for public constructors via the .NET Constructor Node.

Hope this helps!

Best Regards,

[Stacey]

I have seem the same behavior since upgrading to 8.5.  Adding my VI, (which references private assemblies), to a project worked after I created a project configuration file.  However, I have to open the project file before opening the VI otherwise I get a broken arrow.  Is this expected?

Also, I am using this VI in a teststand 4.0 sequence.  Unless I open both the VI and the project containing the VI, I receive an error saying that the VI is broken.  Any ideas on how I can avoid this?

Thanks,
Stacey

[JamesR]

Hi Stacey,

Take a look at number 3 of this document and see if you find it helpful.

Known Compatability Issues with TestStand and LabVIEW 8.5

Message Edited by JamesR on 12-10-2007 06:08 PM

[Stacey]

Hi James,

I have seen that document.  I tried putting the dependent assemblies in the Labview and Teststand folders but it did not seem to help.  I havent tried it since creating the project config file though.  would this make a difference?

[CharlieM]

Hi Stacy,

That could make a difference. It is hard to say. I would defiantly try this first.