How to use .NET 8 without GAC?

[bienieck]

I'm looking for recommendations on using .NET 8, especially given the absence of the Global Assembly Cache (GAC). In my sequences, I frequently rely on mscorlib.dll, which previously could simply be selected from the GAC list. However, with the latest TestStand update, the GAC has been removed, requiring the DLL to be specified by its path.

What would you suggest for configuring the steps with the .NET adapter? Should I add the C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.8 folder to the PATH, or would it be better to add it to the TestStand Search Directories? Or is there another approach you'd recommend?

[Oli_Wachno]

Good point! At least for the general Microsft stuff.

In the time before .net8 support, I have never used GAC fr my own assemblies, they are lcoated in the approproriate folders within the project / framework hierarchy

[bienieck]

I also didn't register my own assemblies in GAC but I often use the standard ones for simple file operations and such. GAC was very handy for it.

[pawhan11]

Create .net project and referenace all libraries teststand might need to use. Best is to create wrappers that exposes simple datatypes to teststand instead of calling core libs directly.

In our setup project is compiled to bin directory where sequences reside and dlls are loaded by relative path from that dir. In .net8 all project dependencies will be copied to build output dir.

[GaryN]

Michal, did you implement any of the solutions here or find another method? We're currently testing moving our technology stack to the latest NI releases and have run into the GAC issue. We too use a lot of mscorlib. Referencing our assemblies directly is an annoyance, but doable. But I'm struggling with the mscorlib stuff.

[bienieck]

In my opinion, as a quick fix, you can use the facade mscorlib.dll file located in the subfolder C:\Program Files\dotnet\shared\Microsoft.NETCore.App. The runtime should be able to read from this file where the base .NET types are defined, and overall it should work fine. You can also add the folder of the specific .NET version to the TestStand search directories, so you don’t have to provide full paths to the DLLs in each step. On one hand, this doesn’t seem to be the officially recommended approach by NI, but on the other hand, it looks like this file was included in .NET Core exactly for such scenarios. I don’t see any major issues with this approach myself, but to be fair, I haven’t experimented with it very extensively. I’d also be interested to hear any concrete pros and cons of using it this way.