Julia Lerman's Blog, page 9

Pluralsight Getting Started with Entity Framework 6 : FREE ALL WEEK

One of my Pluralsight courses, Getting Started with Entity Framework 6,  is free for non-subscribers through July 27. Go watch it while you can! You don’t have to give a credit card, just your email address.

Video of My .NET on a Mac Demo at DotNetFringe

Last week at the awesome DotNetFringe conference in Portland, Oregon, I did a 30 minute demo of building an ASP.NET Web API with Entity Framework using Visual Studio Code on my lovely MacBookPro. So it’s .NET on a mac (coding, debugging and running). It is *that* cross platform.

I also talked about some of the features of ASPNetCore and EFCore. I used other cross platform stuff like JetBrains’ DataGrip IDE for interacting with numerous databases on numerous platforms, PostgreSQL database, xunit for testing and more!

It was a boatload of fun and it’s on YouTube:

The solution I showed in the demo is in my github repository: julielerman/EFCore-ASPNetCore-WebAPI-RTM

Designer Support for EF Core via DevArt

Although Microsoft has dropped support for EDMX as it moves to the next generation of Entity Framework, 3rd party providers have promised to continue supporting designer based tooling for EF Core. Since the EF team announced that it wouldn’t support EDMX going forward, I have asked the providers directly and shared their response that yes, they were planning to support EF Core. And I’ve been trying to calm the many developers who currently depend on EDMX and/or the designer and really want to use EF Core rather than sticking with EF6 and the existing tooling.

The two providers that have long had their own designer support for Entity Framework are LLBLGen and DevArt.

DevArt just announced the release of Entity Developer 6.0 which does indeed support EF Core. Within minutes of reading their tweet announcing this, I took it for a spin. Even though I’m mostly using Code First exclusively these days, I know a LOT of developers who have huge investments in EDMX and would love to use EF Core. So definitely wanted to see how this works.

I grabbed the Entity Developer 6.0 Professional Trial (the trial is free, a real license is not). Although Entity Developer has been around for years and I do have clients that use it for working with Oracle, this is the first time I’ve ever tried it out myself.

You do not need a designer to reverse engineer from the database! EF Core can reverse engineer from an existing database into POCOs and a DbContext. (Check out the scaffold feature in my MSDN Magazine article on EF Core Migrations.) The value of this designer with respect to EF Core is a) if you have an existing EDMX and want to continue using it or b) you want to do designer based modeling for EF Core.

Highlights:

The most important part of the process is that this designer generates the DbContext class using the mapping and connection details needed by Code First and does so using EF Core APIs and namespaces.
You can import an existing EDMX into their designer.
You can create a new model via Database First or Model First in their designer.
There is a special template for EF Core to generate DbContext and POCO classes from the model.
You then use those classes in your application where EF Core as though you were using Code First.
You can continue using the designer paradigm just as you’ve been able to do with EDMX. That means you can modify the database and update the model based on those changes, then regenerate your classes. You can tweak the model visually in the designer and regenerate the classes. You would not use Code First Migrations in this case.
If you want, you could drop the designer after the first code generation and continue with code first and migrations. In that case, unless you really want to use the designer for this first iteration, you could use a straight database to code first workflow which is provided by EF Core migrations “scaffold” command or keep an eye on ReversePoco.com for it’s EFCore support.

Screenshots of creating a new model from an existing (very simple) database.

Create a new model, selecting EF Core as the model type.

Tell it that I want to use an existing database.

Choose a database provider (I picked SqlServer)

Select objects. I didn’t have a lot in my tiny demo database. You can see I chose a database that I had created earlier via code first…that’s why there’s a MigrationHistory table there.

Set up naming rules  Entity Developer has always had this. I just left it at defaults.

Define Model Properties. Notice some EF Core specifics on this page. Many to Many and Table Per Type support are disabled because they are not [currently] supported in EF Core. Also shadow properties is a new feature in EF Core and there is an option related to that.

