.NET Core is still at it’s beginning. We already had some released of .NET Core (1.0, 1.0.1, 1.0.2, 1.0.3, 1.1), however the tools are still not released yet. With this we can get some issues, e.g. when using Visual Studio 2017 RC with side-by-side installation of Visual Studio 2015. You might even have issues running existing .NET Core applications with Visual Studio 2015 after Visual Studio 2017 was installed. Using Visual Studio 2015, RC2 of the dotnet tools is used that are based on project.json. With Visual Studio, a preview of newer build tools with .csproj files is used. Here I’m showing what changes and how you can solve some issues, and still open .NET Core projects with Visual Studio 2015. You can read about how some versioning issues can be solved.

Side By Side Installation of .NET Core Command-Line (CLI) Tools

To deal with different tool features, the tools can be installed side by side. With upcoming changes major changes (previews are available), with project files are on the way. The JSON format of project.json will move to MSBuild with XML syntax. This change is not because XML is better than JSON, but because many other project types are based on MSBuild, and a lot of development effort would have been necessary to bring all the MSBuild features to project.json. Instead, .NET Core now moves to MSBuild. This has become possible because MSBuild is now available on other platforms as well.

JSON to XML is like C# to VB – comparing curly brackets to begin/end.

The change in the tools, in particularily the move from project.json to .csproj results in some issues we need to deal with – at least before the tools are released and everything moved to the new syntax.

There are some solutions. Different versions of the .NET tools can be installed side-by-side. You can find the tools you have installed in the directory c:\Program Files\dotnet\sdk. You can see the actual version of the dotnet tools using

dotnet –version

This shows the actual version installed, e.g.

1.0.0-preview4-004233

This is the version that comes with Visual Studio 2017 RC (and some updates since the first RC installation). You should find the same version you see here in the Program Files directory. On my system I can see these versions with the specific directories:

• 1.0.0-preview2-003131
• 1.0.0-preview2-1-003177
• 1.0.0-preview2.1-003155
• 1.0.0-preview4-004233

Preview 4 of the tools make use of the new project file format (csproj), while preview 2 is using project.json.

Migrating Projects using dotnet Tools

With a previously .NET Core application you might have such a project.json file:

{
  "version": "1.0.0-*",
  "buildOptions": {
    "debugType": "portable",
    "emitEntryPoint": true
  },
  "dependencies": {},
  "frameworks": {
    "netcoreapp1.0": {
      "dependencies": {
        "Microsoft.NETCore.App": {
          "type": "platform",
          "version": "1.0.1"
        }
      },
      "imports": "dnxcore50"
    }
  }
}

You can migrate the project.json file using the command line tools:

>dotnet migrate

This creates this new .csproj file:

<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0">
  <PropertyGroup>
    <TargetFramework>netcoreapp1.0</TargetFramework>
    <DebugType>portable</DebugType>
    <AssemblyName>HelloWorldApp</AssemblyName>
    <OutputType>Exe</OutputType>
    <PackageTargetFallback Condition=" '$(TargetFramework)' == 'netcoreapp1.0' ">$(PackageTargetFallback);dnxcore50</PackageTargetFallback>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="**\*.cs" />


  </ItemGroup>
  <ItemGroup Condition=" '$(TargetFramework)' == 'netcoreapp1.0' ">
    <PackageReference Include="Microsoft.NETCore.App">
      <Version>1.0.1</Version>
    </PackageReference>
  </ItemGroup>
  <PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
    <DefineConstants>$(DefineConstants);RELEASE</DefineConstants>
  </PropertyGroup>
</Project>

The csproj file might change with ongoing releases. Indeed, it already changed since the first availability of Visual Studio 2017 RC and was made simpler since then.

Creating a new project, the generated .csproj file is smaller as it doesn’t include the preprocessor definition for RELEASE, a resources directory got removed, and some defintions with the PropertyGroup are missing. The existing dnxcore50 value from the imports section is added to PackageTargetFallback whereas this setting is not included with new projects.

The PackageTargetFallback definition dnxcore50 is not defined with newly created projects, as this setting is only needed for compatibility, to use package libraries that don’t target the .NET Standard yet.

