🎄 Happy Holidays! 🥳
Most of Solace is closed December 24–January 1 so our employees can spend time with their families. We will re-open Thursday, January 2, 2024. Please expect slower response times during this period and open a support ticket for anything needing immediate assistance.
Happy Holidays!
Please note: most of Solace is closed December 25–January 2, and will re-open Tuesday, January 3, 2023.
Solace .net libraries possibly using no-longer-supported binaryformatter (also, .net5)
In a question thread created late last year, forum user @Anton was asking about a binary formatter exception in relation to his attempt to use .net5.
I have just run into a similar issue. But interestingly, at around the same time that previous thread was resolved, microsoft issued a notice:
BinaryFormatter serialization methods are obsolete and prohibited in ASP.NET apps
Due to security vulnerabilities in BinaryFormatter, the following methods are now obsolete and produce a compile-time warning with ID SYSLIB0011. Additionally, in ASP.NET Core 5.0 and later apps, they will throw a NotSupportedException, unless the web app has re-enabled BinaryFormatter functionality.
BinaryFormatter.SerializeBinaryFormatter.Deserialize
Additionally, it is now coming up to almost a year since that original thread asked about .net5, and .net6 is coming into view pretty rapidly. The performance improvements in .net5 are very significant in many cases.
Can we get .net5 support some time soon? Or at least, remove the binaryformatter dependency? I have been developing code using .net5 and it has been working fine via visual studio, but it failed when I attempted to deploy to an azure VM. As it happens I am not writing ASP.NET, my code is a worker service deployed as a windows service, and I am getting a type initialization exception, not a not supported exception. But I believe this particular component is still the only reason why I can't use .net5 with the solace .net API, at least when deployed to the VM.
Honestly I'm not sure why it works in visual studio, but the fix seems to be the same in both cases: get .net5 support into solace and nix their BinaryFormatter.
My own code is serializing the message payload using protobuf.net, which is much much faster anyway.
Downgrading to .net 3.1 was painful (since I was using .net5 / c# 9 features), but it did succeed. But I would say it's "about time" we got up to current state with .net, and the binary formatter obsolescence does seem to force the issue.
Comments
-
We are going to be delivering .Net 5 support in Dec and it will remove the use of
binaryFormatter.In the meantime, you don't have to downgrade .Net, you could configure the API to allow for its use as per the page you linked above:
To continue using BinaryFormatter in ASP.NET apps, you can re-enable it in the project file. However, it's strongly recommended not to do this. For more information, see BinaryFormatter security guide.
<PropertyGroup> <TargetFramework>net5.0</TargetFramework> <!-- Warning: Setting the following switch is *NOT* recommended in web apps. --> <EnableUnsafeBinaryFormatterSerialization>true</EnableUnsafeBinaryFormatterSerialization> </PropertyGroup>
1 -
That will eliminate the not supported exception experienced by Anton, but the documentation doesn't indicate that it would eliminate a type initialization exception. I don't fully understand why I am getting a type initialization exception rather than a not supported exception, that scenario isn't mentioned by the documentation. Reading between the lines, the fact that ASP.NET is specifically mentioned might be relevant. The whole world seems to to think that the only code is web code, and so everything on the internet is typically phrased in terms of ASP.NET. But I think, in this particular case, the difference might be important.
Since .net5 is coming to solace soon, the simplest answer seems to be to just hold out until then - which is happily something I can get away with doing.
0
