This is OT (apologies) but the paranoia about DB200 is unwarranted (IMO).
Yes, it is a pain to have to migrate project modules(*) and if we didn't have to do it life would be a little bit better, but I think NOT making the move is going to be a greater headache in the long run.
For the sake of clarity:
The DB200 breaking change was a dependency update from NetwonSoft 3.5 to NewtonSoft 4.0.? This is often used in S# drivers that require JSON parsing.? If a driver doesn't have the Newtonsoft depenedency, then the move to DB200 is as transparent as any other DB update (yes, I accept that Crestron have broken things in the past, but in general DB updates are pretty solid - I'm also not drinking the Crestron Kool-aid here - believe me, I have plenty of reasons to gripe).
That's it - if your Crestron DB's are NewtonSoft 4 and your module requires 3.5, it won't compile.? If they're the same version, it will - it's no scarier than that.?
The large change in version number does NOT reflect a wholesale change as it might suggest.? I have to admit I may have some responsibility here as I discussed the forthcoming change with Crestron and suggested that a clear distinction in versioning might help identify which side of the NewtonSoft fence you were operating on - the unforeseen side-effect might be that such a big version change /suggests/ a bigger change than the reality.
There is no direct dependency on firmware here either, so you can certainly run a program compiled against one version in one slot and a different one in another slot, just as it shouldn't be a surprise that you can run SIMPL in one, SSPro in another, D3Pro in another and Studio in another.
Sorry to get a bit preachy, but I do think with a little bit of preparation moving projects to DB200 isn't as big a deal as some appear to feel it is.
Sermon over!
Ol
* That's making the assumption that updated modules have been provided by the developer - but any module developer should have done this by now (we had made ours available /before/ the DB200 release)
