Sdk: Minimal console app unhandled FileNotFoundException

[mikehaas763]

I installed the mac osx pkg installer from get.asp.net. I then created a very minimal hello world console app. I've ran dotnet restore which appears to have run successfully. Then when I run dotnet run I get this:

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Console, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

[mikehaas763]

project.json:

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

    "dependencies": {
        "System.Console": "4.0.0-beta-*",
        "System.Runtime": "4.0.21-beta-*"
    },

    "frameworks": {
        "dnxcore50": { }
    }
}

[adrian17]

Same issue on Debian, both Jessie and Stretch (future release).

Edit: apparently the docs are out of date?

[blackdwarf]

The docs are now updated as well as the samples. Confirmed that new project.json make the samples work on Ubuntu and Windows. However, OS X still fails (El Capitan, 10.11.1) with the above issue.

Also see dotnet/core#26.

/cc @davidfowl @piotrpMSFT @brthor

[TheRealPiotrP]

@mikehaas, can you confirm @blackdwarf updates and let us know if this can be closed?

[mikehaas763]

@blackdwarf what are the doc updates you've made? Is it the change from manually creating a project.json file to just using dotnet init ?

[dlech]

Here are the changes: https://github.com/dotnet/core/commit/c61177243a0387832666e25d2a8d2bc64d43bedf

[mikehaas763]

@dlech thanks for pointing me to the change

@piotrpMSFT Yes I confirm that the docs were updated, but do you really want to have this bug closed before it's fixed when it's being referenced in the Beta-Jan milestone?

[jgowdy]

Still seems broken:

user@host:~/hello$ dotnet run

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Console, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

user@host:~/hello$ cat project.json
{
"version": "1.0.0-*",
"compilationOptions": {
"emitEntryPoint": true
},

"dependencies": {
    "Microsoft.NETCore.Runtime": "1.0.1-beta-*",
    "System.IO": "4.0.11-beta-23516",
    "System.Console": "4.0.0-beta-*",
    "System.Runtime": "4.0.21-beta-*"
},

"frameworks": {
    "dnxcore50": { }
}

}

user@host:~/hello$ cat /etc/issue
Ubuntu 15.04 n \l

[blackdwarf]

Is this on os x @jgowdy?

[jgowdy]

Ubuntu 15.04

[jgowdy]

I just reinstalled with Ubuntu 14.04 LTS and can no longer reproduce the problem after changing System.IO to "4.0.11-beta-*" Specifically targeting 23516 wasn't needed.

Edit: Reinstalled 15.04 from scratch, problem exists. Can't be related to previous installs.

So Ubuntu 14.04 LTS works, 15.04 installs but fails to run with:

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Console, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

and 15.10 won't install at all due to the dependency issue I reported here:

https://github.com/dotnet/cli/issues/308

[jgowdy]

OSX 10.11.1 El Capitan:

Jeremiahs-MacBook-Pro:hello jgowdy$ dotnet run

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Console, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

[TheRealPiotrP]

Ok, yea, we will take a look.

[anurse]

This is all due to our extremely minimal support of RIDs (see https://github.com/dotnet/cli/blob/master/src/Microsoft.DotNet.ProjectModel/RuntimeIdentifier.cs and https://github.com/dotnet/cli/blob/master/scripts/_common.sh#L68)

We need to port the runtime identification code DNX has over, but that was heavily P/Invoke dependent. We are hoping to get an API in CoreFX we can use (https://github.com/dotnet/cli/issues/185#issuecomment-156205814)

/cc @davidfowl

[adrian17]

For impatient Ubuntu non-LTS users, there is an ugly unsafe temporary workaround: edit /etc/os-release and change the following values:

ID=ubuntu
VERSION_ID="14.04"

Then rerun dotnet restore (remember to change os-release back to its original version immediately afterwards!). After this, dotnet run properly runs a minimal console application. I tested it on Ubuntu 15.10, 15.04 and Debian.

[TomPoulton]

I'm seeing this on Mac OSX as well (El Capitan 10.11.1)

$ dotnet init
Created new project in /Users/... etc ...
$ ls
Program.cs  project.json
$ dotnet restore
Microsoft .NET Development Utility CoreClr-x64-1.0.0-rc1-16048

  CACHE https://www.myget.org/F/aspnetvnext/api/v2/
  CACHE https://www.nuget.org/api/v2/
Restoring packages for /Users/tom/... etc ...
... etc ...
$ dotnet run

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Console, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

[davidfowl]

Yes El Capitan restore is broken. To work around it you have to do dotnet restore --runtime osx.10.10-x64

[davidfowl]

@anurse We need to fix this.

[TomPoulton]

I think you meant dotnet restore --runtime osx.10.10-x64 ;) but yes that worked!

[rogah]

El Capitan (10.11.1) restore is broken. The work around worked for now but it's frustrating though.

[anurse]

I'm actively working on improving the OS detection by porting some DNX code. Probably not going to be fully integrated until early next week, but it's on the way :).

[jgowdy]

@anurse Excellent, thank you.

[brthor]

@anurse Nice! :smile: We need that

[TomPoulton]

This is such a surreal experience, conversing with Microsoft on GitHub about a .NET bug on Mac OSX! Love it :)
Thanks for the quick turnaround @anurse

[blackdwarf]

@anurse is this the same as dotnet/cli#498? Should we close this one?

[anurse]

Kinda. They both refer to the same problem: We need accurate RID detection. Neither really captures that fully. Maybe create a new bug with that and dupe these to that bug.

[ochowie]

@anurse Will this fix the issue on Ubuntu 15.04. I can confirm that the temporary fix @adrian17 proposed works but it's really not a sustainable solution.

