Sdk: Cannot restore packages for self-contained application on macOS Sierra 10.12-x64

Created on 23 Sep 2016  路  24Comments  路  Source: dotnet/sdk

On macOS Sierra I cannot restore packages for a dotnet app that I build as a self-contained/standalone app.

Steps to reproduce

This is what my project.json file looks like in order to build it self-contained:

...
"Microsoft.NETCore.App": {
      "version": "1.0.1"
}
...
"runtimes": {
    "win10-x64": {},
    "win8-x64": {},
    "osx.10.10-x64": {},
    "osx.10.11-x64": {
      "#import": [ "osx.10.11", "osx.10.10-x64" ]
    },
    "osx.10.12-x64": {
      "#import": [ "osx.10.12", "osx.10.11-x64" ]
    },
    "debian.8-x64": {}
},

dotnet restore

Expected behavior

restore command to complete successfully

Actual behavior

The following errors occur during the restore

error: System.Threading.Timer 4.0.1 provides a compile-time reference assembly for System.Threading.Timer on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Diagnostics.Process 4.1.0 provides a compile-time reference assembly for System.Diagnostics.Process on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Globalization.Extensions 4.0.1 provides a compile-time reference assembly for System.Globalization.Extensions on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.IO.FileSystem.Watcher 4.0.0 provides a compile-time reference assembly for System.IO.FileSystem.Watcher on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.IO.MemoryMappedFiles 4.0.0 provides a compile-time reference assembly for System.IO.MemoryMappedFiles on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Net.NameResolution 4.0.0 provides a compile-time reference assembly for System.Net.NameResolution on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Net.Requests 4.0.11 provides a compile-time reference assembly for System.Net.Requests on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Net.Security 4.0.0 provides a compile-time reference assembly for System.Net.Security on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Security.Cryptography.Algorithms 4.2.0 provides a compile-time reference assembly for System.Security.Cryptography.Algorithms on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Security.Cryptography.Encoding 4.0.0 provides a compile-time reference assembly for System.Security.Cryptography.Encoding on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Security.Cryptography.X509Certificates 4.1.0 provides a compile-time reference assembly for System.Security.Cryptography.X509Certificates on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Collections 4.0.11 provides a compile-time reference assembly for System.Collections on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Runtime 4.1.0 provides a compile-time reference assembly for System.Runtime on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Runtime.Extensions 4.1.0 provides a compile-time reference assembly for System.Runtime.Extensions on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.IO 4.1.0 provides a compile-time reference assembly for System.IO on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Reflection.Extensions 4.0.1 provides a compile-time reference assembly for System.Reflection.Extensions on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Text.Encoding 4.0.11 provides a compile-time reference assembly for System.Text.Encoding on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Diagnostics.Debug 4.0.11 provides a compile-time reference assembly for System.Diagnostics.Debug on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Globalization 4.0.11 provides a compile-time reference assembly for System.Globalization on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Net.Primitives 4.0.11 provides a compile-time reference assembly for System.Net.Primitives on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Runtime.InteropServices 4.1.0 provides a compile-time reference assembly for System.Runtime.InteropServices on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Threading.Tasks 4.0.11 provides a compile-time reference assembly for System.Threading.Tasks on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Runtime.InteropServices.RuntimeInformation 4.0.0 provides a compile-time reference assembly for System.Runtime.InteropServices.RuntimeInformation on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Resources.ResourceManager 4.0.1 provides a compile-time reference assembly for System.Resources.ResourceManager on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.IO.FileSystem 4.0.1 provides a compile-time reference assembly for System.IO.FileSystem on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Console 4.0.0 provides a compile-time reference assembly for System.Console on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Reflection 4.1.0 provides a compile-time reference assembly for System.Reflection on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Diagnostics.Tracing 4.1.0 provides a compile-time reference assembly for System.Diagnostics.Tracing on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Reflection.Primitives 4.0.1 provides a compile-time reference assembly for System.Reflection.Primitives on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: Microsoft.Win32.Primitives 4.0.1 provides a compile-time reference assembly for Microsoft.Win32.Primitives on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Diagnostics.Tools 4.0.1 provides a compile-time reference assembly for System.Diagnostics.Tools on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Globalization.Calendars 4.0.1 provides a compile-time reference assembly for System.Globalization.Calendars on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.IO.Compression 4.1.0 provides a compile-time reference assembly for System.IO.Compression on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Net.Http 4.1.0 provides a compile-time reference assembly for System.Net.Http on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Net.Sockets 4.1.0 provides a compile-time reference assembly for System.Net.Sockets on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Runtime.Handles 4.0.1 provides a compile-time reference assembly for System.Runtime.Handles on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Text.Encoding.Extensions 4.0.11 provides a compile-time reference assembly for System.Text.Encoding.Extensions on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: Microsoft.Win32.Registry 4.0.0 provides a compile-time reference assembly for Microsoft.Win32.Registry on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: System.Security.Principal.Windows 4.0.0 provides a compile-time reference assembly for System.Security.Principal.Windows on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.
error: One or more packages are incompatible with .NETCoreApp,Version=v1.0 (osx.10.12-x64).

