Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Can't compile Environment.Exit in .NET Core

Tags:

c#

.net-core

dnx

Related: System.Environment in .NET Core

I'm trying to compile a program which uses Environment.Exit in .NET Core. I've used yo aspnet to create the default console application, installed System.Runtime.Extensions and then added a call to Environment.Exit(1) (full sample on github). When running dnu build I get this error:

C:\git\environmentexit\ConsoleApplication\Program.cs(13,25): DNXCore,Version=v5.0 error CS0117: 'Environment' does not contain a definition for 'Exit'

As far as I can tell, this corefx pull request should mean that Environment.Exit is exposed, so I can't figure out what else I'm missing.

Any ideas?

like image 716
nyctef Avatar asked Dec 22 '15 10:12

nyctef


1 Answers

First of all I want to confirm that the problem exist in the current stable version of DNX: 1.0.0-rc1-update1 installed together with Visual Studio 2015 Update 1. The problem is already fixed in the current unstable build 1.0.0-rc2-16343.

I try to describe below very detailed how everybody can reproduce the problem step by step. In the next step I would show how to install the latest unstable build of DNX (it's 1.0.0-rc2-16343 today) and to compile your demo successfully. Finally I show how to uninstall unstable build of DNX go back to 1.0.0-rc1-update1.

First of all it's important to understand that one can install multiple version of DNX. On the other side all the packages resolved by usage "Restore Packages" in the context menu of the project or by usage of "dnu restore" command will be saved (cached) in the common folder %USERPROFILE%\.dnx\packages. The dependencies will be resolved from NuGet. To be exactly there are the file %APPDAT%\NuGet\NuGet.Config which contains the configuration of NuGet with URLs used for resolving of dependencies. Thus one can have wrong results after "playing" with different NuGet configurations and with different versions of DNX. I find such behavior as the large design problem of DNX today. I hope that it will be fixed soon.

In any way I strictly recommend to delete all files from %USERPROFILE%\.dnx\packages to have deterministic results. Additionally one should verify NuGet configuration to load the files only from the starndard NuGet source https://api.nuget.org/v3/index.json (or https://www.myget.org/F/aspnetvnext/api/v2/) and optionally from https://www.myget.org/F/aspnetvnext/api/v3/index.json (or https://www.myget.org/F/aspnetmaster/api/v2), which can contains additional ASP.NET stable packages. One can either edit the file %APPDAT%\NuGet\NuGet.Config manually or to check the described above sources in Visual Studio in menu: "Tools" / "NuGet Package Manager" / "Package Manager Settings" and choosing "Package Sources" finally.

1) I removed all files under %USERPROFILE%\.dnx\packages 2) verified using "dnvm list" that I have only 1.0.0-rc1-final and 1.0.0-rc1-update1 versions of DNX. I uninstalled some unneeded version using something like "dnvm uninstall 1.0.0-rc2-16343 -r coreclr -arch x86" and verified that the 1.0.0-rc1-update1 is default by usage "dnvm upgrade". After that the "dnvm list" displayed:

enter image description here

3) set only https://api.nuget.org/v3/index.json in my initial configuration:

enter image description here

After building of your demo with Program.cs

using System;

namespace ConsoleApplication
{
    public class Program
    {
        public static void Main(string[] args)
        {
            Console.WriteLine("Goodbye, cruel world");
            Environment.Exit(1);
        }
    }
}

and project.json

{
  "version": "1.0.0-*",
  "description": "ConsoleApplication Console Application",
  "authors": [
    ""
  ],
  "tags": [
    ""
  ],
  "projectUrl": "",
  "licenseUrl": "",
  "tooling": {
    "defaultNamespace": "ConsoleApplication"
  },
  "commands": {
    "ConsoleApplication": "ConsoleApplication"
  },
  "dependencies": { },
  "frameworks": {
    "dnx451": { },
    "dnxcore50": {
      "dependencies": {
        "System.Console": "4.0.0-*",
        "System.Runtime": "4.0.21-*",
        "System.Runtime.Extensions": "4.0.11-*"
      }
    }
  }
}

I get the following dependencies resolved

enter image description here

and the error message

enter image description here


Now I installed the latest unstable DNX using

dnvm upgrade -u -r coreclr -arch x64
dnvm upgrade -u -r clr -arch x64
dnvm upgrade -u -r coreclr
dnvm upgrade -u -r clr

The command "dnvm list" displayed

enter image description here

After that I modified the NuGet configuration to use https://www.myget.org/F/aspnetvnext/api/v3/index.json additionally:

enter image description here

Then I modified sdk.verison of global.json from "1.0.0-rc1-update1" to "1.0.0-rc2-16343" in the GUI of Visual Studio:

enter image description here

and saved the changes. After that I made "Restore Packages" and build the project once more. I get the following versions of dependencies:

enter image description here

and the program could be executed without any error.

It's vary important to mention that even if we would change the sdk.verison back to "1.0.0-rc1-update1" we will still have the same resolution of dependences from rc2-16343 because it will be used the packages cashed in %USERPROFILE%\.dnx\packages. It's really important to change NuGet configuration to original state (uncheck URL https://www.myget.org/F/aspnetvnext/api/v3/index.json) and delete all %USERPROFILE%\.dnx\packages. I would recommend you to deinstall unneded night build of DNX by usage of

dnvm upgrade
dnvm uninstall 1.0.0-rc2-16343 -r coreclr -arch x64
dnvm uninstall 1.0.0-rc2-16343 -r clr -arch x64
dnvm uninstall 1.0.0-rc2-16343 -r coreclr
dnvm uninstall 1.0.0-rc2-16343 -r clr

After all the steps one should have the same state in "dnvm list" as initially. One can verify that %USERPROFILE%\.dnx\runtimes don't contains any directories with 1.0.0-rc2-16343, the file %USERPROFILE%\.dnx\alias\default.txt contains dnx-clr-win-x86.1.0.0-rc1-update1 and the PATH contains only %USERPROFILE%\.dnx\runtimes\dnx-clr-win-x86.1.0.0-rc1-update1\bin and not references to 1.0.0-rc2-16343. In other words we finished our test and are returned back to stable rc1-update1.

like image 100
Oleg Avatar answered Oct 05 '22 04:10

Oleg