Aspnetcore: Discussion for: .NET Core RC2, ASP.NET Core RC2, and Entity Framework Core RC2 are released!

[Eilon]

Discussion for: https://github.com/aspnet/Announcements/issues/177

---

Check out the announcement posts:

• Announcing .NET Core RC2 and .NET Core SDK Preview 1
• Announcing ASP.NET Core RC2
• Announcing Entity Framework Core RC2

All the downloads are available at the .NET Downloads page.

And finally, some of the key documents that can help with this release:

• Migrating from DNX to .NET Core CLI
• Migrating from ASP.NET 5 R1 to ASP.NET Core
• Upgrading Entity Framework from RC1 to RC2

[Kurira]

What's the new way to create a project to be used as a "tool" (previously as a command)?
I can't get console application to inject default IServiceProvider, IApplicationEnvironment instances anymore, is there a way to get them?

What's with all the new monikers?
is dnx451 = net451 and dnxcore50 = netstandard1.5? Because I see console app using netcoreapp1.0 and Microsoft.NETCore.App all over the place. What should be used for windows only and cross plat configurations? I'm confused :confused:

[moozzyk]

Tools are now just netcoreapp1.0 apps whose name start with dotnet-. In the project you want to use the tool you would add a reference to the tool's package in the "tools" section in the project.json. If you are looking for an example take a look at the publish iis tool: https://github.com/aspnet/IISIntegration/tree/dev/src/Microsoft.AspNetCore.Server.IISIntegration.Tools. Here: https://github.com/aspnet/cli-samples/blob/master/HelloMvc/project.json#L33-L41 you can find how to register the tool in your project and how to invoke it (in this particular example it's being invoked as postpublish script but you can also run it from command line using dotnet publish-iis. Note that the tool dll name is dotnet-mytool but when you want to invoke it you use dotnet mytool (i.e. you skip the dotnet- prefix)).

[NTaylorMullen]

@Kurira to get the ApplicationEnvironment in a tool utilize this.

What should be used for windows only and cross plat configurations?

Tools target netcoreapp1.0. You'll see some tools target net451 like RazorTooling and EF below but they're initial entry point is always invoked via the netcoreapp1.0 tfm

As for an example of a new-dotnet based tool take a look at any of the following:

• dotnet publish-iis
• dotnet watch

And finally some more complex tools that rely on user code:

• dotnet razor-tooling
• dotnet ef

This isn't all the tools that we ship, just a starting point :smile:. Hope this helps!

[Jupakabra]

Hello,

Thanks for the release.
Is there a difference between installing x86 or x64 .NET Core?
Current templates don't include either of those in global.json, I'm guessing that x86 is used by default?

[Kurira]

So netcoreapp1.0 is for tools, but how do we know if that tools runs on net or on core? Or is it both by default?

[NTaylorMullen]

@Kurira It always initially runs on core. In the later tool examples I provided (razor-tooling/ef) they re-invoke themselves in the users build output in the case that a users project only targets a net TFM.

That's why in watch/publish-iis they only target netcoreapp1.0 because they don't need to do anything with user code; running only in core is sufficient for them.

[keith-vikode]

Has the ability to deploy source code gone for good along with DNX? It's not a deal breaker, but I did find it very handy for finding out just what code was deployed (as well as for adding emergency logging statements!)

Also, and with no evidence to back this up other than gut feeling, the time taken to recompile the app after making a code change when running in VS seems longer using the CLI vs DNX. The short cycle between making changes and F5'ing to see them was, for me, the most awesome feature of VNext - really hope I'm imagining it!

[mrahhal]

@NTaylorMullen how exactly does the ef tooling re-invoke itself? I have a dnx command that runs only on net that needs to access user's code as before (that I want to port to RC2 naturally). The command has dependencies that only run on net (let's say EntityFramework for example). But till now I have found zero info on the subject. How does it all work?

