11-28-2024 07:30 AM
Hi everyone,
I get the following message if i call one of my DLLs:
It is a .net-framework dll and worked really fine under TestStand 2023. During the debugging of this error, i learned that .net(-core) doesn't support the GAC.
So I changed my top level assembly, so that all the used GAC assemblies are copied to the output folder. But the error remains.
If i create an action step to call the System.Data.Linq.dll direct, i get the message that the .dll is a 32-Bit-.dll, although i deployed the assemblie with target plattform x64.
Where do i get the x64-version of the DLL or how can i solve this error?
11-29-2024 02:59 AM
If I remember correctly, Teststand 2024 requires a minimum support of 4.8 for the. NET framework version, while your DLL appears to be 4.0 from the image. I'm not sure if this is the reason, but you can try calling a DLL version 4.8 or higher
11-29-2024 03:19 AM
Thanks for the advice.
On my PC is currently the .Net-Framework 4.8.1. installed, so hopefully the associated DLLs in the GAC should be up to date.
When i switch back to TestStand 2023, the problematic DLL works still fine.
12-01-2024 10:01 PM
I tried again and according to your idea, I found a 64 bit available DLL file in the following path and that can be TS2024 loaded normally:
C:\Windows\WinSxS\amd64_system.data.linq_b77a5c561934e089_4.0.15912.0_none_2fb64ba94278df09\system.data.linq.dll
I don't know if this meets your requirements.
12-02-2024 03:37 AM - edited 12-02-2024 03:51 AM
Okay, after I linked this .dll in my dll, i get this message:
Unfortunately i can't find the related .dll and there is also no explicit reference in my top level dll.
12-03-2024 04:14 AM
Since .NET Core doesn't support the GAC, you need to resolve DLL dependencies by placing the dependent DLLs in the same directory as the top-level DLLs.
To do this, copy `System.Data.Linq.dll` from one of the following locations:
Place the copied `System.Data.Linq.dll` in the folder where your top-level DLL is present.
To automate the process to pull the required dlls, you can create and configure a teststand deployment file.
Additionally, consider migrating your code modules to .NET Core for better support and future-proofing.
12-03-2024 04:44 AM
Okay, if i do so, i get the error with the missing System.Data.SQLClient like i mentioned in my last post.
We are planning to update our system to .NET core, but we build a whole test system around TestStand, so it would be nice to have a workaround, especially since all of our DLLs are in the .NET-Framework.
Thank you anyway for your advice.
12-03-2024 05:47 AM - edited 12-03-2024 05:51 AM
Is `System.Data.SqlClient.dll` present in the same directory as the top-level DLLs? If not, then do copy this dll next to the top-level dlls.
Good to know that you're planning to update to .NET core, this should resolve the dependency issues.
FYI: When you migrate to .NET Core, the code related to `System.Data.SqlClient` might not work as it is. .NET Core does not have a GAC, so `DbProviderFactories` cannot fetch the factory from the GAC. In .NET Core, you need to explicitly register the factory using `DbProviderFactories.RegisterFactory()`.
See the Micrsoft documentation for DbProviderFactories.RegisterFactory Method.
Related Posts:
12-03-2024 05:58 AM
Unfortunately there is no System.Data.SqlClient.dll in the already mentioned paths.
Maybe it is part in one of the other DLLs?
12-03-2024 06:47 AM
You can install the System.Data.SqlClient NuGet package from nuget.org and add it as a NuGet reference to your project. This will ensure that the required DLL gets copied next to the top-level DLLs.
Alternatively, you can download and extract the NuGet package, then manually copy the System.Data.SqlClient.dll to the same directory as the top-level DLL.