Update NuGet package names

[rowanmiller]

Implement the naming principles we agreed on https://github.com/aspnet/EntityFramework/wiki/NuGet-Package-Naming

[Eilon]

What happens to namespaces? Do they change as well?

[rowanmiller]

We weren't planning to. Side-by-side scenarios usually have the data models in separate projects with a different version of EF referenced in each project. So it's really just the assembly name conflicts that cause issues.

[Eilon]

Ah, good point. Need to think about how this affects docs/searches though, but I guess because the new docs are a clean separation from the old docs that's sort of an issue either way.

[ErikEJ]

Looks like a 7 is missing in the first paragraph.. But like the convention!

[rowanmiller]

@ErikEJ the missing 7 was due to EntityFramework<major_version_number> not being valid markdown... updated now :)

[rowanmiller]

@Eilon EF6 and earlier were System.Data.Entity and we are now Microsoft.Data.Entity so we sort of solved that one

[Eilon]

Ah, yes!

[ctolkien]

Is this going to apply for Beta5 release time frame?

Edit: Probably should add, I don't feel like this is a good descision. Stick with semver for versioning, people that want to run both versions are SOL!

[ErikEJ]

@ctolkien Nope, from beta6 (beta5 is already released)

[ctolkien]

Thanks @ErikEJ - had noticed that Beta5 hadn't made it over to Nuget.org with the rest of the Beta5 asp.net packages today, so wasn't sure if this was related.

[ErikEJ]

@ctolkien Ah, did not know that, just was notified of this today: https://github.com/aspnet/EntityFramework/releases

[rowanmiller]

