NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

System.IO.Port support in TS2024 dotNet Adapter

Hi, 

 I'm trying to upgrade my sequences to TS2024 but many of my DLL works with System.IO.Port Package and looks like the .net adapter for net8 have some issues with that package, some one have a similar issue?

 

GenerQ_0-1732138344533.png

 

0 Kudos
Message 1 of 5
(303 Views)

GenerQ,

Are you targeting your assemblies to .NET 8 or .NET Framework?

If .NET Framework, can you try targeting to .NET 8 and check if it works? If .NET 8, can you check if you are copying all the NuGet dependencies next to your own assembly (probably by using `CopyLocalLockFileAssemblies` or `dotnet publish`)?

 

-Shashidhar

0 Kudos
Message 2 of 5
(255 Views)

Hi GenerQ,

 

Based on the error message, the issue is likely that the System.IO.Port.dll was configured to load from the GAC. This is no longer support in .NET Core since the .NET runtime doesn't look for assemblies in the GAC. See details of changes in the .NET adapter here.

 

You will have to deploy your code differently so the assembly can be located by the .NET runtime. If the missing assembly is a dependency of your top level assembly, then a simple option is to have the dependency present next to the top level assembly in the same folder.

 

Hope this helps.

 

Regards,

trj

0 Kudos
Message 3 of 5
(252 Views)

Hello TRJ,

 

I have a .NET Framework 4.8.1 DLL for communication with devices using Serialport.

It worked fine with previous versions of Teststand, and with Teststand 2023.

It does not work with Teststand 2024 Q4. Teststand shows an error "Could not load file or assembly 'System.IO.Ports'.

 

Does Teststand not find the System.dll?  Or is IO.Ports not in that DLL?

 

I use VS2019 so I can not immediately build for .NET 8.

But I read that the DLL build for Framework 4.8 should work.

 

Placing the System.dll next to my DLL does not solve the issue.

You wrote "You will have to deploy your code differently so the assembly can be located by the .NET runtime" .

Exactly what do you mean by that?

 

Thanks

0 Kudos
Message 4 of 5
(178 Views)

Hi Lucst,

 

System.IO namespace was a part of System.dll in .NET framework. However it has been moved to a separate dll, System.IO.Ports.dll, and it is no longer part of the runtime dlls in .NET Core. It has to be included via a nuget if you move your project to .NET Core.

 

Since System.IO.Ports.dll not a part of the runtime dlls, the .NET Core runtime won't be able to locate it when you run your main dll in it's current form. By the way, this is still true if you were to migrate your project to .NET Core. You are expected to deploy your project correctly and create a self contained set of your top level assembly and it's dependencies (the contents of nugets and other dependencies of your project) so that the .NET runtime can find it. For a .NET Core project, you can do this using dotnet publish.

 

Since you haven't moved to .NET Core yet, the workaround would be to replicate creating that self-contained set of assemblies that your main assembly depends on yourself. However, here the issue might be that System.dll does exists in .NET Core (part of the runtime dlls) and is already loaded by the runtime so it wouldn't load the version that you copy next to your assembly. Something you can try is to copy the System.IO.Ports.dll (from the .NET Core nuget) next to your assembly but i am not certain if it will work since it's not a dependency of your project. If so, moving your code to .NET Core might be the only option.

 

Regards,

trj.

 

Message 5 of 5
(165 Views)