.NET Core 1.0.4 and 1.1.1

leecow commented 7 years ago

Thanks for your interest in .NET Core.

You can read about .NET Core 1.0.4 and 1.1.1 in the .NET blog announcement.

Please report any issues you find with .NET Core 1.0.4 and 1.1.1 here, either responding to this issue or creating a new issue.

Please include the following information plus any other info that you think is relevant:

OS version Repro steps Repro code (if you can share it / is relevant) Error messages Whether this worked before Method of installing .NET Core

Please note that this repo (dotnet/core) is not for filing product issues. Here are some repos where you can file an issue:

dotnet/cli - for CLI tools and questions dotnet/corefx - for API issues and questions dotnet/coreclr - for runtime issues nuget/home - for NuGet questions and issues

portaljacker commented 7 years ago

When running the install steps from https://github.com/dotnet/core/blob/master/release-notes/download-archives/1.1.1-download.md:

sudo sh -c 'echo "deb [arch=amd64] https://apt-mo.trafficmanager.net/repos/dotnet-release/ xenial main" > /etc/apt/sources.list.d/dotnetdev.list'
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 417A0893
sudo apt-get update
sudo apt-get install dotnet-sdk-ubuntu-x64.1.0.1

I get the following error:

portaljacker@vps:~$ sudo apt-get install dotnet-sdk-ubuntu-x64.1.0.1
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package dotnet-sdk-ubuntu-x64.1.0.1
E: Couldn't find any package by glob 'dotnet-sdk-ubuntu-x64.1.0.1'
E: Couldn't find any package by regex 'dotnet-sdk-ubuntu-x64.1.0.1'

Doing dotnet -v returns version 1.0.0-rc4-004771.

portaljacker commented 7 years ago

Seems that it should be sudo apt-get install dotnet-dev-1.0.1

I'll submit a pull request.

Edit: Submitted it, let me know if I'm horribly wrong. #534 Edit 2: It was approved!

enricosada commented 7 years ago

@leecow @kendrahavens is possible to add the f# info from wiki to blog post?

https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-SDK-1.0.1

that add some important info and workarounds (like how fix intellisense 😄 ).

kontomondo commented 7 years ago

On Ubuntu 16.10, with dotnet SDK 1.1.1 (same happening with 1.0.4) when doing (lang is irrelevant): $ dotnet new console -lang f#

I get:

Object reference not set to an instance of an object.
   at Microsoft.TemplateEngine.Cli.New3Command.ParseTemplateArgs(ITemplateInfo templateInfo)
   at Microsoft.TemplateEngine.Cli.New3Command.<EnterSingularTemplateManipulationFlowAsync>d__64.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1.ConfiguredTaskAwaiter.GetResult()
   at Microsoft.TemplateEngine.Cli.New3Command.<EnterTemplateManipulationFlowAsync>d__65.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1.ConfiguredTaskAwaiter.GetResult()
   at Microsoft.TemplateEngine.Cli.New3Command.<ExecuteAsync>d__66.MoveNext()

This worked fine previously with RC4.

livarcocc commented 7 years ago

CC @mlorbetske

mlorbetske commented 7 years ago

@kontomondo could you zip up the directory at ~/.templateengine and mail it to me at mlorbe@microsoft.com please? After zipping it up and moving it out of that directory, please try running dotnet new --debug:reinit, after that runs things should return to working normally

kontomondo commented 7 years ago

@mlorbetske I see what the problem is now -- it got initialised in one directory and then I moved it to another, but the template engine settings still has the old "mount points", so it essentially wasn't able to find the files. It should probably check whether dotnet's path has changed and if so, re-initialise the template engine data ? (or simply when files are not found, attempt to re-init maybe)

kontomondo commented 7 years ago

@enricosada After creating a sample F# application, dotnet restore works, but dotnet build fails with /home/user/.nuget/packages/fsharp.net.sdk/1.0.1/build/FSharp.NET.Core.Sdk.targets(170,9): error MSB6006: "dotnet" exited with code 131

Note that a C# sample application restores builds and runs properly.

This happens for the Ubuntu 16.10 SDK 1.1 download: https://go.microsoft.com/fwlink/?LinkID=843446 The SDK 1.0.4 download for Ubuntu 16.04 seems to be working properly.

mlorbetske commented 7 years ago

@kontomondo we agree, we're actively working on handling these sorts of scenarios

enricosada commented 7 years ago

@kontomondo abouut f#, can you open an issue in https://github.com/dotnet/netcorecli-fsc/issues ? Can you please add redo build with a bit more verbose log? it;s dotnet build -v n ? (just for compiler args, or -v d for more). And dotnet --info to show info about environment

enricosada commented 7 years ago

@kontomondo no need to add issue, probably is the same as https://github.com/dotnet/netcorecli-fsc/issues/91 . check that issue for status updates

kendrahavens commented 7 years ago

@enricosada The F# link was added to the post earlier. :)

enricosada commented 7 years ago

