Huge thanks to Dave Rael for having me on the Developer on Fire Podcast! I am honored to have been able to talk with Dave on his show. The Developer on Fire Podcast is really unique because it focuses on the people more than on the technology. There is some tech talk of course but he really tries to get at the stories, the personality, what makes you tick, who you are, what motivates you and how you engage with your work. The show has been around for a long time and he has had some real luminaries among his guests including many of my personal tech heroes. I highly recommend adding this podcast to your listening routine if you haven't already.

developer on fire logo

Historically I've always been a database guy, I never used Entity Framework until I started working with ASP.NET Core and implementing it for my cloudscribe projects. Recently I began getting cloudscribe ready for ASP.NET Core 2.0 and Entity Framework Core 2.0, and in the process I learned that some of my "database guy" assumptions about using Entity Framework were wrong. I also learned about some things that need to be done differently when using Entity Framework Core 2.0 with ASP.NET Core 2.0 vs how things were done in 1.x. In this post I will share what I have learned in hopes it may help others.

Avoid Using Database Default Values

As a "database guy", it seemed natural to me to want to specify default values in the database, but when you do that with Entity Framework there are some important nuances that in general make that a bad idea. In most cases you should instead use default values on the entity like this:

public bool AllowNewRegistration { get; set; } = true;

I was doing that, but as a "database guy", my instinct was to also make that the default in the database by specifying a default value in OnModelCreating of my DbContext like this:

entity.Property(p => p.AllowNewRegistration)

However, after updating to Entity Framework Core 2.0-preview2, I began seeing warnings being logged and warnings when generating a new migration like this:

The 'bool' property 'AllowNewRegistration' on entity type 'SiteSettings' is configured with a database-generated default. This default will always be used when the property has the value 'false', since this is the CLR default for the 'bool' type. Consider using the nullable 'bool?' type instead so that the default will only be used when the property value is 'null'.

This kind of scared me at first because I thought it was a change in behavior from Entity Framework Core 1.x to 2.x, but in fact it turned out the behavior was the same in 1.x, and it is only the warnings that are new in 2.0. It scared me because it sounded like any time my entity value was false, it would use the database default of true, and that is what it does but only on inserts, on updates it respects whatever the property is on the entity. There is a bit of nuance in understanding this warning. For example if you have a bool property on the entity and you use a default value of false in the database you would still get the warning but there isn't really a problem because if the entity value is true at insert time you get the expected result, it will be true in the database after insert. The trouble comes when you specify a default value of true in the database, since the CLR type bool has a default value of false, if the entity has false for that property at insert time it will get the database default of true rather than the value that was set on the entity. This may or may not be a real problem in the application depending on whether that property is surfaced in the UI for creating the entity. If the property is only editable for updating the entity and not for creating the entity, then you still get the expected results. But if it is a property that you surface in the UI in order to allow it to be specified at creation time, then you will get the unexpected result if it is set to false, then the database default will be applied.

So, a rule of thumb should be do not specify default values in the database. As an aside I would also say that in general you do not need to specify the ColumnType as I did above, though it causes no problems or warnings, you can generally trust the Entity Framework provider to decide the right data type for the database.

Exceptions to this rule do exist

Ok, so should we never specify a default value? Never say never. Given what we now understand about how default values are used on inserts, we need to consider how to handle it when we add a new bool property to the entity with a default value of true on the entity itself, what will happen to existing rows when the migration is applied and no default value is specified in the db. It turns out the existing rows will not get the entity default of true but will instead get the CLR default of false. This is not what we want.

In this case the solution is to go ahead and specify a default value of true in the database, generate a new migration, then remove the default value and generate another migration. This way the existing rows will get true from the first migration which is what we want, then the second migration will remove the database default value so that we get expected results on new inserts.

Do Specify MaxLength Where Appropriate

This I learned when I first began using Entity Framework Core, not as part of updating from 1.x to 2.x, but it is worth mentioning for anyone new to using Entity Framework. When you have string properties on your entity, if you don't specify a MaxLength then NVarChar(max) will be used in SqlServer or text in other database platforms, so unless you need that much space for the value you should always specify a MaxLength. Note that nvarchar(max) won't use more space than needed but it is still a good idea to limit the size to what you really need, and probably even more important when using other providers than SqlServer.

Other Changes From Entity Framework Core 1.x to 2.x

