Letošní CORESTART 2.0 (2. - 3. listopadu) naváže na loňskou “edici”, tentokrát samozřejmě se zaměřením na .NET Core 2.0 a všeho okolo něj. Verze 2.0 už opravdu něco umí a jde na ní solidně stavět. Kromě zahraničních speakerů, přispěji i já svou troškou do mlýna dvěma přednáškami - jedna kolem Entity Frameworku Core 2.0 a druhá kolem novinek v C# 7 a dál. Novinek je hodně a program stojí za to. Přijďte, nebudete litovat.
Yesterday I was rewriting some code from Entity Framework 6 to Entity Framework 2 for testing and discovered unexpected behavior. Luckily, the code fails, so it’s easy to detect.
I’m pretty sure you know what the red squiggle in Visual Studio means (correct, it’s the error). Very likely you know green squiggle (correct, it’s the warning). Maybe you know blue squiggle (correct, it’s the message). But do you know what purple squiggle means? By the way the official name for squiggle in Visual Studio is wavy underline.
Today I found a great new feature for debugging in Visual Studio. Maybe you know the Run to Cursor feature (if not, I’ll explain it in next paragraph), but did you know you can use the same feature from Call Stack as well?
During a break of my user group talk yesterday I got a question about how Entity Framework translates Contains into an IN clause. Whether it uses parameters and how it handles limits that SQL Server has around the parameter count.
Last couple of years I published this blog using Jekyll. Static pages are hard to beat in performance and security. Initially on GitHub pages, then GitLab Pages and eventually moving to Azure. Mainly because thanks to web.config I have more control over the webserver (IIS) and I can do bit more (in fact quite a lot). But lately I started to be more and more tired of Jekyll. It was slow for me and given it’s a Ruby application and me not being fan nor fluent of Ruby it started to add up. For maybe a year I looked multiple times at Hugo, because it was an obvious choice and didn’t liked the templating structure. Also Pelican, because it’s written in Python and I like Python. Not sure why, but I didn’t convert to it. And I also played multiple times with the idea of writing something myself, just to dismiss that idea hundred times because I knew I would trap myself in constantly fiddling with it and burning my free time.
New version 5.11.0.0 of ADO.NET provider for Firebird is ready for download. This release is about .NET Standard 2.0. Now the .NET Standard 2.0, with all the new APIs supported, version is available (this work, together with upcoming Entity Framework Core 2.0 support, is sponsored by Integrative9).
Another new feature is support for passing key over the wire for encrypted databases (you need to have server side plugin for this feature, i.e. this from IBPhoenix). New connection string property crypt key is available for that. The value is base64 encoded data representing the key. You can find small example in tests.
New version 5.10.0.0 of ADO.NET provider for Firebird is ready for download. Apart from regular bugfixes some new features are available. Notably, FbTrace now supports new format of Firebird 3 and then DefaultFbMigrationSqlGeneratorBehavior allows easier customization in case you want specific behavior for Entity Framework Migrations.
I was reading the announcement about Entity Framework Core 2 the other morning and saw “String interpolation in raw SQL methods” paragraph. This was already in preview(s) and I kind of took it as granted, not thinking about how it’s done or what it is doing. Not this time. Somehow my curiosity kicked in and I decided to create same feature and maybe do something with it.
Of course, I could peek into sources, but I decided to use the idea, but build it myself from scratch. I like the idea of using already existing feature from C# and then using for different, but reasonable, purpose. String interpolation and SQL parameters are exactly this.
Asynchronous stuff with async/await in C# is great. But as with any other great tool, there are some gotchas that might cost you something (performance, memory, etc.). Today I’m going to talk about FileStream.
I was profiling FbNetExternalEngine to squeeze a bit more performance from the code and as I was going through stack traces, hot paths and allocations, I realized (again), how geeky I am. I was looking into a stack trace and found it fascinating.
As I said in previous post I had to drop AppDomains from my solution to allow replacing assembly while the FbNetExternalEngine is running. Calls across AppDomains are simply too slow (read: I can’t make it fast enough. 😉) for this kind of project. Why I even needed AppDomains? The specs are simple: Allow assembly replacing (rewrite) while it’s loaded in Firebird via my FbNetExternalEngine. Can it be solved without AppDomains?
Over the last few days I was working on performance of FbNetExternalEngine. Basically doing all I can to make it execute the code quickly as possible. OK, maybe not all I can, but something that gives biggest gain while being able to program it in a reasonable timeframe, because there’s always room for more.
I completely missed some handy methods on Entity Framework Core’s DbContext. Maybe you did too. And that would be a pity.
When I was writing the original post I knew the code was right on the edge. It worked on 2.5 and that mattered at that time. My hope was that it will eventually work forever, because why would you change such thing… Nope.
While writing previous post I realized the deconstruction to tuple can be added to any type. As far as compiler is concerned the Deconstruct method needs to exist, doesn’t matter whether it’s an extension method or instance one. That means I can write a Head- and Tail-like methods in C# with nice syntax. I also dusted off my Haskell knowledge and wrote the same logic there for comparison. And then I did it in Python and F# as well. Brace yourself for a true polyglot post.
As I’m playing more and more with tuple in C# 7 to find out where this is useful and where it falls short and actually bites back later on. And during this I kind of by blind luck discovered more succinct syntax for deconstruction. I reminds me Python, which I like.
Did you know you can store NaN value in Firebird? You didn’t? Me neither, until last week when Slavomír Skopalík showed me whole new world. It was in Delphi, so I was curious how it will turn out from .NET/FirebirdClient.
O/R mappery jsou výborný sluha, ale špatný pán. Abych tak trochu parafrázoval známé přísloví. David Gešvindr dobře zachytil, že v rámci různých Entity Framework přednášek apod. trousím, často i jako odpovědi na otázky z davu, různá doporcučení co nedělat (nebo co naopak dělat). Drobečky jsou fajn, ale dát to trochu do kupy a celkově sjednotit není od věci. A o tom je tato přednáška.
I realized I have some pieces of code to show some specific behavior, mostly around threading and synchronization, all over my notes. Some of these pieces may be 10+ years old. I use these pieces during my “threading/parallel/async” course, but why not to share it publicly. Maybe I’ll stumble on it after some years, maybe .NET will be history, and it will be interesting to re-read and re-think the code. The code isn’t unique or something where I’m the first to realize it. It’s really just an example code.
Today I have a small example that shows how optimizations (compiler, JIT, ...) can make multithreaded code behave differently than expected. I don’t remember where I’ve seen the code. Some book or blog post from - I guess - Jeffrey Richter. Or maybe Joe Duffy or Stephen Toub or ... These guys are very smart.