I do not know why exactly but I got it to work both under WPF and Console Apps. I uninstalled all packages and references and re-installed with the "highest dependency" option for dependent package versions. I tried that before, and it did not work then, so I doubt this was the culprit. The only explanation I have and what I changed and made the difference is the following:

var assembly = Assembly.LoadFile(assemblyPathFileName);
                
                ////load into byte array
                //var byteArray = File.ReadAllBytes(assemblyPathFileName);


                ////create assembly
                //var assembly = Assembly.Load(byteArray);

To make sense of the above, I essentially wrap the Eikon API in my own plugin class library. The library and all its dependencies will then be loaded via the above. Before, I loaded assembly via the commented-out code, now I use "Assembly.LoadFile()". I forgot what the difference exactly in the assembly load rules between Assembly.LoadFile and Assembly.Load vs LoadFrom. But this apparently made all the difference. My hunch is that "Assembly.LoadFile" will get a path and any other dependent assemblies will be searched in the same folder while loading bytes does not provide such information. Please note that I for "Assembly.Load" I hooked into "AppDomain.CurrentDomain.AssemblyResolve += ..." in order to resolve unresolved assemblies, but nothing worked until I used "Assembly.LoadFile()".

When installing Eikon .NET SDK with Nuget, it will add tasks into the project file (csproj) to copy those DLL files to the $(OutputPath) folder.

If you open the project file (csproj) with an editor, you will see those tasks under the<Target>element.

 <Target Name="EikonSdkIpc_CopyNativeDependencies" AfterTargets="AfterBuild">
    <Error Condition="!Exists('..\packages\ThomsonReuters.Udap.Ipc.Signed.x64.2.10.5\tools\EikonPipeDll.dll')" Text="This project needs a file provided by a NuGet package that is missing on this computer. Enable NuGet Package Restore to download it.  For more information, see http://go.microsoft.com/fwlink/?LinkID=317567." HelpKeyword="EIKONSDKBUILD0001" />
    <Copy Condition="Exists('..\packages\ThomsonReuters.Udap.Ipc.Signed.x64.2.10.5\tools\EikonPipeDll.dll')" SourceFiles="..\packages\ThomsonReuters.Udap.Ipc.Signed.x64.2.10.5\tools\EikonPipeDll.dll" DestinationFolder="$(OutputPath)" ContinueOnError="True" />
...
  </Target>

You need to verify that the locations of DLL files (SourceFiles attribute in the <Copy> element) are correct.

From your project file, Visual Studio copies the 64 bit version of Eikon SDK API to the output path.

SourceFiles="..\packages\ThomsonReuters.Udap.Ipc.Signed.x64.2.10.5\tools\EikonPipeDll.dll"

However, to make the application executable, you replaced the copied DLL files with the files from C:\Program Files (x86)\Thomson Reuters\..... As I know, applications in the C:\Program Files (x86)\ folder are 32 bit Windows applications.

It seems that your application is 32 bit but the visual studio copies the 64 bit version of Eikon SDK API to the output path. This is why it throws the exception at run time.

If you target the application to 32 bit platform, please use 32 bit version of Eikon SDK API (ThomsonReuters.Desktop.SDK.DataAccess.Singed) instead.

ThomsonReuters.Desktop.SDK.DataAccess.Singed is for a 32 bit application while ThomsonReuters.Desktop.SDK.DataAccess.Singed.x64 is for a 64 bit application.

The script in the project file will look like:

 <Target Name="EikonSdkIpc_CopyNativeDependencies" AfterTargets="AfterBuild">
...
    <Copy Condition="Exists('..\packages\ThomsonReuters.Udap.Ipc.Signed.2.10.5\tools\EikonPipeDll.dll')" SourceFiles="..\packages\ThomsonReuters.Udap.Ipc.Signed.2.10.5\tools\EikonPipeDll.dll" DestinationFolder="$(OutputPath)" ContinueOnError="True" />

Thank you so much for the project file. It looks okay.

First, I would like to focus on the version of EikonPipeDll.dll file. From my test, both versions can run properly and be able to retrieve the data. The followings are screenshots of Process Explorer that shows the versions of DLL files loaded by the application.

This one is for version 9.0.11.1902 (11/24/2015).

The following picture is for version 9.42.0.140 (11/16/2017).

I think that if the version of ThomsonReuters.Udap.Bus.Tools.dll is 2.10.5.157 (11/24/2015), the correct version of EikonPipeDll.dll should be 9.0.11.1902 (11/24/2015).

The default platform of the example program is x86. After changing to x64, the script may incorrectly copy the x86 (32bit) DLL files to the output folder which causes the run-time exception. You may verify the platform of the DLL files copied by the Visual Studio with a "dumpbin /headers" command from Visual Studio Command Prompt.

C:\...\DataApiUsageExampleTimeseriesData\bin\x64\Debug>dumpbin /headers EikonPipeDll.dll
Microsoft (R) COFF/PE Dumper Version 14.00.24215.1
Copyright (C) Microsoft Corporation.  All rights reserved.

Dump of file EikonPipeDll.dll

PE signature found

File Type: DLL

FILE HEADER VALUES
            8664 machine (x64)
               6 number of sections
        535E2E75 time date stamp Mon Apr 28 17:33:25 2014
               0 file pointer to symbol table
               0 number of symbols
              F0 size of optional header
            2022 characteristics
                   Executable
                   Application can handle large (>2GB) addresses
                   DLL

...

If it is a DLL for x64 machines, you will see machine (x64) in the result.

From the previous attached project file, when installing Eikon SDK, Visual Studio may use Highest value for the DependencyVersion option so it installed the highest version of dependency packages. For example, it installed Common.Logging version 3.4.1 instead of 2.1.2.

 <Reference Include="Common.Logging, Version=3.4.1.0, Culture=neutral, PublicKeyToken=af08829b84f0328e, processorArchitecture=MSIL">
  <HintPath>..\..\..\packages\Common.Logging.3.4.1\lib\net40\Common.Logging.dll</HintPath>
  </Reference>
  <Reference Include="Common.Logging.Core, Version=3.4.1.0, Culture=neutral, PublicKeyToken=af08829b84f0328e, processorArchitecture=MSIL">
  <HintPath>..\..\..\packages\Common.Logging.Core.3.4.1\lib\net40\Common.Logging.Core.dll</HintPath>
  </Reference>

For an application to use these highest dependency packages, App.config of the application should have the following entries.

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="protobuf-net" publicKeyToken="257b51d87d2e4d67" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-2.3.3.0" newVersion="2.3.3.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-10.0.0.0" newVersion="10.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Common.Logging" publicKeyToken="af08829b84f0328e" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-3.4.1.0" newVersion="3.4.1.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>

For those 4 DLL files issue, could you please use a Process Monitor tool to monitor your process in order to verify the problem?

Please refer to this question regarding how to use the Process Monitor tool.