We faced a weird problem at customer site. Our integration which uses latest .NET MIP SDK (v25.3.1) started crashing during initialization. We traced it down to deserialization issue. Further investigation unvocered, that (most likely) MIP SDK doesn’t like the floating values in REST API responses. It seems that MIP SDK is parsing them using current culture settings, which for Poland mean that decimal separator should be a comma. A workaround for this problem was to change the default decimal speparator in Windows regional settings, but it would be better if SDK simply uses invariant culture when parsing. Attached you will find the details regarding the stack trace and the raw data that came from the server and caused the problem.
It seems that the server is also affected by this setting. When we call REST API to create a WebRTC session, we get a 400 Bad Request response and the details contains the same Exception!
Regarding the first issue. This fits a known issue that was raised recently and are currently being analyzed in Milestone Development for creating a bug fix.
Please clarify:
Is the XProtect VMS used also version 2025 R3 (corresponding to the MIP SDK version)?
Your observation on the WebRTC, does this work in US English but fails in a Polish server setup, just like the first issue?
Yes, It was tested with XProtect 2025 R3.
Yes, Windows Server running XProtect was setup with English language and Polish regional settings (which includes comma as decimal separator). After we changed the decimap separator to period sign, copied the regional setting to system account and restarted XProtect, the problem was gone.
To sum up, as a workaround, we had to change the regional settings on both server and client (integration host) machines.
Please clarify: What is the version of the Windows OS? You put Windows Server, please give me the details.
Note that I have setup with Danish regional settings which also uses comma as decimal separator but do not see the issue in my test setup.
Windows Server 2025 Standard