>dotnet new

<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp1.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="**\*.cs" />

  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NETCore.App" Version="1.0.1" />
  </ItemGroup>
</Project>

Migrating Projects using Visual Studio 2017 RC

Opening a previously created .NET Core solution with Visual Studio 2017, the project.json file automatically gets converted to the new format. The dotnet migrate command is invoked for every project in the solution. You can see a one-way upgrade dialog as shown here:

The migration is one-way because the migrated project files cannot be openend by Visual Studio 2015. The dotnet tools with Visual Studio 2015 only support project.json. For the new format you need Visual Studio 2017.

Still using .NET Core with Visual Studio 2015

You cannot open csproj based .NET Core applications with Visual Studio 2015. To go back, the migration process moves the migrated files to the backup directory, and of course you can get back to these. However, you also might have issues opening existing .NET Core projects with Visual Studio 20015 that haven’t been migrated.

The reason is that the new version of the dotnet tools don’t support the project.json syntax. You need to explicitely specify to use a specific version of the .NET Core CLI tools.

If you get an error such as this one

MSBUILD : error MSB1003: Specify a project or solution file. The current working directory does not contain a project or solution file

or

MSBUILD: error MSB1009: Project file does not exist

You also might get an error opening the solution with Visual Studio 2015 as shown:

This error containing 1.0.0-preview4-004233 clearly indicates that a wrong version of the .NET Core CLI tools is used.

A solution can be to specify a global.json file with this content:

{
  "projects": [
    "."
  ],
  "sdk": {
    "version": "1.0.0-preview2-003131"
  }
}

The global.json file specifies what version of the tools should be used. Compare this with the versions you’ve seen earlier in this article. To verify the correct tool version is used, you can also invoke the command line

>dotnet –version

and you should see

1.0.0-preview2-003131

if the current directory is the directory of the solution or a subdirectory (a directory of a project). With this in place you should successfully build and compile older .NET Core projects with Visual Studio 2015.

With global.json in place, and you have the correct version of the .NET tools installed, you can open and build .NET Core projects using Visual Studio 2015 successfully.

launchsettings.json

Recently I came to another issue thanks to the issue report from ToMissTheMarc. Running existing .NET Core projects from Visual Studio 2015, you might get this error:

The command specified in the debug target does not exist. Select a different debug target or add the command to the project.json file

This error is a little misleading, as the project.json file doesn’t have a problem. Instead, launchsettings.json does. Just check the file launchsettings.json that can be found in Solution Explorer within the Properties section. It might contain this configuration:

{
  "profiles": {
    "VirtualMethods": {
      "commandName": "VirtualMethods",
      "sdkVersion": "dnx-clr-win-x86.1.0.0-rc2-16343"
    }
  }
}

As the version number of the SDK shows, the file was created with a previous .NET Core version. However, the version number is not the issue. The line with the sdkVersion can be removed. However, the real problem is the commandName specifying the project name. In earlier builds, the project name was configured in project.json. Now, the commandName can be set to Project, such as:

{
  "profiles": {
    "VirtualMethods": {
      "commandName": "Project"
    }
  }
}

This way, the project should start successfully.
You can also delete launchsettings.json to run your project successfully. However, with other options in launchsettings.json, such as for ASP.NET Core web applications, and passing command line arguments from the debugger to the application, this file is needed. Specifying command line arguments from Project Properties, launchsettings.json is created automatically.

Summary

Everything is becoming better when the .NET Core tools are in a released state and all the dependencies you are using make use of the new versions. In the meantime we have to deal with some misleading errors. As you know the solutions, many of the issues can be solved easily. global.json is your friend, also check for launchsettings.json.

Have fun with programming and learning!
Christian

More Information

You can read more about .NET Core in my new book Professional C# 6 and .NET Core 1.0. If you are interested, contact me for a workshop with any topic touching .NET.

What is .NET Core

Portable Library to .NET Standard

Growing Plant Sequence © Kateleigh | Dreamstime.com Growing Plant Sequence