If someone from the team can explain this tool (formerly command) builders will be grateful (I'm not sure if docs are coming, but for now searching about this yields nothing).

[NTaylorMullen]

@mrahhal So i'll use razor-tooling as an example since I have more context. With tools that need to run user code you currently need the following criteria: https://github.com/aspnet/Tooling/issues/484#issuecomment-219807702

Now, when you type dotnet razor-tooling at the command line, dotnet always tries to invoke the netcoreapp1.0 tools version of your tool (remember, it exists in the tools and dependencies sections of your project.json). So it boots the razor-tooling tool and the tool determines based on the command line input what it should do. It has 3 paths.

1. Command line arguments do not result in any sort of user code work. Do all the work in the current process, don't do any re-invocation.
2. Command line arguments warrant user code work and I'm the tool instance that was referenced in the tools section (I'm the dispatcher). Re-invoke myself in the users build output. Example showing how the tool determines if it is the dispatcher. Example showing how to dispatch.
3. Command line arguments warrant user code work and I'm the tool instance that was referenced in the dependencies section (I'm the worker). Perform work on user code. Example showing the razor-tooling code inspecting the users projects for TagHelpers.

One thing to keep in mind with the new tool system is that it's not a port of DNX commands into the new CLI world. Treat it as a completely new system. Now, that being said it has some rough edges that we're aware of and we'll be working through those in the coming tool releases.

Hope this helps!

[mrahhal]

Thanks for the tip, but exceptions from dotnet.exe were occurring whenever I try to debug.

So, it's like the tool entry in the dependencies is non existent. This is what I'm doing in a project that's using the tool:

"dependencies": {
  "SomeTool": {
      "version": "1.0.0-*",
      "imports": "build"
    }
},

"tools": {
    "SomeTool": {
      "version": "1.0.0-*",
      "imports": "portable-net45+win8+dnxcore50"
    }
  },

"frameworks": {
    "net451": {
    }
  }

The tool is running, but the DotnetToolDispatcher.CreateDispatchCommand call is raising CommandUnknownException: No executable found matching command "dotnet-some".

This is how I'm calling CreateDispatchCommand:

c# DotnetToolDispatcher.CreateDispatchCommand( args, framework, "", outputPath: null, buildBasePath: "", projectDirectory: projectFile.ProjectDirectory)

[mrahhal]

OK, managed to get it working. The problem was the buildBasePath argument. It should have been null instead of an empty string. @NTaylorMullen great explanation and thanks a lot.

[guardrex]

@NTaylorMullen Your link to publish-iis tooling above ...https://github.com/aspnet/Home/issues/1457#issuecomment-219797002 ... It's missing the "s" (i.e., "Tools" at the end.

[mrahhal]

@NTaylorMullen I have a sample in the same solution that uses my tool. It used to work with commands, but right now It seems I'm not able to reference the tool through the tools section without installing the package and making it available through a nuget feed (restore says it can't find it). Is this true or is there a way to use tools in the same solution?

[moozzyk]

@mrahhal - unfortunately project to project references don't work with tools: https://github.com/dotnet/cli/issues/1215

[mrahhal]

:grimacing: Too bad.
Alright, thanks for all the help. I got it all working following @NTaylorMullen's explanation. I'll be referencing people to this explanation until the docs get done.

[Villason]

I find the project.json and the dependency web extremely confusing.

I don't to even want to understand the difference between dnxcore50 (why is there still a "dnx"), netstandard1.5, portable-net45+win8, NETStandard.Library, Microsoft.NETCore.App, netcoreapp1.0, dotnet5.6, etc, etc. All the names means nothing to the user. Why should he care?

I am struggling to migrate my RC1 solution to RC2 (it is just a web app + class libraries).

[mrahhal]

@Villason completely agree but I guess working in the open and getting to try all the new bits as they come out will naturally lead to this kind of situation.

Maybe we can help? You can try asking a question on stackoverflow and putting the link here. I think that's a better place for this.

[guardrex]

@Villason I wouldn't go SO ... that's not "chatty" enough for Q&A. You prob can find a free dev on Slack and get many of your questions answered. Signup at http://tattoocoder.com/aspnet-slack-sign-up/.

[guardrex]

... and in addition to the official conversion doc at docs.asp.net, I have some links here that might help: https://github.com/dotnet/cli/issues/2135#issuecomment-212692267

