We had a need to override the default JsConfig<DateTime>.DeSerializeFn behavior. So I mocked up my behavior in a single DTOed AppSelfHostBase in order to prove functionality. Worked perfectly (running in trail mode as I had not registered our license).
I move my override to the working project which registers the license via the servicestack:license key in our web.config…Suddenly the only serialization delegate that gets fired is my DateTime? one. I cannot get DateTime to fire at all. Strange…A few hours and a plethora of curses later I realize somehow the licensing registration is my root issue.
It would appear just like having to register JsConfig<> overrides before the AppHost.Init(), it also must happen before registration? And if you have your key in the web.config this licensing process must kick off before the JsConfig override was placed (I believe because the default DateTime deserializer is called in the validation of the license and thus caches this delegate before I could register my custom one).
Once we switched to calling ServiceStack.Licensing.RegisterLicense (post JsConfig mods) all behaved as intended.
It was confusing on our end for sure, we expected all 3 license registration methods to behave the same. I’m not sure if this is a known quirk, but I could find no direct mention of this in my searching around. Not sure if the web.config key method could be altered to behave similar to calling just before the AppHost.Init(), otherwise a bit of further documentation on the discrepancy would be nice for others that much run into this issue.
Ouch, looks like the DateTime Type Caches are pre-populated at the time the license key is parsed. I’ve added cache refreshes after assigning JsConfig<T> delegates in this commit.
This change is available from v4.0.41+ that is now available on MyGet.
Can you let me know if the latest version resolves this issue? thx.
This makes the behavior worse (when using web.config registration). I immediately get an exception which seems to be sourced at ServiceStack.LicenseUtils.Init() at ServiceStack.Text.JsConfig…cctor() when setting any JsConfig<> override…no exceptions occur when manually registering license in code.
That said, I reverted to 4.0.40 and now I cannot reproduce my original issue at all today! My VM did get rebooted since I was testing on Friday, so perhaps it was in an odd state. It now seems to act fine under code or web.config registration methods. I apologize if I sent you down a rabbit-hole for no apparent reason.
Well now that it’s been done I want to fix the initializer exceptions rather than going back and reverting it. I’ve created a simple project to try repro this and was only able to rerpo an exception if the JsConfig<DateTime>.DeSerializeFn was registered before the AppHost was initialized, is this what you were doing? If so the latest v4.0.41 on MyGet should now work without exception.
If you were able to raise an exception another way could you tell me what you did so I can test it to make sure it’s no longer an issue? thx.
My prior tests were registering before the AppHost.Init(), moving the JsConfig<> overrides into my AppHost constructor has everything working smoothly.
Thanks