Select a template  EF Core is there by default but you can create and save custom templates.

 

After this, the model gets generated and displayed in the designer where you can have your way with it.

 

Generate the code. This is an menu option under “Model” (or just press F7). This is the part I was sorely interested in of course.

When generation is complete, you get a message. It has created a DbContext class and one POCO class for each of my entities.

Then I created a new solution in Visual Studio a Domain Classes project and a Data Model project and copied the new classes into the relevant projects. Until I installed EF Core, there were loads of build errors.

Install EF Core into the DataModel project. It’s been a while since I used Powershell to do this so I forgot to add “ –pre” to the command. I’m sharing that because I’m sure others will make the same mistake! So don’t feel bad. I do it too!

The POCO classes are not very interesting. They’re just POCOs. The context class however, is where you can see that it’s using EFCore. I’ll share the key parts of that class.

EF Core namespaces:

using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata;

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, "Courier New", courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

EF Core OnConfiguring along with the EF Core DbContextOptionsBuilder and the UseSqlServer extension method.

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
optionsBuilder.UseSqlServer(@"Data Source=(localdb)\mssqllocaldb;Initial Catalog=NinjaDomain.DataModel.NinjaContext;Integrated Security=True;Persist Security Info=True;User ID=;Password=");
CustomizeConfiguration(ref optionsBuilder);
base.OnConfiguring(optionsBuilder);
}

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, "Courier New", courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

Comprehends the new relationship mapping methods in EF Core:

#region Ninja Navigation properties

modelBuilder.Entity().HasMany(x => x.NinjaEquipments).WithOne(op => op.Ninja).OnDelete(DeleteBehavior.Cascade).IsRequired(true).HasForeignKey(@"NinjaId");
modelBuilder.Entity().HasOne(x => x.Clan).WithMany(op => op.Ninjas).OnDelete(DeleteBehavior.Cascade).IsRequired(true).HasForeignKey(@"ClanId");

Enough for me for now

That’s all I did for the time being. I wanted to see the basic workflow. The big difference between EF6 (and earlier) and EF Core with respect to this is that at runtime,  EF6 (etc) would read the XML files that represented the EDMX and figure out the model from that. Even though the EF Designer generates code, that code is only for the sake of your own business logic. At runtime, if EF sees you are using an EDMX to describe your model, it relied on the XML files to learn about mappings to comprehend the model. EF Core *only* knows how to read the DbContext & classes, so it was key for the code generation to build those classes with all of the mapping details (and expressed via the EF Core APIs) that Code First needs to comprehend the model at runtime. That’s what the Entity Developer designer is doing for you. And as you can see from the screenshots, there was more to creating this support than simply modifying the T4 templates.

Updating to RC2: Changes to EFCore, ASPNETCore, PostgreSQL driver & XUnit

The long-awaited 2nd release candidate came out earlier this week (here is the team’s announcement: Announcing ASP.NET Core RC2).

I have been sticking with RC1 and avoiding mucking with the nightly builds as Microsoft evolved this stack towards RC2 because so much was changing. Others were braver such as Shawn Wildermuth, the beardy Shane Boyer and the sad people who have been building products and tools dependent on ASPNET Core.

So as soon as the new bits were released I sat down to finally update the sample application I’ve been using at conferences since March that were still on RC1. Although it’s all cross-platform, I’ve been working on this sample on my MacBook directly in OSX and using only the CoreCLR just to prove to myself that this stuff is truly cross-platform. I’ve even set Mono aside.

I had two tiers of problems to attack: first getting the new CoreCLR (and the CLI that gives us dotnet commands, replacing dnx, dnvm and dnu) onto my Macbook, second was updating my sample which was dependent on a variety of technologies and APIs.

I’ve pushed the updated version of the application to github and renamed it: https://github.com/julielerman/EFCore.... But I want to share some of the things I did to get this all working. Shawn wrote a great post on updating his app and the aspnet documentation has a doc on updating from RC1 to RC2 as well. I would start with these. I will focus on some of the changes I had to make that either aren’t covered in those posts, aren’t as obvious or just gave me extra heartache.

