I’ve having trouble getting my plugin to work with Rhino 8. It’s mostly fine but getting an issue when I use the Azure.Storage.Blobs assembly. This in turn needs Azure.Core and from the debug output it’s loading the version in the Rhino 8/system/netcore folder rather than the one packaged with the plugin. I have assembly redirects configured but I gather this won’t work in .NET core.
This is the error:
'Rhino.exe' (CoreCLR: clrhost): Loaded 'C:\Users\martin\source\repos\PluginConnect\PluginUpload\bin\Azure.Storage.Blobs.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'Rhino.exe' (CoreCLR: clrhost): Loaded 'C:\Program Files\Rhino 8\System\netcore\Azure.Core.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'Rhino.exe' (CoreCLR: clrhost): Loaded 'C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App\7.0.13\System.Threading.Tasks.Extensions.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'Rhino.exe' (CoreCLR: clrhost): Loaded 'C:\Users\martin\source\repos\PluginConnect\PluginUpload\bin\Azure.Storage.Common.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
Exception thrown: 'System.TypeLoadException' in Azure.Storage.Blobs.dll
Exception thrown: 'System.TypeLoadException' in System.Private.CoreLib.dll
Exception thrown: 'System.TypeLoadException' in System.Private.CoreLib.dll
Exception thrown: 'System.TypeLoadException' in System.Private.CoreLib.dll
An exception of type 'System.TypeLoadException' occurred in System.Private.CoreLib.dll but was not handled in user code
Could not load type 'Azure.Core.Pipeline.HttpPipelineOptions' from assembly 'Azure.Core, Version=1.6.0.0, Culture=neutral, PublicKeyToken=92742159e12e44c8'.
Version 1.6.0.0 is the one in the Rhino system folder. The version we compiled against is 1.35.0.
Thanks for the link - but so far in my attempts a custom AssemblyResolve handler never gets called. I’m guessing the assembly is already loaded somehow.
I’ve also tried loading a specific version directly but it always seems to load the Rhino version. e.g.
Thanks Dale. That’s the guide I started with and helped getting Debugging up an running with Rhino 8. As recommended I’m still targetting .NET 4.8. No compatibility issues were found by the compat tool.
It seems specifically related to the Azure.Core assembly. The version that comes with Rhino (1.6.0) seems quite old. Even if that was updated it would be good to have a way to be able to control which assembly version is used by the plugin. Maybe this isn’t feasible.
Hi @dale
I currently have Rhino8 on my machine. In the rhino system->netcore folder, we see Azure.Core.dll (version 1.25) and Azure.Identity.dll (version 1.700). These dlls appear to be quite old. Additionally, Azure.Identity 1.7 is tagged as vulnerable on Nuget.
I am trying to access Azure blobs similar to @Martin_Levett above within the GH environment. It does not appear I can get the specific GH component to point at my component’s Azure dll instead of using the primary rhino one in that folder.
Does anyone have a simplified working code of a GH component that utilizes specific assembly loading that we can use as boilerplate?
It looks like those DLLs were added to Rhino 3 years ago when we added support for .NET 6. I’ve added RH-88733 “Update Azure*.dll” to see if we can update the files, or better, not install them.
We are also facing problems caused by the relatively outdated versions of Azure.Core and Azure.Identity in Rhino 8 (SR 25).
Therefore, I wanted to ask, whether there could be a possibility for this issue to be resolved in an upcoming service release of Rhino 8?
I noticed that a somehow similar issue (Load MSAL.NET >4.52 for SSO broker support) was addressed quite quickly in a Rhino 8 service release, which gives us hope that this might be possible in this case as well.