ASP.NET 5:Is the "Dotnet" Command Replacing "Dnu" and "Dnx" Commands

ASP.NET 5 : Is the dotnet command replacing dnu and dnx commands?

Is the dotnet command replacing dnu and dnx commands?

Yes. They are introducing new command line toolchain, ASP.NET 5 will transition to the new tools for RC2. This is already in progress. There will be a smooth transition from DNX to these new .NET Core components.

Are the dnu and dnx commands completely replaced?

No. You can use dnu and dnx, if you follow this instruction Installing .NET Core on Linux.

Is there some documentation somewhere about the dotnet commands?

CLI Repo / Intro to .NET Core CLI - v1.0.0

Getting the correct dependencies for .NET Web Api for the latest .NET core

This is what ASP.NET and Web Tools 2015 (Beta7) does for me. I suppose beta8 (http://www.microsoft.com/en-us/download/details.aspx?id=49442) will scaffold beta8 packages.

"dependencies": {
 "EntityFramework.Commands": "7.0.0-beta7",
 "EntityFramework.SqlServer": "7.0.0-beta7",
 "Microsoft.AspNet.Authentication.Cookies": "1.0.0-beta7",
 "Microsoft.AspNet.Authentication.Facebook": "1.0.0-beta7",
 "Microsoft.AspNet.Authentication.Google": "1.0.0-beta7",
 "Microsoft.AspNet.Authentication.MicrosoftAccount": "1.0.0-beta7",
 "Microsoft.AspNet.Authentication.Twitter": "1.0.0-beta7",
 "Microsoft.AspNet.Diagnostics": "1.0.0-beta7",
 "Microsoft.AspNet.Diagnostics.Entity": "7.0.0-beta7",
 "Microsoft.AspNet.Identity.EntityFramework": "3.0.0-beta7",
 "Microsoft.AspNet.Mvc": "6.0.0-beta7",
 "Microsoft.AspNet.Mvc.TagHelpers": "6.0.0-beta7",
 "Microsoft.AspNet.Server.IIS": "1.0.0-beta7",
 "Microsoft.AspNet.Server.WebListener": "1.0.0-beta7",
 "Microsoft.AspNet.StaticFiles": "1.0.0-beta7",
 "Microsoft.AspNet.Tooling.Razor": "1.0.0-beta7",
 "Microsoft.Framework.Configuration.Abstractions": "1.0.0-beta7",
 "Microsoft.Framework.Configuration.Json": "1.0.0-beta7",
 "Microsoft.Framework.Configuration.UserSecrets": "1.0.0-beta7",
 "Microsoft.Framework.Logging": "1.0.0-beta7",
 "Microsoft.Framework.Logging.Console": "1.0.0-beta7",
 "Microsoft.Framework.Logging.Debug" : "1.0.0-beta7",
 "Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.0.0-beta7"
},

EDIT: For WebAPI this is:

"dependencies": {
  "Microsoft.AspNet.Mvc": "6.0.0-beta7",
  "Microsoft.AspNet.Server.IIS": "1.0.0-beta7",
  "Microsoft.AspNet.Server.WebListener": "1.0.0-beta7",
  "Microsoft.AspNet.StaticFiles": "1.0.0-beta7"
},

Most probably you have old version of VS tooling. You may check your version of ASP.NET and Web Tools under About Visual Studio in Help menu. Reinstall or post exact message you get from build system or from runtime (including IIS).

EDIT: forgot to mention that is works for me for dnx beta7 (dnx beta8 with beta7 VS tooling does not)

How to fix DNX/DNVM in Visual Studio 2015?

This is a known issue.

ASP.NET 5: On Windows 7 SP1, DNX SDK cannot be installed without
Powershell 3.0.

Symptoms

When you create an ASP.NET 5 project, you receive the following error message:

DNX SDK version 'dnx-clr-win-x86.1.0.0-beta5' failed to install. The
solution will use DNX SDK version 'dnx-clr-win-x86-1.0.0-beta5' for
this session

Workaround

To work around this issue, install Windows Powershell 3.0 (or higher) and try to create the project again. To see your current PS version, run $PsVersionTable command (details).

Links:

• How to Install Windows PowerShell 4.0.
• Install PowerShell 3.0 on Windows 7.

Differences between aspnetcidev and aspnetvnext?

Jan 29, 2016 edit:

This information is now part of the ASP.NET wiki: https://github.com/aspnet/Home/wiki/NuGet-feeds

---

The ASP.NET build system uses 3 myget feeds for each branch + nuget.org.

• aspnetvolatile<branch> (aspnetvolatiledev/aspnetvolatilerelease)
• aspnetci<branch> (aspnetcidev/aspnetcirelease)
• aspnetvnext (dev branch)/aspnetrelease (release branch)

After each repo under github.com/aspnet builds successfully, each package produced by it is pushed to the corresponding volatile feed.

After the graph of repos is build, we trigger the Coherence build. This build verifies that the packages have matching versions and their references are correct (that they are coherent). Then, it pushes them to aspnetci<branch>.

Once the Coherence build passes, we run all our tests on the packages in the aspnetci<branch> feed. If the tests pass, we sign the packages and ship them to aspnetvnext or aspnetrelease

So the differences are:

• aspnetvolatile<branch>

  • latest packages
  • possible not coherent
  • not tested
  • not signed
  • updated on every checkin
  • mostly used to diagnose build failure

• aspnetci<branch>

  • possible not latest
  • coherent
  • not tested
  • not signed
  • updated when all repos build successfully
  • used by our build system

• aspnetvnext/ (aspnetrelease|nuget.org)

  • possible not latest
  • coherent
  • signed
  • tested
  • updated when everything works
  • used for stable packages

Once the aspnetcirelease feed is stable, we push the packages from it to nuget.org.

Unless you work on developing new features for ASP.NET, I recommend that you use aspnetvnext (for dev bits) or nuget.org (for release bits). The release feed (aspnetrelease) is just a staging feed and it's not always in a good shape.

Edit:

I think it's easier to understand from a table:

Which version of coreclr?

The version of the coreclr is in our application's project.json. dnvm list -detailed (from the previous toolchain) shows us runtime info which is completely irrelevant to the dotnet toolchain.

> dnvm list -detailed
Active Version         Runtime Architect OperatingSystem Alias   Location
------ -------         ------- --------- --------------- -----   --------
       1.0.0-rc2-16595 coreclr x64       win                     C:\Users\me\.dnx\runtimes 
  *    1.0.0-rc2-20221 clr     x86       win             default C:\Users\me\.dnx\runtimes

We can find the equivalent dotnet relevant information:

• Version and Runtime are in project.json's frameworks section (e.g. netcoreapp1.0, net451).
• Architecture and Operating System are in project.json's runtimes section (e.g. win7-x64).
• Location is our NuGet global-packages folder (nuget locals all -list) after restore and our project's bin after build.
• Alias and Active are obsolete.

"There's no dnvm replacement" for the .NET CLI and no command to "get the version of the coreclr." That is because the runtime is now fully specified in our project.json and installed with the dotnet restore command.

With the dnu/dnx/dnvm toolchain, we installed the runtime independently from our application and its dependencies.

1. We used dnvm install|upgrade|use to download and use a runtime; dnvm did not consult project.json.
2. We used dnu restore to download application specific dependencies; dnu did consult project.json.

With the dotnet toolchain the restore operation combines those two steps. It consults our project.json and downloads both the runtime and the dependencies.

dnvm does not interact with the dotnet toolchain. In fact, we can delete the ~/.dnx directory and dotnet will build our project.

---

Related Topics