.NET Core Version Numbers - .net-core

I have .NET Core installed and I am a little confused about the version numbers I am seeing. When I run the dotnet command, I get this output:
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 of the installed Shared Framework to use to run the application.
--additionalprobingpath 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
That is telling me I have .NET Core v1.1.0, which is what I expected based on what I installed.
However, if I then run dotnet --version, it tells me I have version 1.0.1. Why the discrepancy? What is the difference between these two version numbers?

1.0.1 is a .NET Core SDK version
1.1.1 is a .NET Core runtime version
See related SO question .Net Core Version Confusion on Installer

Related

How to run .NET framework project with VS Code, which has dependency of ReactJS?

I am beginner to .NET framework and ReactJS. I have a code repository which is .NET framework, with ReactJS dependency.
When I opened the repository, VS Code suggested me to install C# extension, I installed.
Now when I opened the main file abc.csproj; it automatically started installing packages.
It ended with message:
Finished
Failed to spawn 'dotnet --info'
and notified:
The .NET core SDK cannot be located. .NET Core debugging will not be enabled. Make sure the .NET Core SDK is installed and is on path.
What is process and list of extensions if I need it to be ran in VS Code?
P. S. It is a .NET framework 4.5 project and not core .NET project
The C# extension no longer ships with an included Mono & MSBuild Tools...
If you still need Unity or .NET Framework support, you can set
omnisharp.useModernNet to false
in your VS Code settings and restart OmniSharp.
See issue #5120 for more details.
https://github.com/OmniSharp/omnisharp-vscode/issues/5120
it seems you don't have the .net framework SDK installed on your machine.
you can download and install .net sdk from here : https://dotnet.microsoft.com/download/visual-studio-sdks to be able to build .net framework projects
I will suggest to use Microsoft Visual Studio. I am using it and it's good and dragless rather than getting SDKs and having installation troubles.

F# Interactive (fsi.exe) support in.Net Core SDK (v3.1.100.14727)

I want to deploy\use F# interactive as part of a .Net library which supports both .Net Framework & .Net Core - I've done this before for just .Net Framework but now I want to support .Net Core, as a way of learning more about .NET Core.
I have VS2019 with the .NET Core SDK (v3.1.100.14727) installed.
I can run fsi.exe from the VS2019 install folder:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\FSharp
But I can not run fsi.exe. from the .NET Core SDK folder - not built to run on a Windows OS:
C:\Program Files\dotnet\sdk\3.1.100\FSharp
I would have thought if I have the correct version of the .Net Core runtime installed (which I do) I should be able to run any .Net Core application - is this not the case?
Do I have to deploy 2 versions of the F# Interactive to support a .Net Core implementation?
This just means that fsi.exe hasn't been compiled to run as a single exe but instead needs to be called via dotnet.
⨯ C:\Program Files\dotnet\sdk\3.1.100\FSharp 
[00:00] ❯ dotnet .\fsi.exe
Microsoft (R) F# Interactive version 10.7.0.0 for F# 4.7 Copyright (c)
Microsoft Corporation. All Rights Reserved.
For help type #help;;
>
You could wrap this or try the --targetprofile option.

Bamboo NuGet Restore command is running older version of SDK