I would definitely recommend looking at my repository though since it does have working code so if you’re stuck on something and it happens to be something I already did, you might find an example to borrow within my app.

Getting the RC2 CLI onto My MacBook

For most, it should be easy. Just follow the instructions on Microsoft’s .NET Core page (there are different pages for different platforms).

It seemed to work. But I quickly ran into some problems when I was tryingi to convert my code and those led me to a few threads that said I may not have the correct version. There is some question about how much needs to be removed from your system so that you don’t have leftover older bits of CoreCLR hanging around causing conflicts. In fact, a key element of the update is to run an uninstall script (on the instruction page linked to above). There was a pull request to update that script to do a better job of cleaning the old version out before installing the new version. (Since then that PR has been modified and merged and is now what you will get from the instruction page.)

I grabbed the existing pull request version of the script and ran it then re-ran the installer. So began a bunch of lost and frustrating hours because suddently the dotnet command was gone. I kept getting “dotnet command not found” errors. (See next section about that). Keep in mind that I’m still fairly new to OSX so some of my lost time was due to things like being told to go to the “usr” path and my windows brain translating that to users/julielerman. I made the mistake of going to the latter. That wasted a lot of time. But I eventually got it sorted out.

Because I did not have a straight path to success, it is difficult to say what exactly was wrong and what was right. Hopefully the new uninstall script will do the trick. If not I suggest looking at ideas in this thread: dotnet command can’t be found on osx with RC2 bits

Dotnet command not found on OSX?

There are two important takeaways in solving the problem of dotnet not showing up on OSX.

1) For those using zsh as the default commandline instead of bash:

“There is an issue in the way path_helper is working with zsh on OSX. The easiest way for you to get unblocked is to simply symlink the dotnet binary to /usr/local/bin using the following:

ln -s /usr/local/share/dotnet/dotnet /usr/local/bin

This may eventually not be necessary. See this issue for a conversation about making the uninstaller smarter on zsh.

2) Problem with dotnet command on bash

Another user had the same problem but on bash so the symlink was not the answer. Eventually he discovered that some app had installed the following into his ~.bash_profile file:

export PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Applications/GitHub.app/Contents/Resources/git/bin...

He removed it completely and got success although Zlatko K (from the cli team) made this suggestion:

You can actually keep that and just have the following:

export PATH=$PATH:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Applications/GitHub.app/Contents/Resources/git/bin...

I don’t know who did that to your .bash_profile but that is the reason why it is happening. And yes, they should not be doing this. They should be adding your path as well.

Updating Visual Studio Code and (yippee) Debugging!

Since I’m doing this on a mac, I don’t have all the benefits of Visual Studio, but Visual Studio Code is pretty awesome. And with it’s limitations, it really forces me to learn my lessons more deeply & memorably, whereas with VS, I can get away with more thanks to all of the extra support. If I was on my regular computers (read: Windows) I would absolutely be using VS, not VSCode). So doing all of this on the Mac gives me some advantages in having to comprehend everythnig I do more clearly. And, it’s fun using the Mac after only using Windows for so long. But I’m not trying to tell anyone they should do all of their .NET coding on a Mac.

So with that out of the way …

A quote about isolated data stores from Eric Evans

I need to keep this quote around so where better than my blog?

“For as long as I can remember, I’ve been advocating that a team that’s developing some complex piece of logic should have their own isolated data store and not have to share some huge database that has some kind of mishmash of different people’s ideas of what the data should be and so forth.”

