Powershell: Microsoft.Management.Infrastructure.dll is delay-signed or test-signed

[crabtruckington]

I am trying to use the Microsoft.Management.Infrastructure.dll as a reference in a c# project. I have downloaded the package from nuget (https://www.nuget.org/packages/Microsoft.Management.Infrastructure/) which gives me version 1.0.0.0 . I have the reference included in the build as "Copy Local: True", and it is properly copied to my /bin/ directory.

Everything works in my development environment without issue. However, when I move the compiled output to another machine, I receive an error:

System.IO.FileLoadException: Could not load file or assembly
'Microsoft.Management.Infrastructure, Version=`1.0.0.0. Culture=neutral,
PublicKeyToken=31bf3856ad364e35' or one of its dependencies. Strong name validation failed

I checked the signing with sn.exe and it shows the following:

`.\Microsoft.Management.Infrastructure.dll is a delay-signed or test-signed assembly`

I see that new preview versions are available on the nuget page, but I have a lot of code that relies on the methods in this .dll, and this code is targeting production, so I am very hesitant to include non-release code.

[iSazonov]

@crabtruckington I am not sure that the repo is right place to report the issue. Also the API was deprecated and you should use alternatives.

@TravisEz13 Could you comment about signing MMI?

[crabtruckington]

Whats it been deprecated by? The microsoft docs recommend using Microsoft.Management.Infrastructure over what I was using before, System.Management ( https://docs.microsoft.com/en-us/windows/win32/wmisdk/connecting-to-wmi-remotely-with-c- ). Docs seem to correspond with the publish date of the assembly on nuget.

Is there something else I should be using to connect to WMI? Target machines are Windows Server 2008 R2 or Server 2012 if that makes a difference. No plans to update them in the near future.

If theres a more appropriate place to report this, my apologies, but the nuget page points to the owner being the Powershell team, and the .dll seems to be included in this repo, though I may be misunderstanding the relationship there.

edit The only 2 objects im using from the assembly are CimInstance and CimSession, so if theres something better that includes those, i'm more than willing to try it.

Connecting to WMI Remotely with C# - Windows applications

As with other languages such as PowerShell, VBScript, or C++, you can use C# to remotely monitor the hardware and software on remote computers.

[TravisEz13]

cc @adityapatwardhan about this issue

[iSazonov]

/cc @SteveL-MSFT Can we close the issue?

[SteveL-MSFT]

We should probably strong name sign this assembly

[TravisEz13]

@SteveL-MSFT The error indicates that this was targeting the full framework. We typically don't strong name sign assemblies when we are intending the binary for .NET Core.

[SteveL-MSFT]

Ok, then let's close this

[TravisEz13]

@crabtruckington When targeting full framework, you should use the binary built into Windows.

[olek539]

Hey guys,

@crabtruckington When targeting full framework, you should use the binary built into Windows.

what if that binary is lacking in Windows?

To clarify: the library in question is also provided by Powershell 3.x installation (correct me here please) - there are systems that do not have it installed out of the box.

This is a real-world situation (problem) where the OS complains about it not being strong-named properly (delay-signed) when I supply that library from your nuget repo.

Could you please refer to that?

[iSazonov]

@olek539 Powershell 3.x is EOL and is not supported.
MMI nuget is a limited version for PowerShell Core only.

[olek539]

Thanks for the reply.
As I understand - Microsoft no longer assigns strong-name to their .Net Core libs.

But the problem still persists - If we choose to provide that library (via nuget) and refer that library (Microsoft.Management.Infrastructure.dll) in our code - when there is no such library provided by the OS, the application will try to load the one provided from nuget. And then the CLR will then throw:
Strong name validation failed

In such case: should we be using the (discouraged) System.Managament namespace instead of Management.Infrastructure?

[iSazonov]

For more information see https://github.com/dotnet/runtime/issues/24803

As workaround you could use mmi.dll from PowerShell distrib.