One thing that blew up for us in a very unexpected way is it appears ConfigureServices is now called in Startup when using WebApplicationFactory even when you use .UseStartup on the builder in the WAF. All our tests started breaking.
Huh, I didn’t see that in the master list of breaking changes. I wonder if MS is even aware that they broke that.
I really, really, really do not get why they change this stuff with every release, breaking a lot of code and nearly all documentation.
Part 2 covers historical technologies that are being removed from .NET 5.
Thread.Abort was never implemented for .NET Core
This is going to cause so much grief in my team.
No, it’s not a breaking change in .NET 5, those are technologies removed from .NET Core. It’s not a breaking change if you’re moving from Core 3.1 to 5, which is what most people should be doing.
Interesting that BinaryFormatter is being deprecated. I always considered it the equivalent of python’s pickle serialization. Insecure, but damn useful when you want a simple way to convert POCOs to bytes.
Anyone know of an alternative? Most other serializers require some sort of markup of schemas, or support a very limited subset of types. That’s fine when communicating over the wire, but annoying for less structured operations.
From the article: https://docs.microsoft.com/en-us/dotnet/standard/serialization/binaryformatter-security-guide#preferred-alternatives
JSON.Net can serialize to BSON (binary json).
This one bit me hard.
I just put a pragma to stop the warning and use it anyways because I don’t know another way to turn a POCO into a byte array.
Would it be possible to pull the serializer out of gRPC?
File Location for Bundled Applications
Isn’t this only for linux? Windows still has to extract the bundled app to a directory, as it cannot load dlls and such out of it’s own image.
Assembly.Load accepts a byte array. So I don’t see why it would need to load the image from disk instead of memory.
https://docs.microsoft.com/en-us/dotnet/api/system.reflection.assembly.load?view=net-5.0
But I admit that I don’t know a lot about this topic.
On Windows for .NET 5.0 it doesn’t extract and you only end up with 3 extra files clrcompression.dll, clrjit.dll and coreclr.dll
I believe that’s not the case anymore and it can run packages assemblies directly from memory now in 5
There are many ways to obtain where the application is sitting (root folder and stuff)
but when I do small tests on simple apps I tend to just use relative paths
e.g File.ReadAllText(Path.Combine("/data", fileName))
can someone point me weakness of this? I was always scared that relative may be changed, but wasn’t it the problem mostly in Desktop apps that use file dialogs?
I’ve recently worked on a console app that used this logic to load a private key file into the app. E.g var key = new PrivateKeyFile(“keyFile”). The keyFile was indeed in the root directory of the app and worked fine on windows. Fast forward to moving it to the Linux server and turns out cron jobs search roots home directory not the app’s running directory like windows. Anyway, after a bit of digging it was looking for the key file in /home/root/keyFile.
Fixed with Path.Combine(AppDomain.CurrentDomain.BaseDirectory,”keyFile”)
C# devs
null reference exceptions