){outline:none;box-shadow:none;}select::-ms-expand{;}:root,:host{--chakra-vh:100vh;}@supports (height: -webkit-fill-available){:root,:host{--chakra-vh:-webkit-fill-available;}}@supports (height: -moz-fill-available){:root,:host{--chakra-vh:-moz-fill-available;}}@supports (height: 100dvh){:root,:host{--chakra-vh:100dvh;}}
Link to home
Create Account Log in
Windows OS

Windows OS

--

Questions

--

Followers

Top Experts

Avatar of jxbma
jxbma 🇺🇸

Why does running Powershell in a .NetCore app on Windows Server 2019 throws a missing Microsoft.Management.Infrastructure exception?


We have a simple .NetCore console application that is attempting to use .Net Powershell.

We are trying to run this app on a Windows Server 2019 VM.


It works as expected when run through Visual Studio 2022 on a 2019 VM.


We created a ClickOnce (SelfContained) publish profile to install/test it on other Windows 2019 server VMs.

When running via the ClickOnce install, we get an exception.



This the exception:

Could not load file or assembly 'Microsoft.Management.Infrastructure,

Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.

The system cannot find the file specified.

Third exception at close: Could not load file or assembly

'Microsoft.Management.Infrastructure, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.

The system cannot find the file specified.


Here are the NuGet packages for the project:

  <ItemGroup>
    <PackageReference Include="Microsoft.PowerShell.SDK" Version="7.3.4" />
  </ItemGroup>

Open in new window



Here is the sample code snippet:


PowerShell? psInstance = null;
   psInstance = PowerShell.Create();
   psInstance.AddScript(@"Get-Service");
   var results = psInstance.Invoke();
   if (!results.Any() && psInstance.HadErrors)
      // Display Error Text
   psInstance.Runspace?.Close();
catch (Exception e)
      Console.WriteLine($"First exception: {e.Message}");
      if (psInstance?.Runspace.RunspaceStateInfo.State == RunspaceState.Opened)
         psInstance?.Runspace?.Close();
   catch (Exception ex)
      Console.WriteLine($"Second exception at close: {ex.Message}");
}

Open in new window


It feels like we are missing some dlls/packages that should be included as part of the deployment?


I thought adding the package through NuGet would also install any additionally required dependencies.


Zero AI Policy

We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.


I made a few queries regarding the .NET Core platform agnostic software, which is an departure from Microsoft's previous ".NET Framework" and the following criteria regarding PowerShell scripts jumps out at me right away.


"Execution Policy: PowerShell has an execution policy that restricts the running of scripts. Depending on your environment, you may need to change the execution policy to allow script execution. Be cautious when modifying execution policies as it can pose security risks." so when the PowerShell script is invoked from within Visual Studio 2022 , that software is the owning Process and I believe the script would be launched and Run under the authority of it. (a spawned sub-processes if that is the correct description.)


Yes, a .NET Core application can invoke a PowerShell script. This can be done using the System.Diagnostics.Process class in C# to start a new PowerShell process and execute your script. Here's a basic example:


using System.Diagnostics;
class Program
    static void Main()
        string scriptPath = "C:\\Path\\To\\YourScript.ps1";
        ProcessStartInfo psi = new ProcessStartInfo
            FileName = "powershell.exe",
            RedirectStandardInput = true,
            RedirectStandardOutput = true,
            RedirectStandardError = true,
            UseShellExecute = false,
            CreateNoWindow = true
        using (Process process = new Process { StartInfo = psi })
            process.Start();
            // You can pass your script commands here
            process.StandardInput.WriteLine($"& \"{scriptPath}\"");
            process.WaitForExit();
            // Read the output and error streams if needed
            string output = process.StandardOutput.ReadToEnd();
            string error = process.StandardError.ReadToEnd();
            Console.WriteLine("Output:");
            Console.WriteLine(output);
            Console.WriteLine("Error:");
            Console.WriteLine(error);
}

Open in new window

Does this sound like a consideration that has been included / incorporated into the process?



Avatar of Dennis Costea Jr. Dennis Costea Jr. 🇺🇸

It does look as though NuGet would help eliminate Package dependencies but, that may not be all that is needed.


(Sent you a 'Not-yet-ready-for-Primetime' answer in Messages here on E-E.  Hope it helps.)



Avatar of jxbma jxbma 🇺🇸

ASKER

@Dennis - Thx for the reply. I will try this out. The console app I created was an attempt to isolate/debug/test the issue.


In our real application, we actually use Powershell via the Microsoft.Powershell.SDK in a . NetCore service.

I'm not sure how the solution of spinning up a process and running the script will actually fly.


I guess I have1 naive question is, in this scenario is the Powershell script required to be run from a script file or can I just run the script directly?


I know that in a previous release, we were using .Net6.0 and the Microsoft.Powershell.SDK . After some fiddling around we were get it to work in that environment.

In that application, the Powershell module was not run from within a service, but rather directly in the application.


As I mentioned above, in the new release, we are service based using .Net7.0 and the Microsoft.Powershell.SDK 7.3.6 .

I will try the potential work around, but ideally our preferred solution would be to use this configuration.


Any suggestions on how to best proceed?


Thx


Reward 1 Reward 2 Reward 3 Reward 4 Reward 5 Reward 6

EARN REWARDS FOR ASKING, ANSWERING, AND MORE.

Earn free swag for participating on the platform.


Not a .Net developer, but you might want to have a look at these two:
SDK: Missing MMI DLL when publishing SCD targeting portable win RIDs. #7886
https://github.com/PowerShell/PowerShell/issues/7886
System.IO.FileNotFoundExce ption: Could not load file or assembly 'Microsoft.Management.Infr astructure , Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad3 64e35' #7909
https://github.com/PowerShell/PowerShell/issues/7909
Seems like you need to specify the target platform explicitly as win[7|8|10]-x64, instead of just  win-x64, either by changing the RuntimeIdentifier in your /Properties/<configuration name>.pubxml, or by using "dotnet publish -r win10-x64 ..."

Teamwork!  'Experts' are unstoppable!


Avatar of jxbma jxbma 🇺🇸

ASKER

@oBdA, Dennis:
Thanks for the reply. I'm a little confused as to adding 7|8|10 to my publishing profile.
What effect will that have as our intended platforms are (x64):
- Windows 10

- Windows 11

- Win Server 2016

- Win Server 2019

- Win Server 2022


Should I be expecting to have different settings depending on the specific target system?

.. or is this related to the link saying PowerShell.SDK itself is publishing to Win7-x64, so I should target it as well in order for publishing to work?
This all sort of made sense and sounds promising, but I'm still a little confused.


Thanks