Efcore.pg: Change Dependencies and Namespaces for EntityFrameworkCore

[roji]

_From @julielerman on January 31, 2016 23:26_

Such a pain but you probably know ASPNET and EF7 just got renamed. EF packages are now Microsoft.EntityFrameworkCore.* and namespaces follow suit. For someone already well-versed in this project, it might be a quick task .

_Copied from original issue: npgsql/npgsql#966_

[roji]

_From @natemcmaster on February 3, 2016 22:44_

+1 for renaming to Npgsql.EntityFrameworkCore.PostgreSQL (see https://github.com/aspnet/EntityFramework/issues/4376#issue-128217800)

[roji]

Hey guys, I've been away from Npgsql for some time now, but am coming back to life in about a week - will also pick up on EF work.

[natemcmaster]

Welcome back!

[roji]

I've done some work on porting the provider to rc2, everything now compiles cleanly. I haven't executed any tests so there's still probably some breakage but it's a step forward. Will work on making it actually run soon.

[julielerman]

I'll be moving my sample to RC2 shortly and will let you know how things go. I'm not doing a lot of crazy things so won't be pushing on edges too hard.

[roji]

Please do, I'd love some feedback! FYI am planning to release new versions of both the EFCore provider and Npgsql itself right after RC2, things will probably be a bit unstable but we're used to that...

[julielerman]

I can't remember where I brought this up, but remember when I said I could use migrations with RC2 without the design package? In RTM I'm noticing that's the case for migrations but scaffold needs it. So I think that I hadn't tried scaffold earlier. This seemed like the best place to drop this note. :)

[roji]

@julielerman thanks for the note, it makes sense that the design package is needed for scaffolding, since that process involves some very Npgsql-specific components.

FYI just yesterday I added a fix which will make Npgsql.EntityFrameworkCore.PostgreSQL required for creating migrations as well, since Npgsql introduces 2 totally PostgreSQL-specific migrations (create extension, drop extension).

[julielerman]

Oh! Thanks for the heads' up since I'm doing demos in a few days at a conf, I'll be ready for that change. I have to admit that I had to google that hasextensions stuff when I saw those issues since I'm not a postgres hard-core user. :)

[roji]

@julielerman sure. The only really mainstream things that depend on extensions is database UUID generation (which PostgreSQL doesn't have without the uuid-ossp extension) and PostGIS, the rest is a bit more exotic.

I have to say it's really cool that I could actually add first-class migration operations in EFCore for adding and removing extensions, it shows how extensible the design is.