Sdk: dotnet new project can't restore it's dependencies

Created on 16 Apr 2016  路  34Comments  路  Source: dotnet/sdk

Steps to reproduce

install the latest dotnet cli (x64 windows).
open a console
create a directory "helloworld" (e.g. c:\users{yourname}\documents\helloworld - no spaces in path)

dotnet new
dotnet restore

Expected behavior

Restore packages so that dotnet run will run the app

Actual behavior

log  : Restoring packages for C:\Users\shawn\Documents\helloworld\project.json...
error: Unable to load the service index for source https://www.myget.org/F/aspnetvnext/api/v3/index.json.
error:   An error occurred while sending the request.
error:   The server name or address could not be resolved

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-rc2-002416)

Product Information:
 Version:     1.0.0-rc2-002416
 Commit Sha:  37f00f24e9

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.10586
 OS Platform: Windows
 RID:         win10-x64

nuget.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageRestore>
    <add key="enabled" value="True" />
    <add key="automatic" value="True" />
  </packageRestore>
  <packageSources>
    <add key="RC2" value="https://www.myget.org/F/aspnetvnext/api/v3/index.json" />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
  </packageSources>
  <disabledPackageSources>
  </disabledPackageSources>
  <bindingRedirects>
    <add key="skip" value="False" />
  </bindingRedirects>
  <activePackageSource>
    <add key="RC2" value="true" />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
  </activePackageSource>
  <apikeys>
    <add key="https://www.nuget.org" value="..." />
    <add key="http://nuget.gw.symbolsource.org/Public/NuGet" value="..." />
  </apikeys>
</configuration>
question
Source
picture shawnwildermuth

Most helpful comment

@Petermarcu @shawnwildermuth
I just got it to work, though I can't say I definitely understand the cause. Here is my info and theory:

nuget.config

<configuration>
  <packageSources>
    <add key="dotnet-core" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />
    <add key="AspNetCI" value="https://www.myget.org/F/aspnetcirelease/api/v3/index.json" />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
  </packageSources>
</configuration>

Broken (dotnet new generated)

  "dependencies": {
    "Microsoft.NETCore.App": {
      "type": "platform",
      "version": "1.0.0-rc2-3002416"
    }
  }

Working:

  "dependencies": {
    "Microsoft.NETCore.App": {
      "type": "platform",
      "version": "1.0.0-rc2-*"
    }
  },

In the project.lock.json all of the dependencies in the broken scenario are all referencing rc3. I suspect that something was recently pushed to a myget feed referencing rc3. Something about dotnet restore is potentially not respecting a version lock or something with the way the explicit version is written in project.json. By using the wildcard match, I believe I'm forcing it to respect rc2.

picture markhuber on 16 Apr 2016
👍4

All 34 comments

I missed adding https://dotnet.myget.org/F/dotnet-core/api/v3/index.json to nuget which makes it restore, but still can't build:

Compiling helloworld for .NETCoreApp,Version=v1.0
C:\Users\shawn\Documents\helloworld\project.json(7,31): error NU1002: The dependency Microsoft.CodeAnalysis.Common 1.2.0-beta1-20160202-02 does not support framework .NETCoreApp,Version=v1.0.
C:\Users\shawn\Documents\helloworld\project.json(7,31): error NU1002: The dependency Microsoft.CodeAnalysis.CSharp 1.2.0-beta1-20160202-02 does not support framework .NETCoreApp,Version=v1.0.
C:\Users\shawn\Documents\helloworld\project.json(7,31): warning NU1007: Dependency specified was Microsoft.NETCore.App >= 1.0.0-rc2-3002416 but ended up with Microsoft.NETCore.App 1.0.0-rc3-23909.

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

Time elapsed 00:00:02.5075413

I won't even ask about the reference to RC3 ; )

shawnwildermuth picture shawnwildermuth on 16 Apr 2016

That looks pretty wrong...

davidfowl picture davidfowl on 16 Apr 2016
👎8

I did something wrong, or the result was wrong?

shawnwildermuth picture shawnwildermuth on 16 Apr 2016

+1 - Also seeing this when trying to do a new C# project. I believe it has to do with the new netstandard1.0 platform moniker.

markhuber picture markhuber on 16 Apr 2016

@markhuber can you confirm you have set up the dotnet-core package feed?

Petermarcu picture Petermarcu on 16 Apr 2016

@Petermarcu @shawnwildermuth
I just got it to work, though I can't say I definitely understand the cause. Here is my info and theory:

nuget.config

<configuration>
  <packageSources>
    <add key="dotnet-core" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />
    <add key="AspNetCI" value="https://www.myget.org/F/aspnetcirelease/api/v3/index.json" />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
  </packageSources>
</configuration>

