.NET Constructor Assembly not found error

[alfredotim]

Hello,

I'm trying to use a private assembly in Labview 2009. I've selected the path where my dll is located with the constructor node VI.

My dll is located as the same place than my vi.

If i need to open a file in another folder in my application, when i want to call again my assembly, it seems that the constructor node have lost the dll path.

I need to set again the dll path in the constructor node vi to use my dll again.

Is there a solution to not lost the assembly path?

thanks.

Regards.

Fred

[smercurio_fc]

I'm not really following what it is that you're saying. You said that you "need to open a file in another folder in my application". Are you referring to another VI? Is this other VI also supposed to use that assembly? Also, what do you mean by the "constructor node have lost the dll path"?

Which version of .NET are you using?

[alfredotim]

Hello,

Thanks for your response.

I'm using .NET 2.0 and Labview 2009.

When I say "I need to open another file" I mean another file specific for my application (a configuration file for example, but with the OpenFile.vi).

I think this action change the current folder of Labview. Then when I want to execute a function from my .NET assembly, Labview doesn't retreive the assembly previously selected in the constructor node vi. So I need to reopen the assembly file from this VI to execute my vi correctly.

See example vi.

Fred

[smercurio_fc]

---

alfredotim wrote: 

When I say "I need to open another file" I mean another file specific for my application (a configuration file for example, but with the OpenFile.vi).

I think this action change the current folder of Labview.

---

This doesn't happen. LabVIEW isn't like Matlab in that there's a "current working folder". I don't have your assembly, so there's no way for me to test your code. Is it possible for you to upload this assembly?

Couple of quick comments regarding the code:

• In general, you should use path controls/constants for specifying paths, not strings. This makes the code more portable. If you have a function that takes in a path as a string there's the Path To String function.
• You should close the reference you create to the assembly when you're done with it. 

[Steve__M.]

Hi,

As smercurio_fc said we can't test your code without your assembly. For more information on how to place your .NET assemblies so LabVIEW can locate it you can follow this KB

Regards,

[alfredotim]

Hi,

Thanks for responses. 

I've tried an example code with a simple assembly without other assemblies dependencies and it's work fine.

I think I have a problem because my main assembly have another assembly dependency that is called dynamically.

- C# code:

            //***** Load class
            Assembly assembly = Assembly.LoadFrom(assemblyName);
            foreach (Type curType in assembly.GetTypes())
            {
                if (curType.Name == className)
                {
                    return (MailService)Activator.CreateInstance(curType, type, services);
                }
            }

When I change the current Labview  path, the assembly called dynamically is not found by Labview and I need to mannualy reconfigure the Construtor to solve the problem.

I suppose that Labview can't manage this type of dll call. May be I will try to suppress this call type and add a static reference in my C# project.

Fred

[smercurio_fc]

---

alfredotim wrote:

When I change the current Labview  path,

---

You keep saying this, and I don't know what you mean. There is no "current LabVIEW path". There's a "Current VI Path", but that's different.

---

alfredotim wrote: 

I've tried an example code with a simple assembly without other assemblies dependencies and it's work fine.

I think I have a problem because my main assembly have another assembly dependency that is called dynamically.

I suppose that Labview can't manage this type of dll call. May be I will try to suppress this call type and add a static reference in my C# project.

---

This is not a LabVIEW problem - it's a .NET issue. .NET has specific rules on how to find assemblies. Assemblies will be loaded from the GAC or from the current process' directory (that's not the "current path" that you keep referring to - it's the directory where the application resides). If the code is in a project, then the project directory gets included as well. 

You may be running into the issue described here: Calling a .NET Assembly from LabVIEW Copies the Assembly to a New Location.