[anurse]

It should

[blackdwarf]

@anurse is the change you mention above done?

[VivekRagunathan]

Same error here on my mac:

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Console, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

I tried setting this: DOTNET_HOME=/usr/local/share/dotnet/ too as suggested in one of the forums.

No solution yet? Any workarounds?

[dlech]

Please read/search the previous comments. Someone is working on it, but it is not fixed yet. There are several workarounds that have been mentioned, including one for El Capitan.

[VivekRagunathan]

Yes I already did. I am running on OSX 10.11.2, and the dotnet restore --runtime osx.10.10-x64 does not work its magic. I guess I will have to wait for the real fix.

[dlech]

FWIW, I just updated to OS X 10.11.2 and dotnet restore --runtime osx.10.10-x64 still works for me.

[anurse]

The pre-requisite change in the PlatformAbstractions library is done, but I wasn't able to get the necessary changes made to dotnet-cli before leaving for the holidays.

[blackdwarf]

@anurse thanks for the update! :)

[simranjitr]

I did the following (on OSX 10.11.2) to get the basic 'dotnet new' generated program up and running:

#

export DOTNET_HOME=/usr/local/share/dotnet/

#

project.json

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

"dependencies": {
    "System.Console": "4.0.0-beta-*", 
    "System.IO": "4.0.11-beta-*",
    "System.Runtime": "4.0.21-beta-*" 
},

"frameworks": {
    "dnxcore50": { }
}

}

$dotnet restore --runtime osx.10.10-x64
$dotnet run

which worked.

Specifying --runtime osx.10.11-x64, fails with 'Could not load assembly System.Console 4.0.0.0' error.

[anurse]

Yeah, that's because dotnet-restore knows about osx.10.11 and so it puts that in the lock file, but dotnet-run does not, so it's looking for osx.10.10 :). It's exactly the issue I'm working on resolving in dotnet/cli#498

[anurse]

Should be fixed when dotnet/cli#498 is closed. If not, please feel free to reopen!

[loic-sharma]

Hey, seems like this bug is back:

$ dotnet new
Created new project in  /Users/sharmaloic/Code/REPL
$ dotnet restore
Microsoft .NET Development Utility CoreClr-x64-1.0.0-rc1-16231

  CACHE https://api.nuget.org/v3/index.json
Restoring packages for /Users/sharmaloic/Code/REPL/project.json
  GET https://api.nuget.org/v3-flatcontainer/microsoft.netcore.runtime/index.json
  GET https://api.nuget.org/v3-flatcontainer/system.io/index.json
  GET https://api.nuget.org/v3-flatcontainer/system.console/index.json
  GET https://api.nuget.org/v3-flatcontainer/system.runtime/index.json
  OK https://api.nuget.org/v3-flatcontainer/system.io/index.json 300ms
  OK https://api.nuget.org/v3-flatcontainer/microsoft.netcore.runtime/index.json 525ms
  OK https://api.nuget.org/v3-flatcontainer/system.console/index.json 387ms
  OK https://api.nuget.org/v3-flatcontainer/system.runtime/index.json 433ms
Writing lock file /Users/sharmaloic/Code/REPL/project.lock.json
Restore complete, 7195ms elapsed

NuGet Config files used:
    /Users/sharmaloic/.config/NuGet/nuget.config

Feeds used:
    https://api.nuget.org/v3-flatcontainer/
$ dotnet run

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Console, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
$ dotnet build

Unhandled Exception: System.ComponentModel.Win32Exception: No such file or directory
   at System.Diagnostics.Process.ResolvePath(String filename)
   at System.Diagnostics.Process.StartCore(ProcessStartInfo startInfo)
   at Microsoft.DotNet.Cli.Utils.Command.Execute()
   at Microsoft.DotNet.Cli.Program.Main(String[] args)
Abort trap: 6
$ dotnet restore --runtime osx.10.10-x64
   ....
$ dotnet run
Hello World!

I'm on El Capitan 10.11 and freshly installed the .NET Core SDK Installer linked in the readme.

[salvarubiomartinez]

Same thing happen to me

[BrendanBuono]

Seeing the same with on .NET Core 1.0 Mac OS X

Install via instructions at https://www.microsoft.com/net/core#macos

[VivekRagunathan]

Check all dependencies - openssl etc. Also check the restore command for osx . Alternatively you can try the same with vscode to make sure all deps are ok.

[dlech]

This is still an issue for me on macOS Sierra, following the hello world example from https://www.microsoft.com/net/core#macos.

Following the steps provided in the link, (dotnet new; dotnet restore; dotnet run) I get the exception as described in the first comment of this issue when trying to run with dotnet run. The dotnet restore --runtime osx.10.10-x64 workaround is still required in order to run without throwing an exception.

I assume that I am using the dotnet command from dotnet-dev-osx-x64.1.0.0-preview2-1-003177.pkg that I just installed, but there is no dotnet --version command, so I don't know if I am actually using that version or an old version of dotnet that I installed a year ago.

[blackdwarf]

@dletch we do have the --version option in the CLI. When you say you don't uave it what do you mean by that?

[dlech]

I'm guessing that I have two versions of dotnet installed, one that I installed a year ago and one that I installed today. I haven't been using it in between. The older version must be in $PATH before the newer version. If I run dotnet --version, I get Unknown option: --version.

So, I'm sure this bug is fixed and I am just seeing it still because I am running a very old dotnet that I need to figure out how to uninstall so that it doesn't get in the way of the current version.

[dlech]

If found this script to uninstall the old version, so I am up and running now.

[blackdwarf]

@dlech good, glad to see you're back on track. :)