.NET Framework / .NET Core / .NET versions compatibility

[chhh]

iAPI currently provides 3 sets of libraries: for Exactive, for Fusion, for Exploris. The examples all target different versions of .NET Framework. Question: Does it really matter which version of the .NET Framework our application is built against? E.g. can I build an application targeting NET Framework 4.8.1 and expect all 3 instruments to be working fine? We have QE-HFX and Exploris 480 systems, it would be nice to have a single binary for both.

[chhh]

Also, app.config in exactive/ComprehensiveExample has this note, could you please help decipher it:

<configuration>
  <!--
       If starting under CLR4, we want to load all CLR2 assemblies
  -->
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <!--
         Prefer CLR4 over CLR2. This is a bit odd for CLR4 present with Foundation 3.0 installed.
         But if Foundation 3.1 is installed, it requires CLR4 for Foundation.IO.
    -->
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
    <supportedRuntime version="v2.0.50727"/>
  </startup>
</configuration>

[jesse-canterbury]

In my view, these things are minor issues, and will most often result in compile time errors. I would not expect any instrument functionality issues arising from using, e.g. framework 4.8.1 instead of 4.8. In other words, if it compiles & runs, you should be good to go.

I could be wrong about this, but having a single binary IAPI for the QE-HFX and Exploris systems is not likely to happen, unfortunately, as they are built on different software platforms. The Exploris architecture was a departure from what had been done for the QE line.

I believe the comments in the appconfig there refer to support for different versions of Foundation. In other words, if CLR4 is present on the machine but Foundation 3.0 is installed, we may still need CLR2. However Foundation 3.1 requires CLR4. Foundation 3.0 is "old" from our point of view so we support it but prefer 3.1. Hopefully that makes sense! Here again, I don't think there is anything there that should be important for using the tool.

@Kfort01 maybe be able to provide some additional context here.

[chhh]

Thank you, @jesse-canterbury !

Those might sound like minor issues to you, but to me:

• it's working with pretty expensive instruments (making down time expensive)
• very little room for experiments (e.g. an instrument might be available for 2 hours a week - you run one test, and then it has to return to production service).

Regarding "if it compiles & runs, you should be good to go" - that's sort of what I thought. In the end, all the code that controls the instrument runs separately and we're merely sending some messages through IAPI interfaces - if the messages get on the wire and are successfully decoded on the other end, likely no harm can be done.

[jesse-canterbury]

Thanks much for that perspective. I understand the need to develop on instruments that are in heavy use. To minimize development overhead due to issues with .NET compatibility, you could try setting up a very minimal example, like one that only makes one or two references to the IAPI but doesn't actually do anything else. You could set up this example away from the instrument itself, and only transfer it to the instrument when you are ready to do the functional development of setting up scans and so on.

Anyway, good luck with your experiments.