I have a .net core 2.2 web app that has been building successfully in Bamboo for several months. Recently someone rebuilt the new Bamboo server (we're on premise, not in cloud) as the first step in a Bamboo upgrade and my build began failing. The error is:
C:\Program Files\dotnet\sdk\2.1.509\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets(137,5): error NETSDK1045: The current .NET SDK does not support targeting .NET Core 2.2. Either target .NET Core 2.1 or lower, or use a version of the .NET SDK that supports .NET Core 2.2.
My original post incorrectly asserted that this error was occurring in a Script task running dotnet publish. I realize now that it is actually occurring in the previous task - a Bamboo Command task running NuGet Restore. And I can reproduce the problem at the command line, so it does not appear to be a Bamboo issue.
So, in summary, I have a .NET Core solution with four projects. All four projects target .NET Core 2.2. I have NuGet 5.3.1 installed on my Bamboo build server. I navigate to the solution directory and run
nuget restore
And I first get the following informational message:
MSBuild auto-detection: using msbuild version '15.9.21.664' from 'C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\bin'.
Followed by four instances of the following error, one per project:
C:\Program Files\dotnet\sdk\2.1.509\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets(137,5): error NETSDK1045: The current .NET SDK does not support targeting .NET Core 2.2. Either target .NET Core 2.1 or lower, or use a version of the .NET SDK that supports .NET Core 2.2.
What is causing the nuget restore operation to be working with .NET Core 2.1 instead of 2.2? Is there a problem with the msbuild auto-detection?
I initially found that .net core 2.2 had not been installed on the new server, so I installed it, so both are now installedre. But the error above persists and continues to reference .net core 2.1.
Instead of running nuget restore use dotnet restore.
A cleaner way to set this up would be to configure a dotnet executable as a Command in Bamboo. By doing this you can ensure that you are running the correct executable every time. Additionally you will gain the following benefits:
The command will show what version it is
This scale to other build agents
Adds clarity to the Bamboo task (will show as dotnet 2.2 instead of a script).
Then you can have dedicated tasks for each step (e.g., restore, build, test)

.NET Core runtime/sdk versioning with .NET 461?

I'm getting more and more confused with .NET Core's SDK and runtime versioning, and I doubt I'm the only one. I want to get a few things straight.
I've created an ASP.NET Core application targeting .NET 4.6.1 - it hits 4.6.1 libraries and Net Standard libraries. Recently I made the switch from project.json to csproj as part of the VS2017 rollout. The 1.1.1 runtime came out with SDK 1.0.1 a few weeks ago, which I downloaded (https://github.com/dotnet/core/blob/master/release-notes/download-archive.md).
dotnet --version gives me the correct SDK (1.0.1)
However, typing "dotnet" into cmd I see "Version : 1.1.0". Shouldn't this say 1.1.1? My Programs and Features shows that the 1.1.1 runtime is installed.
Fast forward to hosting my app: I install the latest windows server hosting package to host on IIS according to https://learn.microsoft.com/en-us/aspnet/core/publishing/iis, that is 1.0.4&1.1.1. Installing this on my server installs "Microsoft .NET Core 1.0.4 & 1.1.1 - Windows Server Hosting" and "Microsoft .NET Core 1.0.4 - Runtime". Shouldn't it have also installed the 1.1.1 runtime? It works, so maybe it's not necessary.
Ultimately, my questions are the following:
Does the runtime version matter when targeting .NET 4.6.1 at all?
Is runtime just used to run the AspNetCoreModule for the IIS to kestrel reverse proxy?
Will installing new Windows Hosting packages break existing projects already running on the servers?
Does .Net's netstandard packages (such as MVC) versioning correspond in any way to the runtime version, or is it just regular semantic versioning? The newest versions of most "Microsoft.AspNetCore.X" packages are 1.1.1.
I'm in the same situation, compiling my ASP.NET Core app against the full .NET Framework (4.5.2 in my case) and deploying it on IIS. Hopefully I can help.
When using the full .NET framework, you need to install the SDK on your developper machine to compile, but to deploy it on an IIS server you don't need any .NET Core runtime installed at all. On my IIS server, I just need .NET Framework installed and then I'm installing the "Windows Server Hosting" as suggested here: https://github.com/dotnet/core/blob/master/release-notes/download-archives/1.0.4-download.md with a command line that won't even install any .NET Core on my server:
DotNetCore.1.0.4_1.1.1-WindowsHosting.exe OPT_INSTALL_LTS_REDIST=0 OPT_INSTALL_FTS_REDIST=0
This installation is super quick and is just deploying the minimum amount of files IIS needs to run your .NET Core app, which is mainly the aspnetcore.dll. I don't even have a directory "C:\Program Files\dotnet" (so no runtime or sdk) on my server and my app is working fine.
So, I would say:
no, it doesn't matter, it won't run against any .NET Core runtime
no, AspNetCore.dll is a C++ module (https://github.com/aspnet/AspNetCoreModule)
I don't see how it could break anything
at the moment, when you add a Nuget package in your ASP.NET Core app, its versionning seems quite independant to me, that's why Microsoft is now providing metapackage to help people using the proper set of Nuget package (https://andrewlock.net/what-is-the-microsoft-aspnetcore-metapackage/)
Regarding:
However, typing "dotnet" into cmd I see "Version : 1.1.0". Shouldn't
this say 1.1.1? My Programs and Features shows that the 1.1.1 runtime
is installed.
I'm wondering the same thing and can't figure out where this is coming from, maybe it's just the version of the "dotnet" command line tool that is package with the SDK 1.0.1, but I can't prove it.

How to run ASP.NET Core Web application on Linux?

I have an ASP.NET Web application that was successfully running on Linux with the help of dnx-mono NuGet package. I used to publish it by using dnx publish tool and run it with the command:
/opt/dnx-mono.1.0.0-rc1-update1/bin/dnx --appbase /path/to/json Microsoft.Dnx.ApplicationHost kestrel
Since dnx is obsolete, I want to get rid of it and migrate to .NET Core, but it does not work anymore on Linux.
Important: I cannot make my application .NET Core app because it uses some libraries (like MySQL.Data) that are still not available for .NET Core. Therefore, I create ASP.NET Core Web Application (notice .NET Framework):
I migrated the whole application and run it successfully on Windows, but my target is Linux. No more dnx publish, no problem - there is dotnet publish which works well and produces binaries. What now? Dnx-mono package does not have a "dotnet-something" successor, and using dotnet command with published binaries produced errors that I was not able to resolve (The library 'libhostpolicy.so' required to execute the application was not found), but I don't think that I should even use dotnet command with standalone binaries. Googling didn't help as most tutorials are focused around ASP.NET Web applications for .NET Core, not for .NET Framework. Version of Linux is Debian 8, dotnet command was obtained by following this guide. Any clue?
You cannot run an application on Linux that targets the full .Net Framework, it has to be Core only.

Resources