[EDIT] Here is the official one: https://docs.asp.net/en/latest/migration/rc1-to-rc2.html

[Villason]

I dunno I thought this was a discussion so I thought I could be in verbose mode. My first issue was just the first package I added to project.json:

"HtmlAgilityPack": "1.4.9"

C:\Program Files\dotnet\dotnet.exe restore "E:\Repositories\MyProject.vs\restore.dg"
Error: Package dependencies must specify a version range. WAT?

I guess I will go back to RC1. (I wanted to go to RC2 to avoid a RC1 bug that was slowing me down)

[davidfowl]

/cc @abpiskunov @emgarten

[guardrex]

@Villason I just mentioned it b/c a lot of rapid-fire Q&A on general .NET Core topics creates quite a stream here. If you have specific issues, of course, that makes perfect sense to discuss them here.

I can tell you that the devs at Slack (and JabbR) all day (and all night for that matter! ... Europe, Asia, Australia, Africa!) are happy to explain aspects on a variety of topics.

[Villason]

@GuardRex

[EDIT] Here is the official one: https://docs.asp.net/en/latest/migration/rc1-to-rc2.html

My issue is with the new project.jsons and library references. I guess I am not alone. My approach was to create a new solution with a web project + class library projects and start moving things from the old project. Then I was "overwhelmed" with all the interchangeable names things get and confused with Intellisense suggestions (like Microsoft.AspNetCore.Mvc.ViewFeature 1.0.0-rc2-final or Microsoft.AspNet.Mvc.ViewFeatures 6.0.0-rc2-16927. WAT?).

Ok, I will stop whining here and skip this Preview1 altogether. It looks like @davidfowl called the MS police :)

[abpiskunov]

@villason create two separate issues please and specify precise repro steps and add me and emgarten there.

1. Restore error: when you do restore for that project get whole restore output
2. Intelligence suggestions: you mean Ctrl+. Suggestions to add package? For what symbol you had those intelligence messages?

[guardrex]

@Villason Here's a little context: What happened was that a lot of design changes occurred between RC1 and RC2. It wasn't bad for those following along with nightly builds. We just slowly massaged things into RC2 over a period of several months. For those who were sitting tight RC1-final ... then coming into RC2-final ... :boom: ... that's a lot of deltas to run into all at once.

What many have been doing at Slack is helping people "walk" their RC1 app into RC2 form. Usually, we'll say, "Paste your WebHostBuilder in here." ... "Ok .. do this ... do that." Paste your project.json in here." ... "Ok ...do this ... do that." ... and just massage the app into good RC2 form. In the midst of those app changes, other questions occur and get answered along the way.

The docs are all updated now for RC2, and the main official conversion doc is really great. That was done by @rachelappel and hits all the main points. If your app is still not quite right, I'd suggest hitting up Slack :cat:'s for final touches. There are a lot of happy endings over there (as there are here). :smile:

[Villason]

@abpiskunov here we go:

Forget it works now. I don't understand why.

[emgarten]

@Villason if you hit it again please open an issue. Usually this error happens when a project.json file has something like "mypackage": "" and no version given. DNU treated this as floating, but dotnet restore requires a value here.

[Jupakabra]

Hi again, I have a tool witch targets netcoreapp1.0 and net451, do I have to create another project for my tool logic (like EF and other tools who rely on user code do) or having all the logic in one project is ok?

[mrahhal]

@Jupakabra my take: if the tool is not overly complex (for example, on par with EF core tool) then one project is more than enough. I maintain a tool that relies on user code and it's in one project.

[Jupakabra]

Great, I kind of followed EF and other tool examples by creating dispatcher and tool code projects. And I spend 2 full days ripping my hair out, because I needed to create nuget packages for both, tool code and dispatcher projects, not just dispatcher one :smiley:

[mrahhal]

You can also check mine here. It's simple enough and to the point.

[aspnet-hello]

This issue is being closed because it has not been updated in 3 months.

We apologize if this causes any inconvenience. We ask that if you are still encountering this issue, please log a new issue with updated information and we will investigate.