@kendrahavens i cannot find it in that blog post now, but thx anyway. I think will be really good to have that wiki link in the blog post because is about .net core 1.0 tools (that works ok for f#, VS instead not, the wiki give more info exactly about that). but np anyway, it's msdn blog, so until VS fully supports it, is not the target audience

kendrahavens commented 7 years ago

@enricosada Hmm, I can't find it either. @richlander Where did you add https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-SDK-1.0.1 ?

leecow commented 7 years ago

@enricosada - I added the fsharp wiki link to release notes for 1.0.4 and 1.1.1

rogerfar commented 7 years ago

When can we expect 1.1.1 to be pushed to the repositories? I upgraded my project to 1.1.1 but Ubuntu 10.4 is still on 1.1.0.

leecow commented 7 years ago

@yesman85 - I've confirmed that the 1.0.1 SDK and 1.1.1 Runtime are on the feed using for Ubuntu 16.04 and 16.10. You should be able to sudo apt-get update and sudo apt-get install dotnet-dev-1.0.1. I have seen dependency errors in some situations. If you see something like that, apt-get should recommend running sudo apt-get -f install (with no packages referenced) to clean things up.

rogerfar commented 7 years ago

@leecow very odd, I tried multiple times and even with a clean install but it stays on 1.1.1.

When I do an install:

user@ubuntu:~$ sudo apt-get install dotnet-dev-1.0.1
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  dotnet-host dotnet-hostfxr-1.0.1 dotnet-hostfxr-1.1.0 dotnet-sharedframework-microsoft.netcore.app-1.0.4 dotnet-sharedframework-microsoft.netcore.app-1.1.1
The following NEW packages will be installed:
  dotnet-dev-1.0.1 dotnet-host dotnet-hostfxr-1.0.1 dotnet-hostfxr-1.1.0 dotnet-sharedframework-microsoft.netcore.app-1.0.4
  dotnet-sharedframework-microsoft.netcore.app-1.1.1
0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/97.1 MB of archives.
After this operation, 280 MB of additional disk space will be used.
Do you want to continue? [Y/n] Y
Selecting previously unselected package dotnet-host.
(Reading database ... 29386 files and directories currently installed.)
Preparing to unpack .../dotnet-host_1.1.0-preview1-001100-00-1_amd64.deb ...
Unpacking dotnet-host (1.1.0-preview1-001100-00-1) ...
Selecting previously unselected package dotnet-hostfxr-1.0.1.
Preparing to unpack .../dotnet-hostfxr-1.0.1_1.0.1-1_amd64.deb ...
Unpacking dotnet-hostfxr-1.0.1 (1.0.1-1) ...
Selecting previously unselected package dotnet-sharedframework-microsoft.netcore.app-1.0.4.
Preparing to unpack .../dotnet-sharedframework-microsoft.netcore.app-1.0.4_1.0.4-1_amd64.deb ...
Unpacking dotnet-sharedframework-microsoft.netcore.app-1.0.4 (1.0.4-1) ...
Selecting previously unselected package dotnet-hostfxr-1.1.0.
Preparing to unpack .../dotnet-hostfxr-1.1.0_1.1.0-1_amd64.deb ...
Unpacking dotnet-hostfxr-1.1.0 (1.1.0-1) ...
Selecting previously unselected package dotnet-sharedframework-microsoft.netcore.app-1.1.1.
Preparing to unpack .../dotnet-sharedframework-microsoft.netcore.app-1.1.1_1.1.1-1_amd64.deb ...
Unpacking dotnet-sharedframework-microsoft.netcore.app-1.1.1 (1.1.1-1) ...
Selecting previously unselected package dotnet-dev-1.0.1.
Preparing to unpack .../dotnet-dev-1.0.1_1.0.1-1_amd64.deb ...
Unpacking dotnet-dev-1.0.1 (1.0.1-1) ...
Processing triggers for man-db (2.7.5-1) ...
Setting up dotnet-host (1.1.0-preview1-001100-00-1) ...
Setting up dotnet-hostfxr-1.0.1 (1.0.1-1) ...
Setting up dotnet-sharedframework-microsoft.netcore.app-1.0.4 (1.0.4-1) ...
Setting up dotnet-hostfxr-1.1.0 (1.1.0-1) ...
Setting up dotnet-sharedframework-microsoft.netcore.app-1.1.1 (1.1.1-1) ...
Setting up dotnet-dev-1.0.1 (1.0.1-1) ...
user@ubuntu:~$ dotnet

Microsoft .NET Core Shared Framework Host

  Version  : 1.1.0
  Build    : 928f77c4bc3f49d892459992fb6e1d5542cb5e86

Usage: dotnet [common-options] [[options] path-to-application]

Common Options:
  --help                           Display .NET Core Shared Framework Host help.
  --version                        Display .NET Core Shared Framework Host version.

Options:
  --fx-version <version>           Version of the installed Shared Framework to use to run the application.
  --additionalprobingpath <path>   Path containing probing policy and assemblies to probe for.

Path to Application:
  The path to a .NET Core managed application, dll or exe file to execute.

If you are debugging the Shared Framework Host, set 'COREHOST_TRACE' to '1' in your environment.

To get started on developing applications for .NET Core, install the SDK from:
  http://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409

It looks like it installed "dotnet-sharedframework-microsoft.netcore.app-1.1.1", but is it maybe the tooling that is reporting the wrong version?

leecow commented 7 years ago

@yesman85 - First off, everything looks correct so you're in good shape :-). Second, I apologize for our versioning and the way it's reported is unclear and confusing. When you do an install there are three components which can version independently: host, runtime/shared framework and the SDK. All of these can live side-by-side. Trying to organize and tell a coherent story with all of these versions floating around is proving very difficult.

Your apt-get install output indicates the packages included in the 1.0.1 SDK are set up.

Setting up dotnet-host (1.1.0-preview1-001100-00-1) ...
Setting up dotnet-hostfxr-1.0.1 (1.0.1-1) ...
Setting up dotnet-sharedframework-microsoft.netcore.app-1.0.4 (1.0.4-1) ...
Setting up dotnet-hostfxr-1.1.0 (1.1.0-1) ...
Setting up dotnet-sharedframework-microsoft.netcore.app-1.1.1 (1.1.1-1) ...
Setting up dotnet-dev-1.0.1 (1.0.1-1) ...

dotnet will return the Host version (1.1.0) where dotnet --version returns the SDK version. If you poke around the directories under /usr/share/dotnet, you'll probably see a number of installed versions. There is policy in the various components to automatically choose the highest patch version within a minor version "family". So if you have 1.0.1, 1.0.3, 1.0.4 under /shared/Microsoft.NETCore.App, 1.0.4 will be used unless you specifically configure a project to use something different. The same rules apply to the other components.

Hope that brief explanation is helpful.

milla commented 7 years ago

We have projects handling XSD, so we previously only use .net core 1.0 full framework, and wait Q3 .net core 2.0. So in this case, since full version can reference .net framework 4.6.1, so we can have part of projects using .net core 1.0, part of 4.6.1, they work well. But after I upgraded to visual studio 2017, it's said the projects are all not compatible with .netcore1.1, does this mean that .net core 1.1 doesn't support full framework?

nikamsshekhar commented 7 years ago

Hi @leecow , I am trying to install .net core on ubuntu 14.04 LTS. I have installed it fresh and using it first time. I followed steps from here. The .net core version is dotnet-dev-1.0.4. I am getting this log when i run sudo apt-get install dotnet-dev-1.0.4 Reading package lists... Done Building dependency tree
Reading state information... Done E: Unable to locate package dotnet-dev-1.0.4 E: Couldn't find any package by regex 'dotnet-dev-1.0.4'

Here are the logs

user@user-VirtualBox:~$ sudo apt-get update [sudo] password for user: Get:1 http://security.ubuntu.com trusty-security InRelease [65.9 kB] Ign http://in.archive.ubuntu.com trusty InRelease
Ign http://extras.ubuntu.com trusty InRelease
Get:2 http://extras.ubuntu.com trusty Release.gpg [72 B]
Get:3 http://extras.ubuntu.com trusty Release [11.9 kB]
Get:4 http://extras.ubuntu.com trusty/main Sources [14 B]
Get:5 http://extras.ubuntu.com trusty/main i386 Packages [14 B]
Get:6 http://in.archive.ubuntu.com trusty-updates InRelease [65.9 kB]
Get:7 http://security.ubuntu.com trusty-security/main Sources [130 kB]
Get:8 http://security.ubuntu.com trusty-security/restricted Sources [4,941 B] Get:9 http://in.archive.ubuntu.com trusty-backports InRelease [65.9 kB]
Get:10 http://security.ubuntu.com trusty-security/universe Sources [52.5 kB]
Get:11 http://security.ubuntu.com trusty-security/multiverse Sources [3,206 B] Ign http://extras.ubuntu.com trusty/main Translation-en_IN
Ign http://extras.ubuntu.com trusty/main Translation-en
Get:12 http://in.archive.ubuntu.com trusty Release.gpg [72 B] Get:13 http://in.archive.ubuntu.com trusty-updates/main Sources [398 kB]
Get:14 http://in.archive.ubuntu.com trusty-updates/restricted Sources [6,327 B] Get:15 http://in.archive.ubuntu.com trusty-updates/universe Sources [178 kB]
Get:16 http://in.archive.ubuntu.com trusty-updates/multiverse Sources [7,767 B] Get:17 http://in.archive.ubuntu.com trusty-updates/main i386 Packages [937 kB] Get:18 http://in.archive.ubuntu.com trusty-updates/restricted i386 Packages [16.9 kB] Get:19 http://in.archive.ubuntu.com trusty-updates/universe i386 Packages [406 kB] Get:20 http://in.archive.ubuntu.com trusty-updates/multiverse i386 Packages [14.6 kB] Get:21 http://in.archive.ubuntu.com trusty-updates/main Translation-en [484 kB] Get:22 http://in.archive.ubuntu.com trusty-updates/multiverse Translation-en [7,430 B] Get:23 http://in.archive.ubuntu.com trusty-updates/restricted Translation-en [3,975 B] Get:24 http://in.archive.ubuntu.com trusty-updates/universe Translation-en [215 kB] Get:25 http://in.archive.ubuntu.com trusty Release [11.9 kB]
Get:26 http://in.archive.ubuntu.com trusty-backports/main Sources [9,712 B]
Get:27 http://in.archive.ubuntu.com trusty-backports/restricted Sources [28 B] Get:28 http://in.archive.ubuntu.com trusty-backports/universe Sources [35.3 kB] Get:29 http://in.archive.ubuntu.com trusty-backports/multiverse Sources [1,898 B] Get:30 http://in.archive.ubuntu.com trusty-backports/main i386 Packages [13.3 kB] Get:31 http://in.archive.ubuntu.com trusty-backports/restricted i386 Packages [28 B] Get:32 http://in.archive.ubuntu.com trusty-backports/universe i386 Packages [43.2 kB] Get:33 http://in.archive.ubuntu.com trusty-backports/multiverse i386 Packages [1,552 B] Get:34 http://in.archive.ubuntu.com trusty-backports/main Translation-en [7,503 B] Get:35 http://in.archive.ubuntu.com trusty-backports/multiverse Translation-en [1,215 B] Get:36 http://in.archive.ubuntu.com trusty-backports/restricted Translation-en [28 B] Get:37 http://in.archive.ubuntu.com trusty-backports/universe Translation-en [36.8 kB] Get:38 http://in.archive.ubuntu.com trusty/main Sources [14 B]
Get:39 http://security.ubuntu.com trusty-security/main i386 Packages [570 kB]
Get:40 http://security.ubuntu.com trusty-security/main i386 Packages [570 kB]
Get:41 http://security.ubuntu.com trusty-security/restricted i386 Packages [13.8 kB] Get:42 http://security.ubuntu.com trusty-security/universe i386 Packages [157 kB] Get:43 http://security.ubuntu.com trusty-security/multiverse i386 Packages [4,289 B] Get:44 http://security.ubuntu.com trusty-security/main Translation-en [334 kB] Get:45 http://security.ubuntu.com trusty-security/multiverse Translation-en [2,201 B] Get:46 http://security.ubuntu.com trusty-security/restricted Translation-en [3,505 B] Get:47 http://security.ubuntu.com trusty-security/universe Translation-en [91.4 kB] Fetched 4,414 kB in 3min 44s (19.6 kB/s)
W: Failed to fetch http://in.archive.ubuntu.com/ubuntu/dists/trusty/Release Unable to find expected entry 'restricted/source/Sources' in Release file (Wrong sources.list entry or malformed file)

E: Some index files failed to download. They have been ignored, or old ones used instead. user@user-VirtualBox:~$ sudo sh -c 'echo "deb [arch=amd64] https://apt-mo.trafficmanager.net/repos/dotnet-release/ trusty main" > /etc/apt/sources.list.d/dotnetdev.list' user@user-VirtualBox:~$ a a: command not found user@user-VirtualBox:~$ sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 417A0893 Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --homedir /tmp/tmp.vIi2jWIXTY --no-auto-check-trustdb --trust-model always --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 417A0893 gpg: requesting key 417A0893 from hkp server keyserver.ubuntu.com gpg: key 417A0893: public key "MS Open Tech interop@microsoft.com" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) user@user-VirtualBox:~$ sudo apt-get update Get:1 http://security.ubuntu.com trusty-security InRelease [65.9 kB] Ign http://in.archive.ubuntu.com trusty InRelease
Ign http://extras.ubuntu.com trusty InRelease
Get:2 http://extras.ubuntu.com trusty Release.gpg [72 B]
Get:3 http://extras.ubuntu.com trusty Release [11.9 kB]
Get:4 http://extras.ubuntu.com trusty/main Sources [14 B]
Get:5 http://in.archive.ubuntu.com trusty-updates InRelease [65.9 kB] Get:6 http://extras.ubuntu.com trusty/main i386 Packages [14 B]
Get:7 http://security.ubuntu.com trusty-security/main Sources [130 kB]
Get:8 http://security.ubuntu.com trusty-security/restricted Sources [4,941 B]
Get:9 http://security.ubuntu.com trusty-security/universe Sources [52.5 kB]
Get:10 http://security.ubuntu.com trusty-security/multiverse Sources [3,206 B] Hit http://in.archive.ubuntu.com trusty-backports InRelease
Get:11 http://in.archive.ubuntu.com trusty Release.gpg [72 B]
Hit http://security.ubuntu.com trusty-security/main i386 Packages
Get:12 http://security.ubuntu.com trusty-security/restricted i386 Packages [13.8 kB] Get:13 http://in.archive.ubuntu.com trusty-updates/main Sources [398 kB]
Hit http://security.ubuntu.com trusty-security/universe i386 Packages
Get:14 http://security.ubuntu.com trusty-security/multiverse i386 Packages [4,289 B] Get:15 https://apt-mo.trafficmanager.net trusty InRelease
Hit http://security.ubuntu.com trusty-security/main Translation-en
Get:16 https://apt-mo.trafficmanager.net trusty/main amd64 Packages
Get:17 https://apt-mo.trafficmanager.net trusty/main Translation-en_IN
Hit http://security.ubuntu.com trusty-security/multiverse Translation-en
Hit http://security.ubuntu.com trusty-security/restricted Translation-en
Ign http://extras.ubuntu.com trusty/main Translation-en_IN
Hit http://security.ubuntu.com trusty-security/universe Translation-en
Ign http://extras.ubuntu.com trusty/main Translation-en
Ign https://apt-mo.trafficmanager.net trusty/main Translation-en_IN
Ign https://apt-mo.trafficmanager.net trusty/main Translation-en Get:18 http://in.archive.ubuntu.com trusty-updates/restricted Sources [6,327 B] Get:19 http://in.archive.ubuntu.com trusty-updates/universe Sources [178 kB] Get:20 http://in.archive.ubuntu.com trusty-updates/multiverse Sources [7,767 B] Get:21 http://in.archive.ubuntu.com trusty-updates/main i386 Packages [937 kB] Get:22 http://in.archive.ubuntu.com trusty-updates/restricted i386 Packages [16.9 kB] Get:23 http://in.archive.ubuntu.com trusty-updates/universe i386 Packages [406 kB] Get:24 http://in.archive.ubuntu.com trusty-updates/multiverse i386 Packages [14.6 kB] Hit http://in.archive.ubuntu.com trusty-updates/main Translation-en
Hit http://in.archive.ubuntu.com trusty-updates/multiverse Translation-en
Hit http://in.archive.ubuntu.com trusty-updates/restricted Translation-en
Hit http://in.archive.ubuntu.com trusty-updates/universe Translation-en
Get:25 http://in.archive.ubuntu.com trusty Release [11.9 kB]
Hit http://in.archive.ubuntu.com trusty-backports/main Sources
Hit http://in.archive.ubuntu.com trusty-backports/restricted Sources
Hit http://in.archive.ubuntu.com trusty-backports/universe Sources
Hit http://in.archive.ubuntu.com trusty-backports/multiverse Sources
Hit http://in.archive.ubuntu.com trusty-backports/main i386 Packages
Hit http://in.archive.ubuntu.com trusty-backports/restricted i386 Packages
Hit http://in.archive.ubuntu.com trusty-backports/universe i386 Packages
Hit http://in.archive.ubuntu.com trusty-backports/multiverse i386 Packages
Hit http://in.archive.ubuntu.com trusty-backports/main Translation-en
Hit http://in.archive.ubuntu.com trusty-backports/multiverse Translation-en
Hit http://in.archive.ubuntu.com trusty-backports/restricted Translation-en
Hit http://in.archive.ubuntu.com trusty-backports/universe Translation-en
Get:26 http://in.archive.ubuntu.com trusty/main Sources [14 B]
Fetched 2,340 kB in 11s (210 kB/s)
W: Failed to fetch http://in.archive.ubuntu.com/ubuntu/dists/trusty/Release Unable to find expected entry 'restricted/source/Sources' in Release file (Wrong sources.list entry or malformed file)