There are a few other things I ran into when updating cloudscribe to Entity Framework Core 2. These are things that may or may not impact upgrading your own application depending on whether you did any of the same things I did when using 1.x.

I was using some of the provider specific annotations like this:

 modelBuilder.Entity<SiteSettings>(entity =>

    entity.HasKey(p => p.Id);

    entity.Property(p => p.Id)


Those extensions went away in 2.0 so now we just use the non-provider-specific ones like this:

modelBuilder.Entity<SiteSettings>(entity =>

    entity.HasKey(p => p.Id);

    entity.Property(p => p.Id)


Hopefully you were not using the provider specific ones and won't run into that problem yourself. For 2.0-preview2 I had to manually edit my existing migration code to make it more consistent with how they would have been generated using the more generic annotations. I have heard that in 2.0 RTM they will handle some of that automatically but you would still have to make changes for the methods which no longer exist.

I was also wiring up the dependency injection like this in 1.x, though I am not sure it was required to do it this way so it may not impact you. I based my code on examples I found which may date back to the beta  or RC days, but in any case this was working for me in 1.x and caused a problem in 2.x:

    .AddDbContext<CoreDbContext>((serviceProvider, options) =>

I ran into a problem where an error was thrown when trying to execute the migrations, I was getting the error:

AggregateException: One or more errors occurred. (Cannot consume scoped service 'Microsoft.EntityFrameworkCore.Infrastructure.ModelCustomizerDependencies' from singleton 'Microsoft.EntityFrameworkCore.Infrastructure.IModelCustomizer'.)

There were a few things I changed which made this error go away, first I changed the above code like this:

    .AddDbContext<CoreDbContext>(options =>

getting rid of the UseInternalServiceProvider. Possibly that solved it but I also did another thing which could have been a factor in the fix. Based on observations in other projects using 2.0, I noticed that DbContext should apparently now have a protected constructor that has no parameters, whereas mine only had the constructor that takes a DbContextOptions parameter, so I added an additional constructor like this:

protected CoreDbContext() { }

whereas previously I only had this one:

public CoreDbContext(DbContextOptions<CoreDbContext> options) : base(options) {}

After doing those things that error went away and things were working fine.

However from following some github issues, I learned another thing that is recommended for 2.0 is not to trigger migrations/seeding from the Configure method of Startup.cs which is how it was generally done in 1.x. I had code like this in my Configure Method:


The above code worked still in 2.x for my scenario, but the new guidance is to move that stuff into Program.cs, so I removed those lines and now my 2.0 Program.cs is like this:

public class Program
	public static void Main(string[] args)
		var host = BuildWebHost(args);
		using (var scope = host.Services.CreateScope())
			var services = scope.ServiceProvider;


			catch (Exception ex)
				var logger = services.GetRequiredService<ILogger<Program>>();
				logger.LogError(ex, "An error occurred while migrating the database.");


	public static IWebHost BuildWebHost(string[] args) =>

	private static void EnsureDataStorageIsReady(IServiceProvider services)


In summary, a few things have changed in Entity Framework Core 2.x that may or may not impact your applications, but I thought I should make note of the issues I encountered in case some of you encounter the same issues.

Last year was my first foray into making my own pickles. I had some great success and I also made some mistakes that I learned from. The good batches of pickles I made were so good that when I shared them with friends at a party I got a message the next day asking if it were possible to get some more, would I consider selling some? But I also messed up some batches and had to throw them away. Here I will provide the steps and variations I use, as well as some cautions so you don't make the same mistakes I made. Even though there are lots of details to think about, making pickles is very easy and doesn't take much time at all if you have the jars and spices on hand. You can use the same recipe and guidance here with carrots as well, just make them the same way substituting carrots for cucumbers, they come out awesome!

Start with the right cucumber varieties

There are special cucumbers for pickling, don't just use regular cucumbers. Use Kirby, or Sumter, or others that are intended for pickling. You could buy them for making an occasional batch, but you should grow them yourself, they are easy to grow. Also plant some dill weed even before the cucumber planting if possible so it will be ready around the time when the cucumbers start rolling in. Also plant some rosemary in your garden and get it established, it will grow into perennial bushes and shrubs in moderate climates and then you can snip sprigs from it which make very interesting and unique pickles unlike anything you will find in the stores. The rosemary pickles I made last year were the ones people really liked the most. Dill weed is not perennial and has to be planted every year. Last year I did not have any dill planted but I did make some dill pickles using sprigs of dill purchased from the local grocery store. This year I have dill growing and ready. Cucumbers grow very fast and once they start rolling in you will be making pickles every other day or so for a while. You can refrigerate them for a few days if needed but don't wait too long, they are better the fresher they are when you make them.

About the jars

Canning jars are easy to come by, get them at a local store or order from amazon. They need to be sterile. You can boil the jars but that is a pain, if you have a good dishwasher run them through twice set on heavy load and high temperature wash. This is especially important if the jars have been used before. One of the mistakes I made last year was re-using the jars after the first batches and I did not get them sterile enough so some went bad and had to be thrown out. I boiled them after that but it was getting towards the end of the season at that point. This year I'm using the dishwasher high temperature wash and they seem to come out sterile, we shall see. I use one quart and two quart jars, I also use some glass fermenting weights or pickle pebbles that I put on top to help keep them below the surface of the water. You can get those also at amazon, they are kind of expensive considering what they are. You can also get by without them if you pack the cucumbers well enough that they aren't trying to float to the top. You can re-use the ring parts of the lids but never re-use the flat parts. You can buy extra lids fairly cheap on amazon.

Make the brine

Use 2 - 3 tablespoons of sea salt per quart of filtered water. I put this in a large sterile bowl and stir it to dissolve the salt. It has to be sea salt, don't use iodized salt. One of the mistakes I made last year was trying to reduce the salt in some batches but that is a bad idea. The salt is very important in creating the right conditions to allow the good bacteria to thrive and to prevent the unwanted kind. When I used too little I ended up having to throw out some bad jars and hang my head in disappointment as my pickle supply dwindled.

The basic recipe

  1. on a sterile cutting board cut the cucumbers into wedges and put them in the jars.
  2. add spices
  3. fill with brine
  4. optionally top with fermenting weights or pickle pebbles
  5. seal the jars tightly with new lids
  6. store the jars at room temperature in some kind of tray or container, as gasses build up sometimes the jars may ooze out some liquid. If that happens what I do is carefully and slowly open the lid to gradually let off pressure then reseal. Best not to store them in direct light

I store them for 7 days at room temperature and that is usually enough. I put them in the fridge at least one night before eating them. They will continue to ferment in the fridge but much slower than at room temperature. You can keep them at room temperature longer or much longer if needed or if you don't have space in the fridge.

Spices - get creative

The fun part of making pickles is using different spices. Try different things, be creative, and give them your own personal touch. Not every experiment will turn out to be great but many will, and it is fun to experiment. Dill is the traditional spice of choice for good reason, but other things like Rosemary make very interesting flavored pickles unlike anything you will find in stores. In fact finding real fermented pickles in stores is not likely, they are typically made with vinegar and may be pasteurized. There are probably regulations that make it difficult for the food industry to provide real fermented craft pickles. The ones you make yourself will be better than any you find in the stores.

The spices I have been playing with are:

  • Sprigs of fresh dill, growing my own this year
  • Sprigs of fresh rosemary, I have lots of this growing in my yard, also good for aroma therapy, just rub your fingers through it and smell your hands
  • Chopped garlic - I chop it but I don't mince it really small, I use kind of a lot because I like garlicky pickles
  • Peppercorns - I put a tablespoon or more in the large jars and a tablespoon or less in the small jars
  • mustard seed - a teaspoon or tablespoon per jar
  • corriander seed - a teaspoon or tablespoon per jar
  • cumin seed - this I only add in some jars, I like it but not as much as some of the other combinations

I have made batches with all of the above together but you don't need all of that every time. I always use the garlic, always use dill or rosemary or both, always use peppercorns, often use coriander, occasionally use cumin. I use quite a bit, you can probably get by with less, but try different proportions. I buy the peppercorns, and other seed spices in bulk from amazon, so much less expensive than buying little jars at the grocery store, and having more on hand allows me to add them more generously than I might otherwise.

It may sound like a lot of steps, but it really doesn't take long. As the cucumbers start rolling in fast I make batches every few days and it takes me only about 15 - 20 minutes including the time to pick them and rinse them. Fermented foods are very good for you and very delicious. I can't wait till my first batch of the year is ready to eat, which will be next week.

There are lots of good little books about fermenting if you want to learn more.

Enjoy, and don't forget to share them with your friends!