Environment data

dotnet --info output:

$ dotnet --info
.NET Command Line Tools (1.0.0-preview2-003131)

Product Information:
 Version:            1.0.0-preview2-003131
 Commit SHA-1 hash:  635cf40e58

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.12
 OS Platform: Darwin
 RID:         osx.10.12-x64

If I remove the 10.12-x64 runtime reference and add "type": "platform" to the app declaration I am able to restore and run. This was working as a self contained app on osx10.11.

Most helpful comment

A quick workaround to get folks unblocked:

You can set DOTNET_RUNTIME_ID=osx.10.11-x64 environment variable, and that will tell the CLI to use that RID. This will allow you to restore, build, run, publish as normal.

NOTE: a real fix is in the works. This is just a workaround until the fix is available.

All 24 comments

@rrelyea @yishaigalatzer

I don't believe the #import syntax you are using actually works in the project.json. @rrelyea / @yishaigalatzer can confirm.

We are adding the osx.10.12 runtimes in our next release. In this case, you can just continue to restore and publish for osx.10.11 and run on 12. Is just an association, all the resulting binaries are the same between the OS's.

You should be able to leave type platform off and still publish standalone if your project.json is like this (no need to update it for Sierra assuming you don't have Sierra specific assets):

"runtimes": {
    "win10-x64": {},
    "win8-x64": {},
    "osx.10.10-x64": {},
    "osx.10.11-x64": {},
    "debian.8-x64": {}
},

In fact, I think you can take osx10.10-x64 out at this point too unless you still care to run there.

This does not work for me. Without osx.10.12-x64 in the runtimes i get

Can not find runtime target for framework '.NETCoreApp,Version=v1.0' compatible with one of the target runtimes: 'osx.10.12-x64'. Possible causes:
1. The project has not been restored or restore failed - run `dotnet restore`
2. The project does not list one of 'osx.10.12-x64' in the 'runtimes' section.
3. You may be trying to publish a library, which is not supported. Use `dotnet pack` to distribute libraries.

And with i get the error described by op.

@dknaack , Can you share your project.json?

Yes, sure.

Its a Asp.NET Application

{
  "version": "1.0.0",
  "dependencies": {
    "Microsoft.ApplicationInsights.AspNetCore": "1.0.0",
    "Microsoft.AspNetCore.Server.IISIntegration": "1.0.0",
    "Microsoft.Extensions.Configuration.EnvironmentVariables": "1.0.0",
    "Microsoft.Extensions.Configuration.FileExtensions": "1.0.0",
    "Microsoft.Extensions.Configuration.Json": "1.0.0",
    "Microsoft.Extensions.Logging": "1.0.0",
    "Microsoft.Extensions.Logging.Console": "1.0.0",
    "Microsoft.Extensions.Logging.Debug": "1.0.0",
    "Microsoft.Extensions.Options.ConfigurationExtensions": "1.0.0",
    "Microsoft.EntityFrameworkCore.Tools": "1.0.0-preview2-final",
    "FluentScheduler": "5.0.0",
    "System.Linq": "4.1.0",
    "IdentityServer4.AccessTokenValidation": "1.0.1-rc1",
    "Microsoft.AspNetCore.Identity.EntityFrameworkCore": "1.0.0",
    "Blazingo.AspNetCore.Mvc.Redis": "1.3.0",
    "Blazingo": "1.3.4",
    "Blazingo.Models": "1.3.7",
    "System.Net.Http": "4.1.0",
    "IdentityServer4.AspNetIdentity": "1.0.0-rc1-update2",
    "Microsoft.AspNetCore.Mvc": "1.0.1",
    "Microsoft.AspNetCore.Server.Kestrel": "1.0.1",
    "Microsoft.EntityFrameworkCore.Sqlite": "1.0.1",
    "Microsoft.EntityFrameworkCore.SqlServer": "1.0.1",
    "Microsoft.NETCore.App": "1.0.1",
    "MailKit": "1.6.0",
    "Swashbuckle": "6.0.0-beta901",
  },

  "tools": {
    "Microsoft.AspNetCore.Server.IISIntegration.Tools": "1.0.0-preview2-final",
    "Microsoft.EntityFrameworkCore.Tools": "1.0.0-preview2-final",
    "Microsoft.DotNet.Watcher.Tools": "1.0.0-preview3-*"
  },

  "frameworks": {
    "netcoreapp1.0": {
      "imports": [
        "dotnet5.6",
        "portable-net45+win8"
      ]
    }
  },

  "buildOptions": {
    "emitEntryPoint": true,
    "preserveCompilationContext": true,
    "xmlDoc": true
  },

  "runtimeOptions": {
    "configProperties": {
      "System.GC.Server": true
    }
  },

  "publishOptions": {
    "include": [
      "wwwroot",
      "Views",
      "Areas/**/Views",
      "appsettings.json",
      "appsettings.**.json",
      "web.config",
      "idsvr3test.pfx"
    ]
  },

  "runtimes": {
    "win10-x64": {},
    "win8-x64": {},
    "osx.10.11-x64": {},
    "debian.8-x64": {}
  }
}


without osx.10.12-x64 listed in your runtimes, I'm not sure where the tools would even get that string for the error. That comes from the runtimes section. What command are you running? Are you running dotnet restore on the project.json with no osx.10.12-x64 in the runtimes section?

Ive run dotnet restore and then dotnet run.

I experience the same error when running it without osx.10.12-x64 in the
runtimes section. The restore command completes but run command fails with
the error posted by @dknaack.

Yes, I'm seeing the same problems now too. @brthor , @livarcocc , can you take a look at this? Both dotnet build and dotnet publish are not working on 10.12 despite the project.json not saying anything about 10.12. Is something in the CLI still inferring the runtime?

Simple repro is dotnet new and replace project.json with this:

{
  "version": "1.0.0-*",
  "buildOptions": {
    "debugType": "portable",
    "emitEntryPoint": true
  },
  "dependencies": {},
  "frameworks": {
    "netcoreapp1.0": {
      "dependencies": {
        "Microsoft.NETCore.App": "1.0.0"
      }
    }
  },
  "runtimes": {
    "win10-x64": {},
    "win8-x64": {},
    "osx.10.11-x64": {},
    "debian.8-x64": {}
  }
}

A quick workaround to get folks unblocked:

You can set DOTNET_RUNTIME_ID=osx.10.11-x64 environment variable, and that will tell the CLI to use that RID. This will allow you to restore, build, run, publish as normal.

NOTE: a real fix is in the works. This is just a workaround until the fix is available.

Thanks - that works for me.

This is fixed by dotnet/cli#4281 and will be in our next release.

I have tried setting the environment variable to DOTNET_RUNTIME_ID=osx.10.11-x64 but this either hasn't worked or I have set it incorrectly? I added it to .bash_profile?

@andrew6767 - what was the command you tried running that didn't work? And what was the error?

@andrew6767 using .bash_profile worked for me.
A few things to try if you're still having issues:

  1. echo $DOTNET_RUNTIME_ID if "osx.10.11-x64" is printed to the console then you've set the value correctly.

    • If not



      1. Verify your export in your .bash_profile export DOTNET_RUNTIME_ID=osx.10.11-x64


      2. Restart terminal


      3. Retry echo



  2. If missing from project.json runtimes: add osx.10.11-x64
  3. If present in project.json runtimes remove osx.10.12-x64
  4. Retry dotnet restore

Good luck 馃憤

The DOTNET_RUNTIME_ID environment variable doesn't seem to work for me either.

I removed the osx.10.12-x64 runtime from the project.json. I tried this command:

DOTNET_RUNTIME_ID=osx.10.11-x64 dotnet restore

And also tried to globally set the env variable in my .zshrc, and I verified that echo $DOTNET_RUNTIME_ID prints the correct value.

Both ways I'm still getting a bunch of

error: System.IO 4.1.0 provides a compile-time reference assembly for System.IO on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with osx.10.12-x64.

error messages for various packages.

What can be the reason why dotnet is not picking up the specify runtime?

Removing osx.10.12-x64 from the list of runtime identifiers works for me. But I wonder why is osx.10.12-x64 listed in the RID catalog if it's not yet supported (not even in a preview version of the CLI)? Please correct me if there is a preview out there supporting it. The October 2016 Update does not list support for the osx.10.12-x64 RID in the release notes. Is there a preview out there that I'm not seeing @eerhardt?

@nathanielcook - sorry I've been on vacation and just getting through my inbox now. Is this still an issue?

@eerhardt Yes, it is still an issue. I have switched to the msbuild based preview 3 of the CLI and dotnet restore for <RuntimeIdentifiers>osx.10.11-x64</RuntimeIdentifiers> succeeds, while <RuntimeIdentifiers>osx.10.12-x64</RuntimeIdentifiers> fails with there is no run-time assembly compatible with osx.10.12-x64.

~$ dotnet --info
.NET Command Line Tools (1.0.0-preview3-004056)

Product Information:
 Version:            1.0.0-preview3-004056
 Commit SHA-1 hash:  ccc4968bc3

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.12
 OS Platform: Darwin
 RID:         osx.10.11-x64

Again, seems like osx.10.12-x64 should not be listed in the RID catalog if it's not supported.

@blackdwarf You are one of the author of RID catalog and while we support using the CLI in OSX 10-12, that is not really a valid rid to be specified in the RIDs section. Can you please fix the article?

@livarcocc so how do people build SCDs for Sierra? Using El Capitan RID?

you target os.10.11-x64. Corefx does not have a separate rid for osx.10.12-x64.

It does have a RID for osx.10.12, but only if you are targeting netcoreapp1.1 and Microsoft.NETCore.App 1.1.0.

https://github.com/dotnet/corefx/blob/73bf061349650cecd6df04fecce7f073b9cf584d/pkg/Microsoft.NETCore.Platforms/runtime.json#L175-L180

netcoreapp1.0 shipped before OSX 10.12, so that wasn't a fully-supported OS version for netcoreapp1.0.

@nathanielcook - can you try targeting netcoreapp1.1 and see if you continue having problems?

Ah, fantastic. I did not remember that. Then I guess we just need to update the blog to say 10.12 for netcoreapp1.1 and Microsoft.NETCore.App 1.1, if it does say so already.

@eerhardt Changed TargetFramework to netcoreapp1.1 and the Microsoft.NETCore.App PackageReference Version to 1.1.0 and now dotnet restore succeeds; thank you for that! That makes sense now.

Was this page helpful?
0 / 5 - 0 ratings