Friendly Reminder: Don’t use platform defaults


Don’t use platform defaults as they may not be the same across all machines, especially when sending data in between them.

Microsoft has a big warning section in the Encoding.Default property docs about this.

The story

A few years ago we built web service so we could centralize common configuration settings like connection strings, etc. This way, all of our apps could hit the service to get the latest configuration settings without us having to change them everywhere.

At some point, we decided to put a little more oomph into the security of it. Now we have a little bit of crypto going on to make sure requests are authorized.

I’m building a new service based on the .NET Core platform and I copied over our client code to see if I could get it going. It compiled fine, but started throwing exceptions on the crypto bits complaining about the key not being the right size.

After a bit of debugging, I noticed this bit of code:

static byte[] _bytes = Encoding.Default.GetBytes("blah blah blah");

Sure enough, when running on the core framework, we get a different encoding than on the full framework.

Unfortunately for us, this issue is in a central portion of our services. Everything communicates with this service and this issue is in the code used for communication 🙁

The quickest change we could make would be to use codepage 1252 as our encoding in our new apps, but this leaves us with the issue of being the mercy of the default value. We can’t move that service ever, unless we can guarantee that the default is the same as before.

Another change we should make would be to commit to codepage 1252 explicitly in code. This would at least get rid of the being dependent on platform defaults.

Any other changes, like using UTF8 instead, would certainly involve a lot more work. Since everything communicates with our config service, we can’t just replace it without rolling out new versions of everything at the same time and I’ve never been a fan of big rollouts.

If we do decide to do a big change, we’ll roll out another service with the fix side by side with the old one. Then we can update our other services as needed.

This entry was posted in Azure, C#. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *