.net assembly does not run when LabView adapter is in runtime.

[jorge5_0]

  Got a VI that calls a .net exe, if I have Labview 8.2 adapter in development mode this application gets launched and works fine, if I change the adapter to runtime it fails when trying to load the application, I have tried several things that I found on the message boards but none has fixed this problem.

  Please take a look at the attachment, this error happens after the first step in the vi gets executed, frmMain.show() function seems to be the one triggering the error.

  Thank's in advance;

  Jorge

[dug9000]

It sounds like you are missing an assembly your assembly depends on. Keep in mind that .NET looks in the directory of the .EXE for the process in which it's running. When using the labview development environment that directory is the LabVIEW.exe's directory, but when you use the runtime it is the directory of the sequence editor or user interface. Do you know what assemblies your assembly depends on? Where are the located? Also what version of LabVIEW are you using?

Hope this helps,

-Doug

[jorge5_0]

  Thank's for your reply, Doug.

  I have actually being doing some more investigation on this and yes, it truns out there are some dll's that got used by this assembly, I was just wondering where should these be located when running in runtime mode, but you just answer this quiestion, so let me try it and post the results later today.

  Thank's again,

  Jorge

[dug9000]

Here is more information from Microsoft on how the .NET framework locates assemblies:

 http://msdn.microsoft.com/en-us/library/yx7xezcf%28VS.80%29.aspx

It's quite a bit more complicated that just looking in the application directory. Also, if your assembly is using LoadFrom to dynamically load other assemblies there are special rules for that as well.

In the simplest case, it checks the GAC first, if it's not in the GAC it looks in the applicationbase directory. But this behavior can be altered by configuration files and various other special cases.

NOTE: The TestStand dotnet adapter uses LoadFrom to load assemblies that are specified that are not in the GAC. When using LoadFrom, the .NET framework will also look for assemblies on which the loaded assembly depends in the loaded assembly's directory.

Hope this helps,

-Doug

Message Edited by dug9000 on 09-01-2009 05:55 PM

[jorge5_0]

  Yes, I have done some more testing and I think it is more an issue of .Net than runtime, I got a hold of a document that explains what references need to be accessible for the assembly to work propperly but the exeample is for Visual so I'm still trying to figure how to set this references in TestStand.

  I have attached a couple of attachments, one is a snapshot of the document, and the other is a .NET action step that does the same calls as the VI and returns the same error.

  Thank's for your replies.

  Jorge

[dug9000]

commonLib and TCMD are the ones that matter. The system assemblies are in the GAC and should be found. commonLib and TCMD are probably your own custom assemblies and likely need to be in one of three places. Try the following and see which works and choose the one that's best for you.

1) Try putting them in the same directory as the assembly you are calling directly from TestStand or LabVIEW. If commonLib or TCMD depend on any other assemblies that aren't in the GAC then they will need to be added to this directory as well. This goes for all of the options really.

2) Try putting them in the same directory as the application (the .exe file which loads them).

3) If they are strongnamed (if they have public key) you can try installing them to the GAC.

Hope this helps,

-Doug

[dug9000]

In looking at the error message more carefully. The problem you are seeing might be due to custom loading of assemblies dynamically by your code. The loadplugins method of your assembly's code in the error message is not a standard thing. You might need to look at that code more carefully or ask the person who developed it what the requirements are.

Also, perhaps you should be using a call executable step to launch your exe rather than using the dotnet interop code of either labview or teststand. I strongly suspect the assembly is meant to be launched as an exe and not called directly as a subsidiary assembly as you are doing now.

-Doug

Message Edited by dug9000 on 09-03-2009 09:04 AM

[jorge5_0]

  Finally I was able to make this work!!   Although I’m not sure if it is a workaround; please let me know what you think about this.  I was trying many tools to debug this problem as it was a CLR (Common Language Runtime) problem, where for some reason the correct paths to the files this particular assembly uses would not be found by the system; I came across this Microsoft tool, CLR Debugger and I could tell that the application crashed while trying to load NationalInstruments.Internal.VSCodeGeneration.dll from the TestStand 3.5\bin folder, if I ran this application from another folder it will work, and the log never showed the mentioned dll, so I decided to remove it from the \bin folder and it started working!  So there are some open questions still, where does this dll came from? And what is it supposed to do? I tried a search but came out with nothing useful.   Thank you very much for your help and time.   Jorge