E: Some index files failed to download. They have been ignored, or old ones used instead. user@user-VirtualBox:~$ sudo apt-get install dotnet-dev-1.0.4 Reading package lists... Done Building dependency tree
Reading state information... Done E: Unable to locate package dotnet-dev-1.0.4 E: Couldn't find any package by regex 'dotnet-dev-1.0.4' user@user-VirtualBox:~$ ^C user@user-VirtualBox:~$ dotnet help dotnet: command not found user@user-VirtualBox:~$

I am using ubuntu on VirtualBox Can you please help me? what am i missing?

leecow commented 7 years ago

Hi @nikamsshekhar, many of those errors have to do with reaching the ubuntu feeds and not just the dotnet feed so something is definitely amiss. Can you confirm the contents of /etc/apt/sources.list.d/dotnetdev.list?

seguler commented 7 years ago

A couple of issues with the RedHat installation procedure:

OS version: Red Hat Enterprise Linux Server release 7.3 Repro steps: Azure VM / Redhat 7.3 and install .NET Core:

sudo subscription-manager repos --enable=rhel-7-server-dotnet-rpms
sudo yum install scl-utils
sudo yum install rh-dotnetcore11
sudo scl enable rh-dotnetcore11 bash

Error messages

sudo subscription-manager repos --enable=rhel-7-server-dotnet-rpms
Error: 'rhel-7-server-dotnet-rpms' does not match a valid repository ID. Use "subscription-manager repos --list" to see valid repositories.