Broken (dotnet new generated)

  "dependencies": {
    "Microsoft.NETCore.App": {
      "type": "platform",
      "version": "1.0.0-rc2-3002416"
    }
  }

Working:

  "dependencies": {
    "Microsoft.NETCore.App": {
      "type": "platform",
      "version": "1.0.0-rc2-*"
    }
  },

In the project.lock.json all of the dependencies in the broken scenario are all referencing rc3. I suspect that something was recently pushed to a myget feed referencing rc3. Something about dotnet restore is potentially not respecting a version lock or something with the way the explicit version is written in project.json. By using the wildcard match, I believe I'm forcing it to respect rc2.

markhuber picture markhuber on 16 Apr 2016
👍4

The change to 1.0.0-rc2-* worked for me. So the project.json being built by the dotnet new is probably at fault, or newer build solves it. If I can get you some info on it, let me know.

shawnwildermuth picture shawnwildermuth on 17 Apr 2016

same here latest cli on Mac OS X. Project wouldn't restore or build.
Once I changes project.json to 1.0.0-rc2-* for core app reference everything worked ok

mikes-gh picture mikes-gh on 17 Apr 2016

I think I see the issue.

@weshaggard I believe you manually push the NetCore.App package back to the dotnet-core feed. The CLI build, meanwhile, always points the dotnet-new template to the just-built version of that package. If that's not propagated immediately to dotnet-core then folks using the NuGet.config workaround are broken.

@shawnwildermuth @markhuber can you try an alternative workaround? Add the following to your NuGet.config:

<add key="dotnet-cli" value="https://dotnet.myget.org/F/dotnet-cli/api/v3/index.json" />
TheRealPiotrP picture TheRealPiotrP on 17 Apr 2016

This is related to dotnet/cli#2545 where we are tracking the recommended workaround. Linking, so we can update the guidance if needed

TheRealPiotrP picture TheRealPiotrP on 17 Apr 2016

Marking as question for 1.0.0-rc2 as this workaround will not be needed once rc2 packages are on NuGet.org.

TheRealPiotrP picture TheRealPiotrP on 17 Apr 2016

@piotrpMSFT - no difference. Here is the packageSources from my nuget.config:

  <packageSources>
    <add key="dotnet.cli" value="https://dotnet.myget.org/F/dotnet-cli/api/v3/index.json" />
    <add key="dotnet.core" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />
    <add key="RC2" value="https://www.myget.org/F/aspnetvnext/api/v3/index.json" />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
  </packageSources>
shawnwildermuth picture shawnwildermuth on 17 Apr 2016

dotnet --info

.NET Command Line Tools (1.0.0-rc2-002416)

Product Information:
 Version:     1.0.0-rc2-002416
 Commit Sha:  37f00f24e9

Runtime Environment:
 OS Name:     Windows
 OS Version:  6.1.7601
 OS Platform: Windows
 RID:         win7-x64

dotnet new

Created new C# project in C:\tmp\bugdotnet.

dotnet restore

log  : Restoring packages for C:\tmp\bugdotnet\project.json...
info :   CACHE https://www.nuget.org/api/v2/FindPackagesById()?id='Microsoft.NETCore.App'
error: Unable to resolve 'Microsoft.NETCore.App (>= 1.0.0-rc2-3002416)' for '.NETCoreApp,Version=v1.0'.
info : Committing restore...
log  : Writing lock file to disk. Path: C:\tmp\bugdotnet\project.lock.json
log  : C:\tmp\bugdotnet\project.json
log  : Restore failed in 175ms.

Errors in C:\tmp\bugdotnet\project.json
    Unable to resolve 'Microsoft.NETCore.App (>= 1.0.0-rc2-3002416)' for '.NETCoreApp,Version=v1.0'.

NuGet Config files used:
    C:\Users\gauthier\AppData\Roaming\NuGet\NuGet.Config

Feeds used:
    https://www.nuget.org/api/v2/

dotnet build

The given key was not present in the dictionary.
smoothdeveloper picture smoothdeveloper on 18 Apr 2016

Is there an system integration test which tries those commands out of a fresh build?

It seems builds shouldn't be green and published if they can't output the "hello world" after the commands I listed.

smoothdeveloper picture smoothdeveloper on 18 Apr 2016

@weshaggard I believe you manually push the NetCore.App package back to the dotnet-core feed. The CLI build, meanwhile, always points the dotnet-new template to the just-built version of that package. If that's not propagated immediately to dotnet-core then folks using the NuGet.config workaround are broken.

The packages only get pushed to dotnet-core and not cli-deps feed but they only get pushed to the dotnet-core feed once all the different OS legs finish building. So if someone picks up the latest and greatest CLI build for a given OS there is a timing issue before the actual matching nuget packages hit the dotnet-core feed. @piotrpMSFT this is that buid synchronization issue you are so dreading to fix :)

