I’m starting to use a license manager in order to protect my plugin. I’m using QLM License Manager.
I setup my project to use the QLM.QlmLicenseLib from NuGet. I’m able to compile but when I start up Rhinoceros and run my plugin that is going to check the license I have the following exception even I have the System.Security.Cryptography.Xml.dll in the same folder as my plugin dll:
System.Exception: Could not load file or assembly ‘System.Security.Cryptography.Xml, Version=8.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51’. Could not find or load a specific file. (0x80131621)
Could you give me any clue about what would be the problem?
Thank you!
Jordi
It’s a VB.NET project based on .NET 7
I used NuGet to add the QlmLicenseLib.
I have this to my .vbproj file in order to have all dll dependencies in the same directory where my dll plugin is: <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
it’s just a guess, because I usually work with c# and Visual Studio, but I have to make a right click on ‘references’ and reference the dependencies in the project as well, not just put it manually in the same folder.
As I would guess Windows would look for system dlls first in the system folders, not in the project folder.
Do you find the dll somewhere în your dependencies list? If not maybe the QLMLib does reference another version than the one being there.it says version 8.0.0.0 specifically is missing, do you use 8.0.0.0 with you other pc on which it’s not working?
BTW, I just saw that you make a jewelry plugin. Nice! My plugin is working pretty well, but I have never published more than two super basic functions, because it’s rather complex for most goldsmiths needs (that all want some easy-click Matrix solution ), so IDK anyway…
I’m pretty sure you’d need to select the Cryptography dll in the assemblies folder, so that the right version is used and not the one from the system with probably another version.
I tried to add the System.Security.Cryptography.Xml assembly directly to the Assemblies in my project but it didn’t work. I have the same exact error. Also, I think it doesn’t make sense, I was expecting that NuGet package system it take care of all dependencies of QlmLicense.
I just took a look at your Jewelry Plugin and it looks very cool. We also build Jewelry Plugins ours is called JewelBeetle. It looks like you have some nice features for creating gems.
I’ve found that sometimes finding assemblies related to your plugin can be a challenge under Rhino since the Rhino.exe may not be in the same folder as your plugin.dll/rhp file. This was more of an issue for us when we were trying to use RhinoInside, but this logic might help you.
You can hook into the AppDomain assembly resolve event, which may help you to determine which assemblies or related assemblies that it is not finding. You can also use that even to manually locate the assembly and load it.
Then in that method you can handle the issue, and/or log the issue. Here I’m assuming you have a _pathToBin variable pointing to the path of your plugin:
// Find Assembly for the Domain, since we are not running from our Bin Folder
var assemblyParts = args.Name.Split(',');
var assemblyPath = Path.Combine(_pathToBin, $"{assemblyParts[0]}.dll");
if (File.Exists(assemblyPath))
{
RhinoApp.WriteLine($@"Manually Loading assembly {args.Name}");
return Assembly.LoadFrom(Path.Combine(assemblyPath));
}
else
{
RhinoApp.WriteLine($@"Assembly Not Found in {assemblyPath}");
}
The other possible issue could be that Rhino.exe has already brought in a version of the assembly you need, and that will be more trouble…
One other thing to check is to make sure that the NuGet package is built for the runtime you are targeting. If you are targeting Framework (net48) then you need to start Rhino with /NetFx switch.
You can also edit your plugin’s project file, and make sure that it is setup for applying binding redirects as needed automatically, and then rebuild your solution.
As you can see there are two blocks. The first one (1) is the part where Rhinoceros just loads my plugin. It seems is able to open the System.Security.Cryptography.Xml.dll assembly.
In the second block (2), it seem it is looking first to some other folders but finally it goes to the folder of my plugin and it is able to load it.
This second block it is when I execute one of my plugins command that is going to use the QLM.LicenseValidator() that it seem is going to use the System.Security.Cryptography.Xml.dll
Is this giving you any clue about what is going on?
Also, I tried to apply binding redirects with no luck.
I’m targeting to .NET 7.0 and I run Rhinoceros with the /netcore argument.
If you were trying to figure this out for .Net Framework, I would suggest using the Fusion Log Viewer (fuslogvw.exe), this shows all assembly bind resolve events and where it’s checking and why it isn’t finding dependencies. But that doesn’t appear to exist for .NET Core. (fuslogvw.exe must be run as ADMIN, so hold CTRL+SHIFT when opening the Developer Command Prompt)
This is not present in .NET Core. They have another solution called dotnet-trace. You have to manually install dotnet trace, I recommend opening a Developer command prompt as admin (see above) and run this command:
dotnet tool install --global dotnet-trace
You should see something similar to this output:
Here is the documentation on that tool:
So you can launch a trace session using the following command:
Once Rhino completed loading and you’ve attempted to load your plugin, you can return to the command prompt and press ENTER which will stop the trace. The Command Prompt hangs for some reason on my PC, but the trace file is still generated.
This will then start a process where it processes all of the data from the trace and generates a *.nettrace file. Use Visual Studio to open this file to review the data.
In VS you can find the bind events, similar to in Fusion Log Viewer. I don’t have a .Net 7 plugin to try this with, but hopefully this can help you.
There is a filter in VS to remove some of the noise events:
Then you can select specific records, and view the stacktrace and the context surrounding the events:
Thank you for your support.
I’m receiving support from QLM. We are in the point that we unblocked my problem and QLM support people is going to check from their side what is going on with the dll issue.
I’ll keep you posted about the findings in case it can helpful for others.