Sdk: Can't resolve System.Management.Automation from GAC for net451 project

Created on 3 Mar 2016  路  9Comments  路  Source: dotnet/sdk

I'm having trouble creating a desktop .NET 4.5.1 console application that references the PowerShell API DLL System.Management.Automation. When I set my frameworkAssemblies to refer to this DLL I get a compiler error. I also notice that Visual Studio's completion results don't contain this DLL:

image

What am I doing wrong?

Steps to reproduce

  1. Create a new console app project using dotnet new.
  2. Update project.json to the contents below
  3. Run dotnet restore
  4. Run dotnet compile

project.json

{
    "version": "1.0.0-*",
    "compilationOptions": {
        "emitEntryPoint": true
    },

    "frameworks": {
        "net451": {
          "frameworkAssemblies": {
            "System.Management.Automation": ""
          }
        }
    }
}

Expected behavior

Code compiles successfully, resolves System.Management.Automation.dll.

Actual behavior

Compile error:

PS> dotnet compile
Compiling dotnetrepro for .NETFramework,Version=v4.5.1
C:\dev\dotnetrepro\project.json(10,45): error NU1001: The dependency System.Management.Automation could not be resolved.

Compilation failed.
    0 Warning(s)
    1 Error(s)

Time elapsed 00:00:02.3045736

Environment data

dotnet --version output:

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.11082
 OS Platform: Windows
 Runtime Id:  win10-x64

Most helpful comment

I'm referring to the NuGet packages we released which contain reference assemblies (only metadata):

If you compile a .NET 4.5.x app against one of those NuGet packages then the PowerShell assemblies from the GAC will be loaded in your app at runtime. However, you'll need to compile against the reference assemblies for the version of PowerShell used on the target machine otherwise you might get MissingMethodExceptions, etc. I'd recommend using the PowerShell 5 package if you're targeting Windows 10 machines.

All 9 comments

We don't resolve dependencies from the GAC anymore. Any chance you can put that thing in a package?

Ouch. Can't ship it via NuGet yet unfortunately since we only release those DLLs as part of Windows or the Windows Management Framework.

How do the other frameworkAssemblies options show up? Do they actually refer to NuGet packages for those assemblies?

It's because DNX supported the GAC and the tooling is based on DNX still.

If I use System.Management.Automation.dll from a NuGet package and it refers to DLLs that are in the GAC, will the GAC'ed DLLs be resolved correctly?

Alternatively, is it possible to compile against a reference assembly DLL and then have it load from the GAC at runtime?

Cool, compiling against our official reference assembly packages works. At runtime the correct DLLs are loaded from the GAC.

Thanks for the guidance!

@daviwil I have the same question. What packages does "compiling against our official reference assembly packages" refer to? Presumably not the ancient ones that turn up in nuget when searching for "System.Management.Automation"...

I'm referring to the NuGet packages we released which contain reference assemblies (only metadata):

If you compile a .NET 4.5.x app against one of those NuGet packages then the PowerShell assemblies from the GAC will be loaded in your app at runtime. However, you'll need to compile against the reference assemblies for the version of PowerShell used on the target machine otherwise you might get MissingMethodExceptions, etc. I'd recommend using the PowerShell 5 package if you're targeting Windows 10 machines.

Cool, thanks!

Is this a general case where frameworkAssemblies no longer can reference GAC content? Despite the content up-thread, I ask because the core-docs still mention GAC resolution here: https://github.com/dotnet/core-docs/blob/master/docs/core/tools/project-json.md

Was this page helpful?
0 / 5 - 0 ratings