and then running "sudo scl enable rh-dotnetcore11 bash" takes me to root user (?), but the following command still cannot find the dotnet: sudo which dotnet

If I run the 'scl' command without sudo, then the current user path recognizes where the dotnet is installed (/opt/rh/rh-dotnetcore11/root/usr/bin/dotnet), however this doesn't seem to be persistent, as after a re-login, 'which dotnet' returns the following:

which dotnet
/usr/bin/which: no dotnet in (/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/seguler/.local/bin:/home/seguler/bin)

EmmaZhu commented 7 years ago

I followed instruction : https://www.microsoft.com/net/core#linuxredhat to install .Net Core. Seems I need to enable dotnet with "scl enable rh-dotnetcore11 bash" whenever I started a new bash session. Is this behavior intended? I know I can put the command in .bashrc. I just think it'd be much convenient if the installation can enable dotnet automatically.

karelz commented 7 years ago

How do I install .NET Core 1.1 (current) on my Ubuntu 16.04? I followed https://www.microsoft.com/net/core#linuxubuntu but it had instructions for 1.0.4 LTS.

To install .NET Core 1.1 on Ubuntu or Linux Mint, simply use apt-get isn't too helpful.

@richlander @kendrahavens are the instructions correct? If they are, they should explain explicitly why "sudo apt-get install dotnet-dev-1.0.4" installs 1.0.5 or 1.1.2. It is extremelly non-intuitive and it looks like a bug. Maybe part of our not-so-ideal versioning story?

