If you are building the UI yourself, you can just tell VS to target the 4.0 framework directly. There should be a project setting called "Target Framework" that you can change to .NET 4.0. The config file is more just a workaround to get an executable originally built against an earlier .NET version to load a newer version instead.
I've already set this per the attached screenshot. I forgot to mention this is running TestStand 2010 SP1 and I have updated the operator interface TestExec project to reference the latest TestStand dependent assemblies (version 188.8.131.52). The strange thing is that the testexec.exe.config file appears to reference older TestStand .NET assemblies.
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"><dependentAssembly><assemblyIdentity name="NationalInstruments.TestStand.Interop.API" publicKeyToken="AD9244EB3B825CD8" culture="neutral"/><bindingRedirect oldVersion="0.0.0.0-184.108.40.206" newVersion="220.127.116.11"/></dependentAssembly>
I've even deleted the testexec.exe.config file, cleaned the solution and rebuilt it. The file re-appears in the testexec/bin/release directory but still contains references to the older assemblies and is missing the startup line I need. It always re-appears with the same build date as well of 30-Sep-11. I wonder if its just being copied from somewhere and is not being rebuilt?
That's definitely odd that your config file is still referencing the old assemblies. You deleted them from the project and then added the ones from the <TS 2010 SP1>\API\DotNet\Assemblies\CurrentVersion? Are they showing up as the proper version in your project after that?
It sounds like the problem is something with building your app in VS because it does not appear to be using .NET 4.0, or honoring your updated assembly references. If you want to verify what CLR version your UI is using, from a VS command prompt you can use the "clrversion <PID>" command. See if that shows v2.0 or v4.0.
Check to see if your project has an app.config file. Visual studio 2010 will auto-generate and add this file depending on your project settings and then at build time will copy it to the target directory with the correct name for your exe file. If so, I think you should add any customizations to the app.config in your project. Also, the way you should be adding references to teststand assemblies is by doing an "Add Reference..." on the references node in your project (assuming C# here) and selecting the ".NET" tab in the dialog and selecting "TestStand API Primary Interop Assembly" or similar from the list. You then should update the settings for the reference (right-click on it and choose "Properties...") to set "Embed Interop Types" to false, and then also set "Specific Version" to false ("Copy Local" should also be false, but I think that's the default).
Hope this helps,
Thanks Jeff and Doug for your help. I confirmed that my TestExec project was referencing the correct assemblies. I even deleted them all, cleaned the project and re-added them one at a time following Doug's instructions. After rebuilding the project my app.config file still showed references to the old version 18.104.22.168 assemblies.
However, what I did was to manually edit the app.config file, updating the new version to be 22.214.171.124 for each assembly. I also added the following lines to the app.config file:
<startup useLegacyV2RuntimeActivationPolicy="true"> <supportedRuntime version="v4.0" /> </startup>
After rebuilding the project I found that my TestExec.exe.config file included the correct information and that I was now able to run the operator interface with the correct v4.0 .NET version. So editing the app.config file manually was the solution here.
Actually the references to the teststand interop assemblies really shouldn't even be in your app.config file. You can probably just remove them completely. I'm not sure how they got there in the first place.
To force the sequence editor to load .NET CLR 4.0, create a file called
seqedit.exe.config with the following content in the
<supportedRuntime version="v4.0" />