So here’s the scenario:
- Project A has a messaging library that it publishes to NuGet via the build server. This allows other projects to use the same assembly to issue commands as the service that handles the commands.
- When project A builds, the NuGet packages are versioned as Major.Minor.Patch.Revision where Revision is the build number determined by the build server. So the package may be pushed up as 2.1.0, but is modified at the build server to include the build number as the revision and ends up to be something like 126.96.36.199 which we will use for this example
- Project B uses the library that was just published by Project A’s build process so it now has a dependency on version 188.8.131.52.
- For local testing, I am running project A which is still just version 2.1.0
- Project B creates a message with messaging library v184.108.40.206 and Sends it over the bus
- Project A receives the message and throws an exception stating that deserialization failed because it could not load the metadata for JObject etc.
On a hunch, based on the fact that the fully qualified name of the message class was contained in the message headers, I went back to project A (the local one that I was currently running) and changed the messaging library version to 220.127.116.11, cleaned the solution and then re-ran it and tried again, and all was fine so I am assuming that the precision of the version is the problem.
This is problematic because of the problem mentioned above but I can see this becoming a bigger problem when trying to debug locally against different environments (e.g. Integration environments) while trying to keep all the versions aligned, because the build process will basically ensure that the versions are almost never in alignment and having to change it manually every time I make a change during development is going to be a bit of a hassle.
Once upon a time, I was told (Google groups I think) that the deserialization process is supposed to only look for the major and minor versions, but this doesn’t appear to be the case.
Is this expected behavior? Is there a decent way around this?