omajid commented 7 years ago

Hey @EmmaZhu

I followed instruction : https://www.microsoft.com/net/core#linuxredhat to install .Net Core. Seems I need to enable dotnet with "scl enable rh-dotnetcore11 bash" whenever I started a new bash session. Is this behavior intended?

Yes. There's a few reasons for use-via-scl. The most important one is that .NET Core requires certain libraries that are just too old on base RHEL. In particular, some networking API requires features that are not a part of libcurl on base RHEL. So we build a modified version of libcurl that only gets activated via SCL. This lets all programs on the system continue working without being aware of the modified libcurl but .NET Core can see it and make use of more advanced features that part of the networking API in .NET Core needs.

Another reason is that without SCL, we would be tied to RHEL's release cycle and not be able to get updates out within days or weeks of upstream release. We would be doing non-security updates at 6 month (or longer) cycles.

I know I can put the command in .bashrc. I just think it'd be much convenient if the installation can enable dotnet automatically.

Please feel free to file bugs at bugzilla.redhat.com. User pains help us direct effort and weigh options. It's kind of hard for us Red Hat folk to monitor all github issues :)

livarcocc commented 7 years ago

The version of the tooling (1.0.4) and the versions of runtime(s) that it carries (1.1.2 and 1.0.5 in this case) are not tied together, as they have a different release cadence. For instance, we don't want to rev the runtime because of a tooling bug.

