Discussion for: Renaming to ASP.NET Core 1 and Entity Framework Core 1 #1255
Comments
|
Is there a possibility of an upgrade tool / script which you could for example run on an RC1 project directory that would then update the references and namespaces across the files? |
|
Maybe you going to fix the namespaces for IApplicationBuilder and IHostingEnvironment too? I think they are inconsistent at the moment. IApplicationBuilder -> Microsoft.AspNet.Builder IConfiguration -> Microsoft.Extensions.Configuration |
|
@endeffects 👍 I understood from your message, new Namespaces would be: IApplicationBuilder -> Microsoft.AspNetCore.Builder Please correct if, I misunderstood it. |
|
No, i think they should be part of the Microsoft.Extensions Namespace. I also think it would be better not to limit such common names like "ApplicationBuilder" and "HostingEnviroment" to the AspNet Namespace, but by having a look into the interfaces this seems not to be an option. |
|
Not really, we're not moving those things as they are part of the ASP.NET libraries. They are specifically made for ASP.NET web applications. Things under the Extensions namespace and assembly can be used outside of ASP.NET. That's the distinction. |
|
Well, in my Startup class i'm able to prepare everything without the AspNet Namespaces (if needed): public Startup( IApplicationEnvironment applicationEnvironment ) { } But as soon as i'm going to use my setup i'm falling back to AspNet. From my point of view this is wrong, but i understand the reason for it. |
|
Can I just confirm also about Microsoft.AspNet.Identity? This also will be considered 1.0.0 of Microsoft.AspNetCore.Identity going forward? I'm writing a blog post on this and may as well get it right from the offset. |
|
Will RC2 be released in February 2016 and will it include all these renaming changes? |
|
@AspNetWebDev Yes, and @davidfowl has confirmed that several times on JabbR ... https://github.com/aspnet/Home/wiki/Roadmap |
|
shouldnt there be a discussion (or at least a placeholder issue) happening here https://github.com/aspnet/EntityFramework/ since people contributing to EF may not be watching aspnet/Home |
|
re the nuget renaming what is being done to communicate this to downstream nugets? what is being done to help them transition? is there an upgrade guide? some example scope of what will be effected
etc and please dont refer me to a blog post. there have been so many contradictory blog posts leading up to this change that many people have switched off from that channel. will there be any tooling added to nuget to support package renames? |
There should only really be a few packages that are affected downstream and we don't really have a great way to send out messages to package owners about package renames other than blog posts, or github issues and announcements.
Those numbers are for the existing stack and the packages were already affected since they don't work with the new stack anyways. So that's always been an issue. That was actually the purpose of this rename, to make it obvious that any thing that extended in the existing stack wasn't going to work with the new one.
Nope. I do think we should offer a script that will mechanically update your project's namespaces and package names (or at least tell you what the old packages are). It's pretty trivial and would be better than doing nothing (what we've done in the past 😄 ). |
|
What will be the new name for MVC 6? None of the blog posts I read so far have any clear information about that. |
I keep seeing this question asked, MVC is now ASP.NET Core MVC 1.0 /cc @shanselman @DamianEdwards @csharpfritz Can we update the blog posts to explicitly call out the names. |
|
So, what would be the abbreviation for this so it can be easily searchable and discussed and referenced? Just calling it MVC1 is going to confuse a lot of people. It seems silly to complain about having to type all those other letters to describe what you're talking about, but I see that being an issue. We could shorthand it as MVCC or CMVC or something like that...(and btw, I hope I'm in the spirit of proviso at the beginning of this thread - though I do wish there was another for discussing the merits of the name change itself.) |
|
You could just abbreviate it to "MVC Core" and I won't hate it 😄 |
|
@davidfowl why not leverage the contact owner feature of nuget? |
The few package authors that have extended ASP.NET Core hopefully pays attention to these channels. That's not to say we couldn't send out a bunch of emails, we could investigate that as well. But's it's really not as much as you think (as I said before, the numbers you mention earlier in the thread aren't correct). |
True, but before the rename people were used to the pattern of "do a nuget update and fix all the compilation errors and make the tests pass". I dont think this pattern failed for large scale changes such as "mvc core". I would have said as such in the decision making process of deciding to rename, but i cant seem to find it, or missed that discussion?
Every major upgrade of the tooling in question has this issues. That is that the major version number indicates. The rename approach simply doesnt scale. If u want to do major changes in a future version will u come up with another moniker and break all the nugets again. The interesting thing is this "breaking" framework approach has already happend and there is an accepted approach for multi-targeting nugets, the lib per framework approach. I dont see any reason this approach would not have stood up well under the core rename. The problem we now have is some portion of downstream nugets will take the rename approach, to reflect the ms approach, and some will continue on split lib approach. You have also set a dangerous precedent "significant changes in a nuget should result in a rename". Nuget is simply not built to handle this in a graceful way since it was never a design decision that was considered. |
We've done this like 5 times over the last 2 years (unfortunately) from k, dnx, and now .NET Core and ASP.NET Core. This is the final rename (famous last words) and we'll do our best to let people know what the new names are. If that means we need to reach out to the < 50 people that have extended MVC then so be it. The bigger issue is telling people that have existing projects that they can't upgrade the version (although that's advantageous because it's a different product)
We can't use target frameworks because the new stack runs on the same frameworks (and more) than the old stack.
As they have to because it's a new stack that runs on the more frameworks than the old stack. It's just a different pivot and that cannot be represented in nuget.
That's how it should be actually. If you're making a different things, make a new package id. Upgrading to the next version when it's a fork is bad like 99% of the time. You cannot update from MVC 5 to what was once called Mvc 6. You cannot update from EF6 to what was called EF7, they are fundamentally different products and a new package id is what makes the most sense here. FWIW: @avanderhoorn and I spoke about this in depth several times and theorized a bunch of different nuget features that would make this easier (like the ability to pick a top level package based on what dependencies you had in your project) but nothing ever came of it. |
|
Just to clarify, i dont mind the rename evolution, i am just concerend about the nuget rename impact.
That is an interesting point. Is that discussion had in more detail somewhere so i can get more context of the implication? |
|
Also is the recomendation that every downstream nuget that targets core be renamed? Can the rules for this be articulated somewhere and communicated? |
I'm not sure there's a specific discussion anywhere but we say it in all of our talks, it shows up in our diagrams and it's in the packages that we ship (they support both
See how ASP.NET Core stretches over to .NET Framework 4.6? That's because the new stack runs there as well. |
If you target ASP.NET Core then yes you should absolutely rename to Blah.AspNetCore. This is what glimpse is doing because they need to support both existing and the new stack. Sure, we can write something for library authors that extend ASP.NET Core. BTW this is similar to what people have been doing in the past:
https://www.nuget.org/packages?q=Mvc3 This is no different... |
|
Are we done renaming? Honest question. Do you foresee more changes from AspNet to Extensions to Core to whatever. What really sucks about all this is that names like Microsoft.Extensions.Primitives mean absolutely nothing to anybody except the person who came up with it and some guys he/she projected on to get suggestions. That's why at least 50% of your changes repeat themselves. |
AFAIK, yes. AspNet -> AspNetCore, Extensions stayed as it was.
Yep. Naming is hard, but done. May I not eat those words 😄 |
|
Also note that Microsoft.Data.Entity has been renamed to Microsoft.EntityFrameworkCore |
|
Just a little question, I've seen that the Roadmap now shows "TBD". |
|
@vncastanheira TBD = "To Be Determined" (no firm date) |
@davidfowl so to clarify, if I had a package which was going to be called |
|
@kevinkuszyk if it's a library specifically for ASP.NET Core, then I would definitely recommend having And if it's specific to MVC, yeah, add As far as the version, that's a tricky one. It's certainly not needed per se, assuming the package dependencies are set up well. |
|
MyGet/aspnetvnext libraries was updated. Is there any news when VS2015 tools will be updated to use new |
|
@anfomin Date is TBD, but they've said that they're working on revised dates. See ... https://github.com/aspnet/Home/wiki/Roadmap https://youtu.be/qPz3E8Ij2KQ?list=PL0M0zPgJ3HSftTAAHttA3JQU4vOjXFquF [At 7:07] |
|
@anfomin we don't yet have a specific date for the updated VS tools, but we are working on an update to it. |
|
@Eilon Side (but related) question: When speaking of VS, VS Code is rarely mentioned. I heard that VS Code was going to get an update fairly soon to make Can you provide any info on how the VS Code update is coming along? Can you say how we would be informed that that update has been delivered so that I know when I can convert the |
|
@Eilon Excellent. I find the moniker |
|
@guardrex We don’t have a downloadable package yet for OmniSharp on dotnet. But you can build from source. I pinned dependencies and mirror the packages feed so build from source is rock solid. Please sync code from OmniSharp-Roslyn dev branch and build from there. To use it in VS code, you just need to update the user setting add following line: {
"csharp.omnisharp": "<path to the omnisharp executable>"
}I’m working on get a downloadable prebuilt OmniSharp on to github. |
|
Hello, Visual Studio 2015 is currently trying to parse cshtml razor files using Microsoft.AspNet.Tooling.Razor package, even though all the solution is targeting Microsoft.AspNetCore. What is the solution to this problem? How to update the visual studio razor tooling engine package reference? I would also suggest to make the visual studio razor engine package referencing more dynamic which could allow developers to change it more easily like was attempted in previous visual studio versions via web,config file setting. Note: I have searched for a couple of hours for any mention of this problem in github and google and found no mention which surprizes me :o |
|
@NTaylorMullen what are your tips & tricks for using Razor RC2 in VS tooling RC1? |
|
BTW, I updated 9 hours ago to 1.0.0-rc2-16551 and since then, the Roslyn fails to compile razor views at all (the previous errors still displayed but previously they atleast allowed compilation and were only intellisencse related but now the compilation fails). Which built the view class string and is now compiling it and the view generated code is (I changed my private namespaces names) is the following (see below), which looks like an OK c# while there are about 70 compilation errors from Roslyn and the main issue is that Roslyn can't locate any reference to System namespace or any other namespace. Seems like it did not put it in the dependency of the temporarily generated assembly which was generated for the compilation. Any ideas on this problem? Edit: Now when I read the code of: https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNetCore.Mvc.Razor/Internal/DefaultRoslynCompilationService.cs I see that the code DOES load the current assembly references...so I really don't get it why those compilation errors can't resolve System namespace and other namespaces. I will keep digging. Edit2: It seems that the referenced libraries by the current assembly fail to load because they are looked at in: System.Reflection.AssemblyName(PlatformServices.Default.Application.ApplicationName)).GetManifestResourceStream("PROJECT.NAME.deps.json") The generated code (EDIT: I delete it because it is too long and i came to the conclustion that the problem is not related to the code): I have opened a new issue for this here: aspnet/Mvc#4185 |
|
Hmm, sadly there's no good solution to this. Now that all of the bits are renamed VS tooling is looking for packages that are no longer referenced. It's not as simple as just adding references to the old packages either. If you did that it'd be pulling in essentially two MVC/ Another problem you'll see when working with rc2 bits is that there'll be lots of red in .cshtml pages. Another issue due to renaming AspNet => AspNetCore 😢. |
|
@NTaylorMullen What will be if one would interpret AspNet and AspNetCore assemblies as the same assembly with some another, but the same pseudo-name with optionally some +x increment in the version. I can explain it on an example. One can make the follow mapping Microsoft.AspNet.Identity.EntityFramework 2.2.1 -> Identity-EF 2.2.1 It means that Microsoft.AspNet.Identity.EntityFramework will be mapped to pseudo assembly (id) "Identity-EF" with no version increment. Microsoft.AspNetCore.Identity.EntityFrameworkCore will be mapped to the same pseudo assembly (id) "Identity-EF" with +2.0.0 increment for the version. It would allow to compare assemblies, to interpret old and new assemblies as the same assembly and to process the version changes correctly too. I suppose that one could solve the most problems in the way. One need just have some small database for all assemblies (package names) and to hold an optional increment value for the version. One could hold the information in the NuGet database for example. What I wrote above is just a small variation of the old suggestion. |
|
Sounds like a good client side tool that you could write that would manually update all of the code and references. It wouldn't fix any of the code of course, it would just fix project.json files. |
|
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. |
- Allow identical `@using` directives in the primary document. This means that if a user types `@using System` twice in the primary document (i.e. `Index.cshtml`) then we'll generate that using statement twice; this enables proper C# IntelliSense to light up on both using statements and allows auto-completion to work because there's no more magical distinction logic for Razor code that is in the current document. - Prior to this change if you had two identical using statements in the same document one would be in no-mans land mapped to nothing (not C#, not HTML) and the other would be mapped to C#; the second a user differentiated the two statements (i.e. adding a `.`) we'd distinctify the using statements resulting in an invalid completion. - This PR has an end-user impact where they will now receive the normal C# warning about having duplicate using. I treated this prior behavior more as a bug because we threw away the first using directive instance which impacted editing and in general was a silly thing to correct for the user. - Added new integration test showing how using directives are not de-duplicated in the primary document. #1255
ghost
locked as resolved and limited conversation to collaborators
and others
This is a discussion post for the Discussion for: Renaming to ASP.NET Core 1 and Entity Framework Core 1 announcement.
Please use this issue to discuss any questions you have regarding the renaming (and re-versioning) of ASP.NET and Entity Framework.
(I hesitate to mention this, but please try to refrain from discussing the merits of the change - rather, please keep discussions focused on the change itself and any technical questions surrounding it.)
Original Announcement Post
Hi everyone -
As you may have seen in this week's ASP.NET Community Standup and Scott Hanselman's blog post ASP.NET 5 is dead - Introducing ASP.NET Core 1.0 and .NET Core 1.0, ASP.NET 5 is being renamed to ASP.NET Core 1 and Entity Framework 7 is being renamed to Entity Framework Core 1.
In this post I'll share some of the technical details of the update to prepare you for the change.
The three largest parts of the change are:
Microsoft.AspNet.*packages and namespaces are changing toMicrosoft.AspNetCore.*.EntityFramework.*packages and namespaces are changing toMicrosoft.EntityFrameworkCore.*.1.0.0-*.Some smaller changes are:
0.1.0-*. This is going to be used in packages that are not quite ready for prime-time and so we are leaving them in a pre-release state. For example, the SignalR packages remain in this state for the time being. Once 1.0.0 ships we will work to bring these packages back to the RTM state.Some things that are not changing are:
Microsoft.Extensions.*packages are remaining pretty much as-is (same names, same versions).There are a number of small exceptions to the items above, such as the
Microsoft.AspNet.Identity.EntityFrameworkpackage being renamed toMicrosoft.AspNetCore.Identity.EntityFrameworkCore(to reflect the new names of both ASP.NET and Entity Framework). We will post a full list of renamed packages so you can quickly see the before/after.This is of course a rather large task, and we have already started work on the rename, and we kindly ask for your patience as we work to resolve all the issues.
We are working on a guidance document that provides further details and we will post a link here when that is available.
We will keep this issue updated with any related breaking changes.
Many thanks,
Eilon Lipton on behalf of the ASP.NET and Entity Framework team
The text was updated successfully, but these errors were encountered: