Friday, 21 October 2016

The self-evident things we do or sometimes don't

This week I had quite a bit of frustration at work. This post is meant as therapy.

Here's the cause of my troubles.
For a project my team inherited we used a client-server architecture where communication was handled with remoting and binary serialization (old school, I know). The dto-project was referenced in the client and the server solution as a project reference, not an assembly (for all the wrong reasons). All worked well in all deployment stages.

We needed to make changes to the client. We've been using Visual Studio 2015 for a couple of months now but never needed to change this client or server in a manner that caused the sln file to change the visual studio version until now.

When running the server and client (from vs 2015) locally everything worked. But once we tried deploying it using a build server the deserialization broke. With a useless exception, as is often the case with the .NET binary serialization.

To summarize a couple of days of debugging and testing:
The sln file of the server mentioned vs 2013 while the client mentioned vs 2015. When building on the build server(with msbuild) the compiler was selected according to the vs version specified in the sln file. When running locally the compiler version was always the one from vs 2015, as the solutions were opened in it.

Apparently the built dto assemblies were different enough to cause serialization exceptions. Build from exactly the same code but with a different compiler that is. We came to this conclusion comparing the assembly sizes and using a binary compare tool.

There are things you do without thinking, like using a package for your dto classes project and only building them once for each release or maybe using something less brittle than binary serialization.

These kind of issues let you feel the pain that can be caused not doing those obvious things.

No comments:

Post a Comment