karelz commented 7 years ago

@livarcocc in that case we should mention it in the docs, something like "don't worry about not matching numbers". I am confused - I thought it is a bug, and I am on the team :(

omajid commented 7 years ago

@karelz I tried documenting it once: https://stackoverflow.com/documentation/.net-core/9592/components-and-versioning-in-net-core (copy on my blog).

Is this something that might be useful as part of .NET Core 1.x docs?

stanuku commented 7 years ago

@omajid @karelz @livarcocc Thanks for the responses. It is clear to me now from below snip, but it isn't super obvious that the latest SDK 1.0.4 includes both LTS and current runtimes.

Also, on the instructions page for Ubuntu: Before you start, please remove any previous versions of .NET Core from your system by using this script. --> So, is 'side by side' not possible on Ubuntu? like windows?
Using dotnet cli how do I find out what .NET Core runtimes are available on my system. dotnet -- version only tells you the SDK number -> Am I missing something?

thanks

karelz commented 7 years ago

@omajid it is not about 'ad-on' docs. IMO it should be crystal clear from the main docs -- installation docs in this case. Additional documentation is just too late. The confusion has been already seeded.

@stanuku see https://github.com/dotnet/cli/issues/3773 for discussion about dotnet --version.

stanuku commented 7 years ago

@karelz: Thanks

The discussion https://github.com/dotnet/cli/issues/3773, basically had a disappointing end in spite of many valid concerns and suggestions. I've been a .NET dev for over a decade (since 2.0) and consider myself a decent one at it. But, never before I'm subjected to such confusion and uncertainty. I'm having a hard time wrapping my head around this stuff. I'm not sure if I'm prepared to answer questions that would follow when I propose the adoption of .NET Core in new projects at my work. And also when I try to guide and mentor mid and junior level developers on this stuff. Let alone the issues I might face communicating to the server and IT teams about the bits that I would need them to install on build and hosting servers. How easy life can be when you just have to say we need .NET 4.6.2 or 4.5.1 etc, compared to this versioning nightmare. In my experience, an average developer (not so curious kind) would hardly care about the internals/SDK/CLI, they would expect the Visual Studio or other IDE to do the heavy lifting and abstract the complexity, so they can focus on solving the business problems and delivering their tasks. There is not much business value addition in spending tons of hours understanding these internals, which seem to be so fluid currently.

I hope common sense would prevail. One of the perils of the "open source" perhaps (Not that I'm against it, actually I love it when it is managed well and at a smaller scale. I don't expect everyone here to agree with me) however, exposing all the moving parts to a developer who could care less about the CLI/SDK etc etc and just wants to know a single one version number that can be used to pick up in the Target framework drop down in Visual Studio for example and be done with it and move on to more important business problems.

svick commented 7 years ago

How easy life can be when you just have to say we need .NET 4.6.2 or 4.5.1 etc, compared to this versioning nightmare.

With .Net Framework, you use Visual Studio 2017, MSBuild 15 and C# 7 to develop and build your applications and .Net Framework 4.7 to run them. With .Net Core, you use Visual Studio 2017, MSBuild 15, C# 7 and .Net Core SDK 1.0 to develop and build your applications and .Net Core 1.1 to run them. It is more complicated and the naming can be confusing (since it's easy to overlook the "SDK" part), but I'm not sure it's as bad as you make it sound.

they would expect the Visual Studio or other IDE to do the heavy lifting and abstract the complexity, so they can focus on solving the business problems and delivering their tasks

Do you have any specific suggestions for how the tooling can be improved?

There is not much business value addition in spending tons of hours understanding these internals, which seem to be so fluid currently.

There were huge changes in the past (dnx → dotnet, project.json → csproj), but as far as I know, the only somewhat big change that's coming is .Net Standard 2.0. So I wouldn't exactly call it "fluid".

And if you really need "tons of hours" to understand that .Net Core and .Net Core SDK are distinct and versioned separately, then I think something is very wrong. (Maybe it's the documentation?)

stanuku commented 7 years ago

@svick Thanks for your response (A disclaimer: I'm a very loyal .NET developer most of my professional career. I made and still making my living because of it. So far, I'm glad I didn't have to go through the constant catch up and churn that you find in the other popular and competing stacks)

Here are my thoughts/concerns:

Microsoft .NET development story has a long and solid history with Visual Studio + .NET full framework (albeit restricted to Windows). All the Businesses (LOB apps, SAAS, Product based) would be very anxious to move to .NET Core yet. Unless there is a great benefit. With all the churn happening since the past year and half or so, it delays that adoption even further. You can count me in that boat. I would have to cite the example of Entity Framework here. Are there any more improvements or enhancements planned after EF 6.3? if EF core is the future then .NET Core is the only way to go. I know there is a promise of .NET Standard 2.0. I really hope it lives up to the hype and expectations. I know, there is no point in dwelling on what has happened in the past, however, in the daily life of Architects/Developers who were early adopters, the reality is that they have been feeling misguided and in jeopardy of losing traction at work and with the management. The selling point of "cross-platform" is mostly for startups/midsize and green field development, whom historically not have been MS's focus or customer base. Those shops/organizations would still continue to be targeting full framework unless there is a simple and rock solid story for .NET Core migration which seems to be still long ways away. Is there an incentive or compelling reason for them to migrate now or in next one year?
I'm wondering how important/crucial it is for a developer to know what tooling /SDK/CLI/SharedHost/Runtime versions. Shouldn't it be left to their IDE to figure out based on one target version that he or she picks from the list? I'm referring to the traditional VS Architects/Developers, they never really needed to know anything other than the .NET framework version and a Managed language of their choice, for the most part. I agree that VS 2017 has shown promise and hope, however we already have applications in production based on the project.json (from VS2015) . To upgrade all the servers with relevant bits and migrate to MSBuild/.csproj again takes a lot of convincing and confidence building measures.

Some suggestions/comments:

In VS 2017 IDE, I would ideally prefer the .NET Core listed in the target framework drop down instead of under templates. For a traditional VS developer, it is hard to relate to.

The documentation is getting better, not perfect though. Please refer to some of the issues that I've reported. https://github.com/dotnet/core/issues/656, and my comments in this post.

NOTE: I'm super excited about the .NET Core and ASP.NET Core but it is so far just limited to my personal projects and a couple simple cookie cutter web applications at work. I don't feel too confident yet to start building a case for a wider adoption at my work place at a bigger scale especially, training the devs. Given the management has bigger problems to solve and other priority and don't really see a pressing need to migrate. I'll have to sit out and watch .NET Standard 2.0 unfold and target .NET 4.6.1 till then. Sometimes I wonder who is MS targeting with the .NET Core movement.

svick commented 7 years ago

@stanuku

With all the churn happening since the past year and half or so, it delays that adoption even further.

.Net Core SDK 1.0 was released this February. I don't think it's fair to complain about churn before that.

Are there any more improvements or enhancements planned after EF 6.3? If EF core is the future then .NET Core is the only way to go. I know there is a promise of .NET Standard 2.0. I really hope it lives up to the hype and expectations.

I don't know anything about future plans for EF or EF Core. But even if EF Core is the future, then you can still stay on .Net Framework, since EF Core is a .Net Standard library and .Net Framework does support .Net Standard. (And that's not something that's new with .Net Standard 2.0.)

Is there an incentive or compelling reason for them to migrate now or in next one year?

If any of the unique features of .Net Core (not just it being cross-platform, but also e.g. different deployment strategies) do not appeal enough to you, then you should not migrate, possibly ever. Even the documentation recommends not to migrate existing .Net Framework applications.

Shouldn't it be left to their IDE to figure out based on one target version that he or she picks from the list?

Isn't it like that already? If you install .Net Core tooling for VS from the VS installer, you don't have to care about any .Net Core SDK version, no?

The VS-specific section of the .Net Core getting started page also does not mention any SDK versions.

omajid commented 7 years ago

.Net Core SDK 1.0 was released this February. I don't think it's fair to complain about churn before that.

I think it is, especially given .NET Core 1.0 was released last year. I - and many others - had no idea SDK and non-SDK were different components, were being developed independently and were versioned separately. And I was talking to folks working on .NET Core every week...

stanuku commented 7 years ago

@svick: Again I'm not debating on the decisions, but giving an outside perspective. This perspective is from people like me who would ultimately take the result of the efforts of people like you (within and outside MS) to a bigger picture, people who would utilize your product to build bigger things, solve real problems and generate revenue and act as ambassadors of the .NET brand.

My main point is, did MS have .NET Standard 2.0 in mind all along? if so, then the pain and rough ride for the early adopters could have been mitigated with proper and timely communication and guidance. If not, and if .NET Standard 2.0 just evolved based on the feedback, then it makes me feel a bit uncertain of what else could change in the future (for a brief period just before the BUILD 2017, there was confusion on .NET Core 2.0 not supporting .NET Standard 2.0. The big guns at MS had to do the damage control later and clear the confusion. I suspect they must have debated about it internally and retracted based on the feedback)

.Net Core SDK 1.0 was released this February. I don't think it's fair to complain about churn before that.

Not just the SDK I was referring to the other components of the .NET Core. Same sentiment as @omajid has expressed.

Isn't it like that already? If you install .Net Core tooling for VS from the VS installer, you don't have to care about any .Net Core SDK version, no? The VS-specific section of the .Net Core getting started page also does not mention any SDK versions.

Unless I'm missing something, the VS 2017 still doesn't show what versions I'm getting or targeting from the project creation dialogs. Although, I don't mind editing the project files and changing the TFMs and other details, not everyone would prefer to do that.

VS2017 is promising but, I'm suspecting we have good couple of iterations of .NET Core/Standard i.e. 2.*, 3.0 and VS 2018, 2019. Before, we get there where we want to be. I can't wait for it. But will watch cautiously. I had bore the brunt of early adoption in 2016 already.

Thanks

svick commented 7 years ago

did MS have .NET Standard 2.0 in mind all the way?

As far as I know, they didn't. It came from the acquisition of Xamarin and their realization that the best way to support .Net Framework, .Net Core and Xamarin/Mono all at the same time was to expand .Net Standard.

for a brief period just before the BUILD 2017, there was confusion on .NET Core 2.0 not supporting .NET Standard 2.0. The big guns at MS had to do the damage control later and clear the confusion. I suspect they must have debated about it internally and retracted based on the feedback

To clarify, the confusion was about ASP.NET Core 2.0 not supporting .Net Standard 2.0, and thus also not being able to run on .Net Framework.

VS 2017 still doesn't show what versions I'm getting or targeting from the project creating dialogs. Although, I don't mind editing the project files and changing the TFMs and other details, not everyone would prefer to do that.

Yes, it doesn't. But you can change it from the project properties page, you don't have to edit the project file.

I can't wait for it. But will watch cautiously. I had bore the brunt of early adaption in 2016 already.

I'd say that in 2016, you were a very early adopter: i.e. not everything was even expected to work. In 2017, you're just an early adopter: everything should work, but the experience might not be quite polished yet. So waiting some more before switching to .Net Core sounds like a reasonable business decision to me. (Even if part of me wishes everyone would always work from master, not even wait for release, at least for the projects I'm currently most passionate about. 🙂)

stanuku commented 7 years ago

@svick:

To clarify, the confusion was about ASP.NET Core 2.0 not supporting .Net Standard 2.0, and thus also not being able to run on .Net Framework.

You're right, my concern still applies though.

Yes, it doesn't. But you can change it from the project properties page, you don't have to edit the project file.

Yes, you still wouldn't know what the runtime version (major.minor.patch) is. Shouldn't we need to know?

richlander commented 7 years ago

Closing. .NET Core 1.0.5 and 1.1.2 have now shipped.

See #622

dotnet / core

.NET Core 1.0.4 and 1.1.1 #532