Could not load file or assembly because runtime is newer than currently loaded run time

[dug9000]

Hi David

That article is admittedly written in a confusing way. I think it was updated to refer to TestStand 2010 in the solution section after TestStand 2010 released, but the bulk of the article was not rewritten to make it clear that the old content only applies to TestStand 4.2.1 and earlier. I will look into getting it rewritten.

To answer your question as clearly as possible:

1) TestStand 2010 (4.5) supports calling .NET 4.0 assemblies (with use of a config file as documented) and integration with Visual Studio 2010. We explicitly tested this functionality with TestStand 2010 and support it with this version.

2) TestStand 4.2.1 and earlier do NOT support .NET 4.0 or integration with Visual Studio 2010. There are known issues with using TestStand 4.2.1 and earlier with .NET 4.0 and Visual Studio 2010. See the article you linked to for details, assume when it says 4.x that it really means 4.0-4.2.1.

Let me know if you need any additional information. Hope this helps,

-Doug

[DavidHary]

Indeed, I already confirmed that and noticed the Test Stand loads the .NET 3.5 framework.

Could you point me to more info on using .NET with Test Stand? Is there a tutorial somewhere? Thanks.

[dug9000]

I don't think there is a tutorial specifically for using TestStand with .NET. I do however recommend upgrading to TestStand 2010 if you have not already done so since there have been significant enhancements made to the .NET adapter in TestStand 2010, such as support for generics, specifying multiple calls with dot notation, and numerous other improvements.

Just to make sure you understand, the .NET 3.5 framework actually uses the .NET 2.0 clr. Yes, it is all a bit confusing and I don't know why Microsoft chose to do things this way, but what really exists as far as CLR is as follows:

.NET Framework 2.0, 3.0, and 3.5 all use the same clr, the .NET 2.0 clr.

.NET Framework 4.0 uses a new clr, the .NET 4.0 clr.

Thus there is nothing that needed to be changed on the TestStand side to support .NET framework 3.5, it's really the same clr as 2.0, but with more APIs and some patches.

Hope this helps clarify things,

-Doug

[DavidHary]

Doug,

That's totally helpful as minutia totally matter in our trade. Our standard platform is Windows 7 x64, TS 2010 SP1, and LabVIEW 2010 SP1 x86 (apparently TS does not support LV x64, right?)

As to tutorials, were could I find more info on using the new .NET features, such as generics, that you mention?

David

[dug9000]

There is currently no version of TestStand called 2010 SP1, the article was also wrong in this regard. There is a 2010f1 which is probably what you meant.

TestStand should be able to call x64 VIs using the development environment for LV x64 (but not x64 VIs via the runtime engine), though I believe there are some issues with this that require some workarounds (there is likely a KB on the issue).

As for tutorials, you should read the teststand 2010 release notes where it talks about what's new in 2010 for the .NET adapter. You should also read the reference manual section on the .NET adapter in chapter 5. Also, if you are completely new to TestStand, you should run through the teststand tutorial located in the public directory and look at many more section of the reference manual, and also look at the many various examples in the examples directory. There is a lot to learn about teststand in general.

Hope this helps,

-Doug

[DavidHary]

Doug,

This config file worked fine with the Sequence Editor. However, we are experiencing difficulties when calling our sequence from TestExec.exe under .\UserInterfaces\Labview.

Here is the message we are getting:

Could not load file or assembly 'file:///C:\...\bin\Debug\Empower.WhiteSands.DataServer.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.

It seems that the TestStand runtime loads the 2.0 CLR.

What can I do to tell the TestStand runtime to load the 4.0 CLR?

Thanks

David

[Jeff.A.]

Hi David,

You will need to create a similar config file for any executable that you wish to use with .NET 4.0 assemblies.  (Create a TestExec.exe.config file in the same directory as TestExec.exe and with the same content mentioned before)

-Jeff

[DN_Eng1]

I put the following lines in the SegEdit.exe.config file and put in the same directory SegEdit.exe and still TS 2010 didn't accept my .net 4.0 runtimes.

How does TS read this config file? Is there something, I am missing? 

<?xml version="1.0"?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
</assemblyBinding>
</runtime>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" />
</startup>
</configuration>

[dug9000]

Did you really spell the file name as SegEdit.exe.config? That is wrong. It's a 'q' not a 'g' (i.e. seqedit.exe.config).

If you spelled it correctly, did you restarted teststand after creating this file? Also, make sure you didn't accidently create it with a .txt extension or something (Windows hides extensions by default unless you change the setting for this in file explorer).

-Doug

[David_Jackson]

I have a similar issue using the .NET runtime operator interface code.  The operator interface executes sequences that reference version 4.0 .NET modules located in the GAC.  When it encounters one of these I get an error saying that the .NET module does not exist.  It cannot find them in the .NET version 2 runtime GAC location of C:\Windows\Assemblies.  However, I have manually confirmed that these assemblies exist in the new .NET version 4 runtime location of C:\WINDOWS\Microsoft.NET\assembly\GAC_MSIL.  This indicates to me that the operator interface is still running the default version 2 .NET  runtime.

I can correct this behaviour in the sequence editor by creating the seqedit.exe.config.  Based on the response above the same approach should fix the runtime behaviour by creation of a file called TestExec.exe.config, stored in the same folder and TestExec.Exe.  The problem for me is that this file already exists and appears to be created by the Visual Studio build process. This contains lots of information that looks like it is needed!  I took the liberty of editing this in Notepad, adding a new line from the seqedit.exe.config file that did not exist in the created TestExec.exe.config file.

<startup useLegacyV2RuntimeActivationPolicy="true"><supportedRuntime version="v4.0" /></startup>

I've attached the modified file, including this line (added .txt to the suffix so it posts ok). The operator interface now loads the version 4 runtime and works with my sequences calling v4.0 .NET modules. However, whenever I rebuild the operator interface in Visual Studio 2010 it re-creates the original TestExec.exe.config file (missing the startup line above).  The creation of this file seems to be out of my control. Does anyone know if I can instruct the Visual Studio 2010 build process to add the startup line to this file?

Regards,

David