(Eric Evans, “DDD & Microservices: At Last, Some Boundaries!” GOTO Berlin Dec 2015 (gotober.com) https://www.youtube.com/watch?v=yPvef9R3k-M)

This is such a difficult thing for so many developers to buy into. I frequently share a story about Eric trying to ease me out of a near mental meltdown, explaining to me when I was struggling with this (& I am paraphrasing and possibly adding some of my own comprehension at this point) that you have to pay the price somewhere and often its just less painful to solve the problem of having data in different places that needs to connect once in a while than it is to deal with the complexity of a system that tries to provide all answers to all of the problems. We have patterns to solve the “connect the data once in a while” problem (e.g. message queues).

I admit that I have to advise people to aim for this but it’s often not practical (or cost-effective) so if we’re talking about relational databases then we can at least isolate with schemas. But I do try to start with “separate database” and work our way backwards from there if it’s just not doable (or if the person or team I’m talking to looks like they are about to murder me). However each step backwards comes with a price. You just have to choose – pick your poison. As long as you are doing so with the right information at hand to make those decisions & choices, I think that’s the most important part.

ICYMI, My General Advice re DDD, EF & Domain Models with or without Data Models

I wrote this in a Github issue thread about EFCore & lack of current support for complex types (which support DDD Value Objects .. to a degree) this morning and someone said I should share it so here it is:

I love value objects. I’m just not considering efcore for any serious work yet so I am not going to stress out about not using them. I find myself designing my domain with them out of habit then having to undo. And if you are set on efcore, then +++ to @jnm2 ‘s point. I map from domain to EF’s data model (the in-memory model that EF infers at runtime) using EF’s mapping when it’s easy and I don’t have to make annoying (or worse) concessions. Otherwise it is time for a mapper between domain and data model defined by separate classes + EF DBContext. So EF mapping layer is my default mapper when using EF. But sometimes it is just not sufficient and I go to (or recommend) the effort of building a separate data model. Your choice. Pick your battles.

Another point is that Jimmy Bogard doesn’t even think the ef6 complex types do enough to map types that you’ve defined as value objects. So he’s been either just using one to one or going the extra mapper route depending on the situation. Gogglebing Jimmy Bogard, something like “what’s missing in ef6 for DDD” to read more. And then there’s that collection conundrum, too as well as the problem of mapping private fields. So if you are okay without those in EF6, maybe support for value objects isn’t such a huge deal except for the problem of it being “taken away” temporarily.

My ref to Jimmy Bogard was for his Domain modeling with Entity Framework scorecard post.

I’m sharing because of the following reply from Joseph Musser on this thread:

I would love to have had (and still would love) an article that thoroughly addresses that question: weighing the pros and cons of staying within EF modeling constraints or using a data model and mapping yourself. When to consider making the switch. And what that means for creating a rich, disciplined model that doesn’t become anemic. I feel like I’ve wasted a lot of time not having a fundamental understanding of this from the beginning.

Specifying Global TypeScript server path in Visual Studio Code in OSX

Since I’m really new to working on a mac, the instructions on the VSCode blog post (http://blogs.msdn.com/b/user_ed/archive/2016/02/09/visual-studio-code-new-features-javascript-salsa-preview.aspx) for enabling Salsa for TypeScript in VSCode was just not enough for me. This is the instruction:

You then have to tell VS Code the install location using the typescript.tsdk setting. Set typescript.tsdk to the path of thelib folder containing the tsserver.js file of the installed TypeScript module.

I had done a global install. And since hidden files and the usr/ folder are also a mystery to me, it took me a while to figure out that this is how to specify that in the settings.json file in VSCode.

“typescript.tsdk”: “usr/local/lib/node_modules/typescript/bin/tsserver”

I hope someone can save some time by finding this blog post.

OSX, ASPNetCore, EFCore and CoreCLI, oh my!

After moving some RC1 test projects from windows over to my MacBook, it was time to start from scratch in OS X to see what that experience was like. Installing all the right pieces. I’d been using Visual Studio Code already on windows for nodes programming, but doing that for an ASP.NET 5 project is a little harder since the debugging for that isn’t implemented yet. At the same time I’m still getting used to navigating my way around a Mac … keystrokes, bash commands etc.

But I did get a small sample worked out and even used PostgreSQL to do the job.

That (remember, RC1) little test is on github here: github.com/julielerman/ef7osxtest.

But RC2 is a different beast!

Addendum because so many have asked: I am using the nightly builds of RC2. It is not out yet!

DNX is transitioning to CoreCLI with new underlying APIs. And there was that name change. ASPNET 5 became ASP.NET Core and EF7 became EF Core. The package and namespaces have changed.

And in the meantime, EF7/EFCore is still going through changes with RC2. To me the most significant is the work the team has been doing to help with disconnected graphs. You can read the latest (and I think final) state of how EF will handle disconnected graphs here on github.

I tried a few paths to starting a new project to try out RC2. Here’s some twitter evidence:

This has been my work environment for the past 10 hours. I even ate breakfast and lunch here. pic.twitter.com/EL78TyNcgQ

— Julie Lerman (@julielerman) January 31, 2016

I had watched the video of David Fowler & Damien Edward’s talk about Core CLI from NDC London and David did the demos on a mac.

My talk with @davidfowl on the change from DNX to .NET Core CLI for #aspnetcore is now live https://t.co/Uc9x5qLVJR — Damian Edwards (@DamianEdwards) January 28, 2016

But it took a tweet from Tony Sneed to remind me that I could get David’s demos from github:

@julielerman Ton of churn for RC2: rename, new hosting bits, DotNetCli, etc @davidfowl’s sample is a good reference https://t.co/ekTWX8Eked — Tony Sneed (@tonysneed) January 31, 2016

Indeed, that was the best starting point. I cloned that repository onto my MacBook and made sure I could run all three projects.

Now I’m working on building out the HelloMVC project by adding in the model, dbcontext, controllers and other relevant bits from my RC1.

At the moment (as of Feb 1 2016), the dotnet ef migrations commands aren’t working but Brice Lambson is working hard on it and says that should be pushed up this week. (Watch this github issue.)

And it might be a while before the Postgres provider gets updated to work with the new namespaces and package dependencies  but we do have the Microsoft.EntityFrameworkCore.Sqlite provider that will work on OS X although there seem to be a lot of problems at the moment with that on Linux. But I’ll be trying that out anyway.

Travel & Conference Schedule Feb – May

I didn’t travel much last year so am making up for it this spring and summer. Here is where I will be and what I’ll be talking about in the near future.

Feb 15
Vermont.NET User Group/VTCoders
(My home base!)
Aurelia & Node.js: Fitting the pieces together
Burlington, VT


Feb 18
DotNetMiami
7 Reasons to Use EF7, 6 Reasons to Stay with EF6
Miami, FL area


Feb 20
South Florida Code Camp
7 Reasons to Use EF7, 6 Reasons to Stay with EF6

Aurelia & Node.js: Fitting the pieces together
Ft. Lauderdale, FL


Mar 10
WROC#
Entity Framework on OSX:
  Microsoft Data Access Gone Wild!
Wroclaw, Poland


Mar 28-31
QConSP
Entity Framework on OSX:
   Microsoft Data Access Gone Wild!
[Workshop] Thinking in DDD:
  Improve your software without being a guru
Sao Paulo, Brazil


April 6-8
AATC2016
(Agile Alliance Tech Conf)
Introducing Your Team to Modern Software Practices
Raleigh, NC


May 3-4
Techorama
EF on OSX: Microsoft Data Access Gone Wild!
Introducing Your Team to Modern Software Practices
Mechelen, Belgium


July 4-6
DevTeach
Aurelia & Node.js: Fitting the pieces together
(aka JavaScript Noob’s Look at an Aurelia Front End, Node Back End Web Site)

Entity Framework on OSX:
    Microsoft Data Access Gone Wild!
Montreal, Quebec

This is why Steve Smith and I created Domain-Driven Design Fundamentals Course

@julielerman @ardalis I totally agree. It changed so much about how I think about architecting my apps. I may re-watch for a refresher!

— Andrew Bancroft (@andrewcbancroft) January 27, 2016