weshaggard picture weshaggard on 18 Apr 2016

As a follow-up to try and shed light on some of the mystery. The reason 1.0.0-rc2-* works is because that correctly just picks up the latest rc2 build which will work but the reason why the version dotnet new output doesn't work is because it is putting an rc2 build number higher then any on the feed, because that build hasn't be fully published yet, and so it trys to find it and fails and nuget then takes the next highest one which is an earlier rc3 package which doesn't work with the current tools.

All this will get itself worked out correctly when we finish rc2 and push the final packages to nuget.org.

weshaggard picture weshaggard on 18 Apr 2016

The reason 1.0.0-rc2-* works is because that correctly just picks up the latest rc2 build

@weshaggard Until rc2 releases, do we get the same effect using 1.0.0-* if we aren't using the dotnet-core and/or dotnet-cli feeds but instead just using the aspnetcirelease feed?

guardrex picture guardrex on 19 Apr 2016

@GuardRex I'm not sure of the current state of the aspnetcirelease feed so I cannot say if that would work or not. In general I would avoid 1.0.0-* though because it might find an RC3 package which doesn't currently work with CLI tools.

weshaggard picture weshaggard on 19 Apr 2016

@weshaggard Seems to be the way things are working ... aspnetcirelease is stabilization for rc2-final. I just ran a test with it, and no rc3 packages came down, and this would also explain why my shared framework app with Microsoft.NETCore.App/1.0.0-* didn't hit this issue ... it pulled rc2 due to my feed. I'm good ... we just get a lot of questions about this from devs coming in new to .NET Core on JabbR.

guardrex picture guardrex on 19 Apr 2016

This will be fixed once RC2 packages are on NuGet.

TheRealPiotrP picture TheRealPiotrP on 20 Apr 2016

created a Helloworld app.Dotnet restore fails to restore packages

My nuget.config 

<add key="AspNetCI" value="https://www.myget.org/F/aspnetcirelease/api/v3/index.json" />
<add key="NuGet.org" value="https://api.nuget.org/v3/index.json" />

project.json

{
"version": "1.0.0-*",
"compilationOptions": {
"emitEntryPoint": true
},
"dependencies": {
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.0-rc2-23931"
}
},
"frameworks": {
"netcoreapp1.0": {}
}
}

ibrmohammed picture ibrmohammed on 22 Apr 2016

Unfreeze the version of that package ...

"dependencies": {
    "Microsoft.NETCore.App": {
        "type": "platform",
        "version": "1.0.0-*"
    }
},
guardrex picture guardrex on 22 Apr 2016

getting this error

image

ibrmohammed picture ibrmohammed on 22 Apr 2016

Looks like an Internet connection problem. Your NuGet feeds are correct.

guardrex picture guardrex on 22 Apr 2016

Ok. So the dotnet restore depends on internet speed.Because i am constantly getting timeout errors.

ibrmohammed picture ibrmohammed on 22 Apr 2016

Possibly. That hasn't been a reported problem generally ... actually, this is the first time I've seen it be a consistent problem. Are you on a very slow connection there?

guardrex picture guardrex on 22 Apr 2016

yes. looks like that.

ibrmohammed picture ibrmohammed on 22 Apr 2016

hummmmm .... I'm having a problem restoring an app here, too. Let me check online and see what's what.

guardrex picture guardrex on 22 Apr 2016

My internet speed test shows download speed of 1mbps. That should be fine!!

ibrmohammed picture ibrmohammed on 22 Apr 2016

https://github.com/dotnet/cli/issues/2552 ... check the spelling of your TFM in project.json

guardrex picture guardrex on 22 Apr 2016

I was getting the same error on Visual studio 2015 Update 2. I noticed that I had a telerik feed configured and the error message was showing this one (It was not the default one), removed it and that fixed the problem without having to add a Nuget.Config.

rsantos16 picture rsantos16 on 20 May 2016

Install pre-requisites
In order to use .NET Core, you need to install the updated version of OpenSSL, from Homebrew. After installing brew, do the following:

brew update
brew install openssl
brew link --force openssl

chemitaxis picture chemitaxis on 27 May 2016
👍2

@chemitaxis That worked for me. Thanks!

WoojO picture WoojO on 11 Jun 2016

That worked for me too. Thanks

babatopeoni picture babatopeoni on 17 Jun 2016
Was this page helpful?
0 / 5 - 0 ratings

Related issues

Pilchie picture Pilchie  路  68Comments
timotyweis picture timotyweis  路  81Comments
ghost picture ghost  路  210Comments
dasMulli picture dasMulli  路  138Comments
ericstj picture ericstj  路  54Comments