![](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2018\/02\/word-image-35.png\")
<\/p>\n
Overview of the process<\/h2>\n
It ended up taking just over 2 days and looked like this:<\/p>\n
![](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2018\/02\/word-image-36.png\")
<\/p>\n
>80% of the effort was spent reading blogs, trial & error, making mistakes, and drinking more coffee than I\u2019m proud of. Doing this again would take at most a quarter of the time \u2013 if anyone on your team has done this already I strongly recommend you buddy up! The general approach I ended up taking was:<\/p>\n
- \n
Break everything, Google solutions for every problem in turn until stuff worked again.<\/s><\/li>\n- For all but the web project, upgrade the csproj files<\/a> to the new (much simpler) VS15 format, but still building for .NET 4.5.2. I chose to do this manually rather than creating new projects from scratch.<\/li>\n
- Unload all projects in the solution apart from the DataPersistence library, which was at the bottom of the pyramid. Make that build for .NET Core instead.<\/li>\n
- Update all the packages in the DataPersistence library to the latest versions which supported .NET Core, or for some cases like Entity Framework, replace the packages entirely with their .NET Core equivalents (Entity Framework Core in this case).<\/li>\n
- Go through all build failures and patch up api changes until the project compiles.<\/li>\n
- Repeat steps 2-4 but adding additional projects back into the solution one-at-a-time.<\/li>\n
- For the web project there\u2019s so much plumbing to get everything to work that I just created a new empty project and manually copied over the Controllers, Models, Views, javascript and css, with just a few adjustments. Doing that rather than trying to upgrade the project in-place was definitely the right decision.<\/li>\n
- Run the tests. Weep at the multitude of ways that \u201cbuilding just the same as before\u201d does not mean \u201cdoing what it did before\u201d.<\/li>\n
- Fix up the issues from step 7, ranging from one-liners through to pretty invasive changes which touch dozens of files.<\/li>\n
- Test manually.<\/li>\n<\/ol>\n
Gotchas<\/h2>\n
Plenty of things went wrong. Most of these focus on issues I encountered during steps 7 and 8.<\/p>\n
Incompatible libraries <\/strong><\/p>\n
ImporterCore depended on a library<\/a> I originally wrote a couple of years ago, which didn\u2019t yet support .NET Core. It uses WebClient, which didn\u2019t exist in .NET Core 1.0 \/ 1.1, so getting this working would previously have been painful. Fortunately, WebClient was added into .NET Core 2.0, making the upgrade simple \u2013 just some changes to the csproj, AssemblyInfo, and nuspec files<\/a>. But if you depend on any incompatible libraries which you don\u2019t control, you could be blocked.<\/p>\n
Entity Framework <\/strong><\/p>\n
This is what took most of the effort. Entity Framework 6.2 isn\u2019t available for .NET Core, and its replacement EF Core has significant changes, which makes it more like a port than an upgrade. (Here is a feature list comparison<\/a>) First though, a happy point:<\/p>\n
Mapping conventions<\/strong><\/p>\n
Overall I\u2019ve grown to like EF Core more than EF 6.2. The main reason is an emphasis on configuration by convention. Here\u2019s a mapping file for an original Survey<\/em> object. It tells Entity Framework the names of columns for each property, the table name, and which item is the key (plus more in most cases).<\/p>\n
public class SurveyMap : EntityTypeConfiguration<Survey>\r\n {\r\n public SurveyMap()\r\n {\r\n \/\/ Primary Key\r\n this.HasKey(t => t.Id);\r\n \/\/ Table & Column Mappings\r\n this.ToTable(\"Surveys\");\r\n this.Property(t => t.Id).HasColumnName(\"Id\");\r\n this.Property(t => t.Title).HasColumnName(\"Title\");\r\n this.Property(t => t.Nickname).HasColumnName(\"Nickname\");\r\n this.Property(t => t.Category).HasColumnName(\"Category\");\r\n this.Property(t => t.Language).HasColumnName(\"Language\");\r\n this.Property(t => t.IsOwner).HasColumnName(\"IsOwner\");\r\n \/\/And a dozen or so more properties\r\n }\r\n }<\/pre>\nIn EF Core, by convention a property is assumed to map to a column of that name unless you tell it otherwise, just as the overall object is assumed to map to a table of the same name. It\u2019s also assumed that if there\u2019s a property called Id<\/em> or SurveyId<\/em>, then that is the Primary Key unless you tell it otherwise. So I got to delete nearly a thousand lines of unnecessary boilerplate, which is pretty cool.<\/p>\n
Most of the remaining mapping can be done through annotations (for example to tell Entity Framework about values which are generated by SQL Server<\/a>), though a few things like composite keys<\/a> can only be configured using the fluent api, which is done in the context\u2019s OnModelCreating(ModelBuilder modelBuilder)<\/em> method.<\/p>\n
Api changes<\/strong><\/p>\n
There are a handful of api changes \u2013 for example foreign keys used to be configured with something like:<\/p>\n
modelBuilder.Entity<ResponseQuestion>()\r\n .HasRequired(parent => parent.ResponsePage)\r\n .WithMany(child => child.ResponseQuestions)\r\n .HasForeignKey(prop => new\r\n {\r\n prop.ResponsePageId,\r\n prop.ResponseId\r\n }\r\n );<\/pre>\nIn EF Core, HasRequired()<\/em> was changed to HasOne()<\/em>. The tests also used context.Database.Create()<\/em> and context.Database.Delete()<\/em>, which in EF Core were changed to context.Database.EnsureCreated()<\/em> and context.Database.EnsureDeleted()<\/em>, but these were pretty minor.<\/p>\n
Interception<\/strong><\/p>\n
Slightly more effort was getting some custom handling of DateTime<\/em> values working nicely. The application always stores DateTimes<\/em> as Utc in the database, but when reading from the database Entity Framework doesn\u2019t know this, so treats them as DateTimeKind.Unspecified<\/em>, which would lead to some incorrect behaviour elsewhere in the app. In the original version of the application, I worked around that with a variation of this technique<\/a> \u2013 essentially using the Interception capabilities in Entity Framework to patch up the DateTime<\/em> object\u2019s DateTimeKind<\/em> property. Unfortunately, this kind of Interception isn\u2019t yet possible in EF Core, so instead I used an EntityMaterializerSource\u00a0with some adaptations to let it handle nullable columns. Conveniently the old version of the application had tests in place to cover this conversion in a variety of scenarios (in particular because projection queries behave differently to entity queries) so it was easy to be sure it was working as expected.<\/p>\n
As an aside, it drive me crazy that neither version of Entity Framework handles this well out of the box \u2013 I can\u2019t remember the last time I stored date information in a database without wanting to consider it as UTC.<\/p>\n
Lazy Loading<\/h2>\n
This was the biggest time suck: EF Core doesn\u2019t support lazy loading. It\u2019s coming in EF Core 2.1, due Q1 \/ Q2 2018, but that\u2019s no help today. I\u2019ve written a fair bit about Entity Framework performance<\/a>, and the original choice to use lazy loading was for good reasons. There\u2019s no indication anything\u2019s going wrong when building the app \u2013 it\u2019s just that when accessing an entity\u2019s child property which you expect to be lazily loaded, you get an empty list instead. Fortunately there were quite a few end to end tests using a live database which failed all over the place, but I could imagine this not being noticed in a situation where an app only very occasionally uses lazy loading (possibly without the developer even knowing), where there weren\u2019t tests in place.<\/p>\n
The solution of using eager loading instead wasn\u2019t the end of the world, but it did result in a lot of extra testing, generally messier code with deeply nested Include()<\/em> and ThenInclude()<\/em> statements all over the place, and is slightly less performant overall. I\u2019ll probably undo these changes in a few months once upgrading to v2.1 is possible.<\/p>\n
Configuration<\/h2>\n
While .NET Framework configuration is typically stored as xml in app.config \/ web.config files, .NET Core uses appsettings.json to store configuration data. I actually like this change a lot, but it did require some changes.<\/p>\n
Hosting in IIS<\/p>\n
The original Explorer website was hosted under IIS, and I didn\u2019t realise that IIS doesn\u2019t know how to serve ASP.NET Core websites out of the box. ASP.NET Core uses the Kestrel server, which runs as a separate process to IIS. You need to install the .NET Core Windows Server Hosting Bundle<\/a> which lets IIS handle things like security and some management tasks while handing off to Kestrel to actually run the code. The application pool needs to be configured to run No Managed Code too, since that\u2019s handled by Kestrel.<\/p>\n
Unfortunately I discovered this the hard way by deploying it to production and wondering why it didn\u2019t work. Nor did I have access to install components on the server, so there was a little downtime while I waited for a friendly sysadmin to help out. Oops.<\/p>\n
Verdict<\/h2>\n
- For all but the web project, upgrade the csproj files<\/a> to the new (much simpler) VS15 format, but still building for .NET 4.5.2. I chose to do this manually rather than creating new projects from scratch.<\/li>\n