Certain DLLs are not included in C# plugin builds

Hello,

I’ve been working on a plugin for a handful of users and have run into a certain issue a few times now. My plugin generates excel sheets using NPOI and makes API calls with Http.Json. Both of these work fine on my computer, but some users have been experiencing errors that the dependent or transitive-dependent assemblies were not found.

The plugin is hosted on a private server, so the process is a bit non-standard and might be excluding the proper dlls. If it matters, my process is to build the plugin and copy the .rhp file to the plugin subdirectory on the server sans the contents of the built folder.

Any help would be appreciated,
~CH

Hi @Cole_Howell1
I’m surprised this setup works at all, I am fairly certain that Windows should block the automatic loading of RHP and DLL coming from an external machine on a shared server.
If you drag and drop the folder locally on the user machine, and you unlock all the files (including the dlls) I believe the error will disappear.
Farouk

You might consider building a YAK package and installing that instead using the Yak CLI since all the DLLs would be included with the .rhp.

Sorry, I misspoke - I’m moving just the generated .yak file to the server, not just the .rhp. My users have their package manager configured to query our server as a package repository.

Whenever the package is built, /bin contains subdirectories that look like the example in the yak docs. An example of the directory once it’s built:

PluginRelease
├── manifest.yml
├── myplugin-1.1.1-rh8_23.yak
├── net48
│    └── myplugin.rhp
│    └── myplugin.pdb
│    └── myplugin.rui
│    └── NPOI.Core.dll
│    └── System.Net.Http.Json.dll
│    └── ... // Other .dlls, including transitive dependencies
└── net7.0
│    └── ... // Same structure as net48
└── net8.0
     └── ... // Same structure as net48

My thought is it might be an issue with the way Visual Studio is configured or the dotnet runtime my users’ machines are running, as I’ve had issues with that in the past in particular.

Thank you both for your time, and apologies for the mistype.

What was the issue they ran into?

I had a user with the error recreate it for me. Primary error is:

Could not load file or assembly ‘System.Text.JSON, Version=10.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51’. Could not find or load a specific file. (0x80131621)

Looking up the error code and comparing against the plugin’s project, it claims System.Text.Json is not supported on net7. I’m not sure if my user is using the net7 or net8 framework, but changing that may fix it… I’ll give it a shot.

I don’t the same message in my project with NPOI, but last time it happened it was due to a transitive dependency failing to load. I can’t recreate it on my machine, but I’ll upload the message once I find some time to recreate the error.

Not sure if it applies

In comparison to NET48, NET Core is not a default installation on a Windows PC. Even if an application ships NET Core assemblies to run without the Core Runtime globally installed, it is possible it has issues to locate it. To be on the safe side, you either force people to install the NET Runtime or you ship the assemblies with it. It can however conflict with Rhino assemblies. I’m not sure if Rhino ships all of those you are using. NET Core also excluded a lot of assemblies into Nuget packages to keep the standard library as small as possible. Maybe try to ship the dlls and see if it works. It helps to test it on a VM where no NET Core is installed. I had a lot of troubles in the past with Net applications which do not ship the NET Core runtime. In my corporation, NET Core is usually installed by default, still a tiny group of uses haven’t had it installed. So I catched the error and prompted the user to install the runtime first.

I assume you’re referencing system.text.json in your project (or a dependency is) via nuget?

I’m thinking you’re on to something, because some machines work without issue and some throw the missing assembly error when using parts of the plugin that rely on non-standard dlls. I’ve been considering using a virtual machine for testing moving forward to verify that any user can work with the plugin, so I appreciate the response - definitely something I’ll look into. If that ends up being the problem, I’ll make your reply the solution.

Yes, that’s correct.