Today was dedicated to updating my long running repository sample that I started when EF Core was EF 7 to the newest version of EF Core: 1.1. Here is the updated repo: https://github.com/julielerman/EFCore-ASPNetCore-WebAPI-RTM.
Phase one of this update continues to use project.json.
In addition to updating the version #s of the Nuget package references, I also made some changes to the code to reflect a few new features.
Pay attention to the tooling packages. In the tools section, the package name has changed – note DotNet at the end – and the version is currently 1.0.0-preview3 even though IIS version is preview2.
"tools": {
"Microsoft.AspNetCore.Server.IISIntegration.Tools":
"1.0.0-preview2-final",
"Microsoft.EntityFrameworkCore.Tools.DotNet":
"1.0.0-preview3-final"
},
Also in the dependencies, the EFCore Design package is 1.1.0 like the rest of EFCore. That’s part of the EF APIs, not tooling.
Code changes ….
You’ll discover the DbSet.Find method and change tracker Load method in use in the repository class. These were both added in to EF Core 1.1.
I modified the WeatherEvent class to fully encapsulate its Reactions collection using the support for mapping to IEnumerable. That resulted in some changes to constructors and the addition of an AddReaction method and a local variable.
Unrelated to EF Core, I also modified the SeedData.cs class. It reads a hard coded seeddata.json file to read in seed data. That data used old dates. I wanted the data to show current dates to help me tell that I really and truly pushed new data into the database. Since the Date property of WeatherEvent is private, they way I went about this was to read the raw JSON and update the date value that way then save the raw JSON back to the original file. Then I deserialize the JSON with a current range of dates into a set of WeatherEvents. This also means that I added Delete/Create database back in so the database gets thrown away and recreated/reseeded every time you start up the application.
The tests are also update to use the latest packages. In addition to changing the versions, I had to add a reference to an older package (InternalServices) as its dependency has not yet been updated in xunit.
Here’s the full project.json for the test project since I had to do a bunch of googling to figure it out.
{
"version": "3.0.0-*",
"description": "Tests for simple app using aspnetcore, efcore and
postgresql. developed and run on OSX.",
"authors": [ "Julie Lerman" ],
"testRunner": "xunit",
"dependencies": {
"Microsoft.EntityFrameworkCore.InMemory": "1.1.0",
"src": "3.0.0",
"xunit": "2.2.0-beta4-build3444",
"dotnet-test-xunit": "2.2.0-preview2-build1029",
"Microsoft.DotNet.InternalAbstractions":"1.0.0"},
"frameworks": {
"netcoreapp1.0": {
"dependencies": {
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.1.0"
}
},
"imports": [
"dnxcore50",
"portable-net45+win8"
]
}
}
}
I hope you find this repository useful to see EF Core 1.1 in action.
Oh and as per a tweet by Brad Wilson, I added SDK to my global.json file!
Pro-Tip: Your .NET Core projects should *always* have a global.json file with an SDK version in them.
ALWAYS.
— Brad Wilson (@bradwilson) November 21, 2016
Now I have to go learn about why this is important. Clearly it is!
Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!
The reason you want an SDK version in your global.json is because the SDK dictates behavior that you depend on. For example, preview 2 uses project.json; preview 3 uses MSBuild and .csproj files.
If you don’t specify an SDK version, then the system will use whatever the latest version is that’s installed on the computer. Instead, you’d rather let the developer (or CI system!) know which version of the SDK you built things against, so they can know what to install if/when they don’t have what you need.
I found this great article on how the global.json SDK setting is used.
http://www.hanselman.com/blog/WheresDNVMSafelyRunningMultipleVersionsOfTheNETCoreSDKAndToolingWithGlobaljson.aspx
Microsoft seems to be doing their level best to sew confusion throughout the developer ranks, at least those of us trying to learn .Net Core 1.1 coupled with EF Core 1.1.
For example, you mention “pay attention to the tooling packages”. In the subsequent explanation, I see a bewildering mix of “1.0.0” this and “1.1.0” that which makes zero sense.
To be fair, the Angular folks did the same thing with their 2.x editions, which used a weird 3.x edition of the corresponding Angular router (e.g., “@angular/common”: “~2.4.1” + “@angular/router”: “~3.4.1” in the package.json dependencies section of a typical Angular 2.x application).
The Angular folks have seen the error of their ways and have promised to make Angular 4.x numerically consistent between all the pieces and parts (estimated RTM March 1, 2017).
Here’s hoping that by the time Visual Studio 2017 goes RTM that the “Net Core tooling” for it (and maybe an update to VS 2015?) will clear up the weird mixing of “1.0.0 stuff” with “1.1.0 stuff”.
A similar clarification for the dotnet CLI would be appreciated too, so that when I dotnet new, I get the latest RTM editions of .Net Core.
don’t shoot the messenger! I’d recommend reading this blog post from the dotnet team: https://blogs.msdn.microsoft.com/dotnet/2016/11/16/announcing-net-core-tools-msbuild-alpha/
One thing I did not understand about the article you reference, and thus learned a valuable lesson: If you’re going to use a version of Visual Studio to make the transition from project.json to csproj, it has to be Visual Studio 2017 (RC at the time of this writing), not Visual Studio 2015.
I made the mistake of using the command-line dotnet migrate and then tried to open the solution with Visual Studio 2015 Update 3 and had quite a mess on my hand. That’s when I went back and saw that, although there is plenty of information about making the migration using Visual Studio 2017, the lack of *ANY* mention of being able to do so with Visual Studio 2015 should have been a warning to me. Lesson learned.
P.S. You’ll notice I “shoot the Angular messenger” as well as the “Microsoft messenger” in roughly eager measure in my earlier comment; albeit with a slight nod to the Angular folks who are already working to bring all their “bits” up to the same version numbering (thus skipping over 3.x and going straight to 4.x).