@ctolkien the Beta 5 packages are on NuGet.org now (https://www.nuget.org/packages/EntityFramework.SqlServer/7.0.0-beta5). We didn't publish the EntityFramework package since it was just a meta package and it will go away in Beta 6 with the renames from this issue.

BTW we aren't making much noise about Beta 5 from the EF7 side because there isn't a huge amount of new stuff in it. Beta 6 will be a much more interesting release for us.

[rowanmiller]

Note that there was significant discussion around this rename on the announcements repo. That issue is now locked and discussion has been directed to this issue.

[Anderman]

Thx for closing the announcement. But could nuGet just fix this issue, so that we can skip this issue?

[luisrudge]

I don't like this idea and this will set a bad precedent for other package maintainers.

[ghost]

I really dislike the name change. I guess I need to understand the SXS issue and the rationale behind people wanting to do it. To me it seems completely nuts and is asking for trouble.

Furthermore, I believe that this will strongly set the wrong precedence for other package authors and generally make a mess of NuGet. Major version changes will no longer be discoverable through NuGet instead increasing reliance on blogs etc.

Doesn't Entity Framework 7 v1.0.0 seem just a bit odd?

Please, for the love of the community, don't do this.

:-1:

[regisbsb]

Could we please do not do it. I feel bad that it slipped thought the community. This is a bad idea and Nuget already supports caping versions. Side by side loading is such a niche use case. Any way if needed some one must create a anti-corruption layer that will reference the old one while the new layer will use the new one without binary comunication (wcf, rest, homing pigeon, whatever). I can see that this is more a desire to change the name than a tecnical limitation. And it's a bad example set by the most downloaded package in nuget repo.......

[JamesNK]

A downside you haven't included is people will be confused when EF8 is a thing but the package still says EntityFramework7.*

Edit: Ah, you're planning to make a separate package every release.

[luisrudge]

Also, nuget's most downloaded packages page in a few years:

• Entity Framework
• Json.NET
• Entity Framework 7
• Entity Framework 8
• Entity Framework 9
• Entity Framework 10

[rowanmiller]

@JamesNK

Edit: Ah, you're planning to make a separate package every release.

Yeah we saw the issues we are trying to avoid with the EF5 => EF6 breaking changes. To a lesser degree because the changes were less drastic.

[rowanmiller]

@luisrudge I agree that in some ways that is worse... but in reality it's not hard to work out which package you should install. And as the popularity of versions grows and shrinks over time it will appear and disappear from the list.

[rowanmiller]

@regisbsb

Side by side loading is such a niche use case.

We actually see folks want to do this quite a bit.

• The most prominent one at the moment is wanting to use EF6 in an ASP.NET 5 application when ASP.NET Identity uses EF7. The fact that Identity uses EF7 is largely an implementation detail, but clashing assembly names means it fails to load whichever version you try to use second.
• It's also not uncommon to have multiple data models in the same app. When upgrading folks often move the models incrementally or use the latest version for new models. Historically this kind of worked because of our move from being part of .NET to partially out-of-band to fully out-of-band and the resulting assembly and namespace changes along the way.

[rowanmiller]

@sblackler

Doesn't Entity Framework 7 v1.0.0 seem just a bit odd?

Yes that would be odd :smile:... the package version is still 7.0.0... which is still a bit odd for a package to start at 7 and only ever have one major version.

[rowanmiller]

Thanks for all the feedback folks. So far, most of the negative feedback has fallen into two categories.

• "I don't like this", "this seems wrong", etc. - I don't mean to down play this in any way, gut feelings and "code smells" are often a good sign that something is wrong. We had the same reaction when we started discussing this, but the more we discussed the more we came to the conclusion that it seems academically wrong but pragmatically it solves the issues we face pretty nicely. It would be great if folks can ponder the aversion to the approach a bit further and let us know of concrete scenarios that are broken/worse due to this approach.
• "You're ditching SemVer" - I don't think this is valid because the fact that our versions aren't all listed as versions of a single package doesn't mean we aren't following SemVer. http://SemVer.org doesn't really prescribe anything about how versions are distributed, whether they can be installed side-by-side, etc. It is mostly concerned with when to bump the major/minor/patch version etc. and we are attempting to follow that with EF (although no doubt imperfectly).

The issues with download counts being spread across the multiple packages and those multiple packages showing up separately in search is valid and that is definitely a downside of this approach.

[luisrudge]

@rowanmiller why isn't nuget's version constraints enough?

[herecydev]

^This. Seems the obvious solution would be:

"dependencies": {
        "EntityFramework": "7.*",  // Matches all versions of EF7

You then have the control of moving it down to any patches, etc.

"dependencies": {
        "EntityFramework": "7.0.*",  // Matches any patch of EF 7.0

[Anderman]

Most likely to happen when someone is using EF6.1.3 and we release EF6.2.0. They run Update-Package and get automatically upgraded to EF7.0.0. They then need to undo that and run Update-Package -Version 6.2.0.

[regisbsb]

It's a workaround to support a use case (SxS) that I believe could be addressed differently with binary isolation in the solution itself that wants to use 2 EFs. Well if SxS trumps using a bad versioning approch I believe we cannot discuss it any further.

[herecydev]

Shouldn't this issue be reopened? Given the intense conversation in the announcements it's still clearly an issue.

[luisrudge]

Unless this is already set in stone.. Then please let us know so we can stop arguing about something that is not going to change.

[miguellira]

@rowanmiller Although I'm sure there are other SxS scenarios that will still warrant the name change, it sucks that the latest version of Identity is taking a dependency on a package (EF7) that has less feature parity than its predecessor. I'm curious, if that dependency is abstracted (which I'm sure you and/or the Identity team have already discussed) what's the next most prominent use case?

[milutinovici]

I propose you name the package Entity Framework X (as in crossplatform), or Entity Framework Core, and set the version to 1.0.0. And follow SemVer.

[bricelam]

@herecydev Even with a version of 7.* in the project.json, Update-Package (or nuget update) will update to 8.x. The user can optionally specify -ToHighestMinor to preserve the major version or -Safe to preserve the major and minor version, but neither of these are the default update behavior.

Ideally, if NuGet truly followed semantic versioning, Update-Package by default wouldn't cross major version boundaries unless you specified something like -WithBreakingChanges.

[herecydev]

That's a behavior that should be addressed, if I'm wildcarding like 7.* the nuget update should honor that always. With that behavior, we could enhance the tooling so that when tabbing a dependency:

"dependencies": {
        "EntityFramework": 

It would autofill out to the latest major version with a wilcard on the minor version:

"dependencies": {
        "EntityFramework": "7.*" //7 determined by looking at the latest major number

Regardless of what's happening outside of the project the project.json shouldn't change and thus will pick up the dependencies as expected. It should be clear that with proper tooling none of this EF change would be necessary and so many comments are saying this.

[bricelam]

none of this EF change would be necessary

Except for the fact that the CLR won't let you (easily) load multiple versions of an assembly into the same AppDomain.

[herecydev]

On a separate note, if you're worried about people calling nuget update and it breaking their projects, don't you think you're hand holding them a little bit with this change. That's something they have consciously done and are wholly responsible for.

[herecydev]

Except for the fact that the CLR won't let you (easily) load multiple versions of an assembly into the same AppDomain.

I can't speak much about this as I haven't needed this functionality myself. I also don't know enough about the CLR to understand the technical limitations, but it doesn't feel like the correct solution to rename the package name instead of the version to overcome this.

[bricelam]

Personally, I think I'm starting to agree with you on the hand-holding point. The NuGet workflow seems to be changing a lot with the introduction of project.json, and I think users will need to become a lot more aware of its mechanics to be effective.

[bricelam]

One option would be to change the assembly names to EntityFramework7.* (or EntityFramework.*.7 to borrow from VS), but keep the NuGet packages EntityFramework.*. Of course, having different assembly and package names is also frowned upon.

[herecydev]

Of course, having different assembly and package names is also frowned upon.

At least the wild carding above would still resolve correctly, the project.json is still the "go to" place for seeing everything about the project and how it works behind the scenes is somewhat out of the developer's concern. Though I agree it's still not perfect.

[Jetski5822]

I agree, this seems like a hand holding exercise that is unnecessary, if anything, I think it will end up causing more confusion... and what worries me even more is that it means that people will be able to use two versions of EF in the same project.

[Bartmax]

TL;DR:

• - Don't rename to Entityframework7 (follows pure semver)
• - Create a new package EntityframeworkSideload that holds any past version. (for SxS)
• - Change default behavior of nuget to preserve major version by default and update only with a flag. (preventing customer of breaking changes for all packages, not only ef)

Requirements

So there are two requirements: 1 - Don't make people auto update by mistake on breaking changes. 2 - SxS Entityframework. Note: Follow semver as much as possible

1: Auto update: - nuget approach.

Update update can respect the major version on update, and having "package": "7." will keep version 7 (or as other solves this with ^ and ~ characters, I think \ is way clear). This is already supported but not the default behavior.

For new projects with project.json, new is not a problem since everything is new, nuget included. For non project.json projects this will be a big change but with no breaks. People may think why it didn't updated ?? but that's it. Since most non project.json developers that wants to update uses the GUI, it's a matter of having Update and UpdateToLatest (breaking changes) buttons when appropiate. Also the cli client can inform if you do Update-Package that Package version 9 of x assembly is found but it wasn't updated because it's has a higher major version of currently package installed and has breaking changes. Use -updateMajorVersion flag to update package beyond current major verions.. bla bla bla

Automated tools don't update major versions (breaking changes), so I don't think any script will be broken with this behavior change.

So, your packages won't update beyond your major version by 'itself' which is good.

2: Side by side

The already the proposed solution to change EntityFramework to Entityframework7 have some downsides which are: 1 - confusing customers/people 2 - suggesting that changing major versions on names can be 'good' 3 - nuget stats (most downloaded, etc).

If you already have a project with EF6 (or any version of EF for that matter) and you want to include that in your new NET5 project, but also want to use EF7, the proposed solution is to use/have something like this:

"EntityFramework": "6.x.x",
"EntityFramework7": "7.x.x",

Ok, here is my 'attempt' to fix them.

Don't rename Entityframework to Entityframework7 Create a new package (and assembly name) EntityframeworkSideLoad When you release a version of Entityframework (latest version -1), release also as a sideload package.

Then if you need SxS you need to load the SideLoad package.(being a SxS transitional optional approach, i think this makes sense)

"EntityframeworkSideLoad": "6.x.x", // this can be version 4, 5 etc..
"Entityframework": "7.x.x",

Name can be anything, (sideload, compat, back, previous, secondary, alternate, whatever) and you can use EntityframeworkSideload with ANY (see future proof below for why this is important) version (except the latest)

Current projects targeting Entityframework v6 should be able to change to EntityframeworkSideload v6 without any breaking change (since is the same code, I don't see a problem here).

Additional, latest version won't be on SideLoad package, so even if nuget doesn't 'fix' the update thing, you can use EntityFrameworkSideLoad to keep your current version (well, until EF8 is released). That's a lot of time to migrate completely and to give Nuget team to fix the auto update thing.

Ok how this fixes the downsides: 1 - Confuse people: With this approach, people would never ever know or needs to about the SideLoad package so no confusing.

2 - It won't encourage people to change version numbers on packages, as microsoft creates a new packages, specific approach for this particular scenario.

3 - Stats will be preserved, and also we can see how many people are sideloading EF using the SideLoad package stats. So, more accurate data instead of less and inaccurate.

Bonus: It's 'future proof' for something that may happen again.

"EntityFrameworkSideload": "7.x.x",
"EntityFramework": "8.x.x",

For those that 'need' SxS, having to install this 'new weird package' is acceptable. If you need to work with 2 EF, this should be the minor of your problems.

[luisrudge]

Awesome @Bartmax

[ErikEJ]

@bartmax VS 2015 will release on monday, and the default NuGet behavior will most likely not change until NeXT VS release

[luisrudge]

@ErikEJ nuget is just a visx, right? There's nothing stopping the nuget team to relaese a new version without a vs release.

[ErikEJ]

Yes, but you must also opt in to install the update...

[Bartmax]

@ErikEJ if you read, my proposal doesn't need a nuget update, and it's more about Entityframework package rename than anything else.

[bricelam]

@Bartmax What about the CLR limitations of loading more than one version of the same assembly?

[Bartmax]

@bricelam I may be missing something but if the package is EntityframeworkSideload the assebly won't be the same. you will have 2 different dlls, entityframework.dll and entityframeworksideload.dll may be wrong. I don't see how this is different from having entityframework and entityframework7.

[divega]

you will have 2 different dlls, entityframework.dll and entityframeworksideload.dll

Not sure providers written against entityframework.dll would work with entityframeworksideload.dll.