0

The Issue:

Our application is a .NET 5 Windows Desktop application. The licensing capability requires the application to use the System.Management component from NuGet to create a unique device ID from the system processor ID, MAC Address and BIOS serial number.

This all worked great when testing it from Visual Studio debugger. However, when adding System.Management.dll to the application installer (InstallShield installer) I naturally selected the version of System.Management.dll that was in the app's build target folder. It turns out that the version of the DLL that ends up in that folder is a no-op version that throws not supported exceptions saying "System.Management is supported on Windows Desktop Apps only".

Jeff H
  • 157
  • 11
  • Please edit the question to be a question/definition of the problem and then add the solution as an answer instead of including it in the question. Then it fits the format of the site fine – Sami Kuhmonen Apr 16 '22 at 00:34
  • @SamiKuhmonen, Is there a straight answer site I can post it on? It's useful, obviously. – Jeff H Apr 16 '22 at 02:55
  • @KenWhite, getting a little trigger happy here, I think. I've taken Sami's advice and changed the post to a question, then answered it. – Jeff H Apr 16 '22 at 03:01
  • Not trigger happy at all. I addressed your initial post as you posted it, which was totally incorrect, and I provided information on what you needed to do to fix it, which you've now done (2 hours after I posted my comment). I've retracted my close vote now that you've fixed the question, but next time you might want to be a little more polite when letting people know that you've made a correction. I'd suggest you say something like *Thanks! I've fixed the problem. Would you reconsider your close vote?* – Ken White Apr 16 '22 at 03:23

2 Answers2

1

The Solution:

I found the correct version of System.Management.dll in the build TargetFolder\runtimes\win\lib\netcoreappX.x folder. In my case, since I'm using System.Management version 6.0, it is in the "netcoreapp3.1" folder.

Conclusion

There are many cases where Microsoft doesn't do the right thing. In this case, my application was specifically a .NET 5 Windows Desktop application, so we would all think that msbuild could figure out the correct thing to do. Not so. In such a case, I would have at least hoped that .NET Foundation would have provided information on this. Well, now you all know now, as well!

Cheers

Jeff H
  • 157
  • 11
0

I think perhaps this is because the deps.json file is missing, causing the stub version to be loaded from the application directory, rather than the one from the runtimes directory. So either the desired dependency could be installed to the application root directory, or the existing hierarchy from the build directory could be maintained, but also distributing the dependency configuration.

https://learn.microsoft.com/en-us/dotnet/core/dependency-loading/default-probing

molesmoke
  • 76
  • 1
  • 4