Robert Jørgensgaard Engdahl

I'd like to confirm this issue. Replacing some of the Include()s with separate loads and then invoking ChangeTracker.DetectChanges() seem to be a doable work-around. Invocation time went from 1.6s to...

Brilliant We experience even worse test times. Perhaps we also have some entities inherit each other. For comparison it takes about six seconds to spin up a localDb, which then...

It just might. As I recall it, the problem had to do with reflection generated lambdas that became subject to a lot more run-time security checking after a new .Net...

You could make this work though. You just need to trick the compiler into preferring the FormattableString overload. I've explained it in details here: http://blog.engdahls.dk/2016/08/how-to-overload-string-and.html

The resolution of an overload should be done at compile time. The conversion, however, will be done on-the-fly, so for normal strings we add the overhead of making an intermediate...

This is not backwards-compatible... you will break the binary API (overload resolution is compile time at the caller site). Code that worked before will continue to work after a recompile.

binary backwards compatibility might be possible with a private string overload, but overloads with different accesslevels might be a can of worms. Anyway, it is not really an issue, everone...

@304NotModified and @jtheisen Overloading string and FormattableString is done using the following trick: https://blog.engdahls.dk/2016/08/how-to-overload-string-and.html The real question is if overloading is desirable at all. Another approach would be ILogger extension...