VersionMajMin mechanism and XmlSerializer

[alkhaef]

Hello,

I just started using the VersionMajMin functionality and I found out that it doesn't play too well with XmlSerializer. Particularly, when using code like the following:

Code: Select all

XmlSerializer serializer = new XmlSerializer(typeof(CalmSchema));
calmDataSet = (CalmSchema)serializer.Deserialize(reader);

...you get a nasty exception thrown as follows:

[A]CalmPlugin.CalmSchema cannot be cast to CalmPlugin.CalmSchema. Type A originates from 'CalmPlugin7.2, Version=7.2.17.0, Culture=neutral, PublicKeyToken=null' in the context 'Default' at location 'C:\Documents and Settings\A\My Documents\Visual Studio 2010\Projects\opendental7.2\OpenDental\bin\Debug\CalmPlugin7.2.dll'. Type B originates from 'CalmPlugin7.2, Version=7.2.17.0, Culture=neutral, PublicKeyToken=null' in the context 'LoadNeither' at location 'C:\Documents and Settings\A\My Documents\Visual Studio 2010\Projects\opendental7.2\OpenDental\bin\Debug\CalmPlugin.dll'.

Notice that everything is the same except for the version numbers in the file name. When I delete CalmPlugin7.2, the exception goes away.

Does anyone know how to get .net to recognize the two as one and the same? I read some place about signing the assembly, but when I tried that, it didn't work because OD itself isn't signed <sigh>. Otherwise, all I can think of is to either a) delete the file programmatically upon load... or b) jimmy up my own deployment system... both of which I'd like to avoid.

Best,

[jordansparks]

Be sure to let me know if you figure out the answer so that we can make it behave nicer. The easy answer is to not use the VersionMajMin naming until it's sorted out. It really should not be necessary. I just added the following explanation to the bottom of the plug-in page:

However, using the above two strategies is not necessary for most developers. There is normally no reason to exclude your dll from the file copy routing during an update. And you can assign a version number to a dll without changing the name of the file.

[alkhaef]

Dr. Sparks,

I think your suggestion is the "right way" to go (unnumbered dll name, using the "file copy" routine). However, I didn't see any mention of how that works, so I had originally put off doing that for later.

How exactly does it work? Does any file in "OpenDentImages\UpdateFiles" get copied over to every workstation automatically? I'm assuming it only happens upon update, and not during every start-up, correct?

If all the above is true, would this work as an update methodology, always maintaining consistency between OD and my plugin?

When OD revs up,
0. Restore most recent backup to dev machine
1. Update OD on dev machine
2. Qualify new version of local plugins on dev machine (as well as OD release itself)
3. When passed, copy newest qualified dll to "OpenDentImages\UpdateFiles", overwriting the previous release
4. Run update on one live machine, updating the DB as prompted
5. Run update on all other live machines
6. Enjoy the new OD release and respective matching plugin on all machines

Thanks,
Al

[jordansparks]

I just added a section at the bottom of that page describing the normal update sequence. I didn't realize it was quite so complex until I saw it written out. I honestly haven't come up with a good sequence for releasing dlls. Your sequence would work if you made a small change to it. You have to copy the dll into the OD application folder after updating the first workstation but before restarting OD on that workstation. Because as soon as you fire up OD after an update, it immediately copies its own files to the UpdateFiles folder. That's the only time it happens.

[alkhaef]

Dr. Sparks,

Great explanation. Thanks for all the details and feedback! Yes, I expected the update sequence to be nontrivial to work as well as it does, but wow

My sequence re-ordered as you described looks like would work, but IMO it would be a little error-prone (especially if I'm not the one actually performing it). How about the following sequence?

0. Restore most recent backup to dev machine
1. Update OD on dev machine
2. Qualify new version of local plugins on dev machine (as well as OD release itself)
3. When passed, copy newest qualified dll to live updating machine, overwriting the previous release
4. Fire up OD on live updating machine, making sure plugin screams about version mismatch and doesn't load, with plugin version matching new to-be-updated OD version
5. Run update on live updating machine, updating the DB as prompted
6. Fire up OD again on live updating machine, making sure plugin doesn't scream
7. Run update on all other live machines
8. Enjoy the new OD release and respective matching plugin on all machines

Yes, this relies on strict major/minor/patch version mismatch checking/blocking within plugin code, but to me it has the following benefits:
a) It forces (maybe reminds is a better word ) someone to qualify everything together (step 2), b/c they have to rebuild to update.
b) It guards against an accidental wrong-file-copied forcing you to re-roll-out manually (like I'm doing now - ugh - can't wait till I take advantage of this)

Based on your explanation, it looks to me like the above sequence would also work, right?

Best,

[jordansparks]

Yes, it would work. But I prefer making dlls both backward and forward compatible as much as possible. Less screaming. Why not track the current dll version somewhere in the database, kind of like we do with ProgramVersion. I think I placed an example of such version tracking in the plugin demo. If you start OD and there's a version mismatch, it means that the dll was already updated on another machine. At that point, trigger a download of the dll from a centralized location.

[alkhaef]

I remember the version tracking in the demo for DB updates. Fortunately, my plugins haven't started touching the DB yet, but I'll look into it again in the context of file updates. Hmm... What you're describing sounds like a good idea. I'll have to think about it a little more to see if it achieves my goal - forcing/reminding someone to validate the plugin against OD upon every update. I'll explain why...

I can try to make things as forward-compatible as possible, but I prefer not to rely on that (my psychic isn't a very good one ). Case in point - when I updated from OD 7.0.?? to 7.2.??, I found that my plugin needed some changes to get working - one minor example being that InsPlans.Refresh was renamed to InsPlans.RefreshForFam, another related to some assumptions I'd made about the ODGrid that had changed (not catchable just by seeing if it compiled).

Had I not forced myself to re-qualify, there would have been runtime errors and I'd be in fire-fight mode with patients floating around.

Granted, I fast-forwarded through TWO major versions there, and that work would *probably* only have to be done during a major-version upgrade, but I figure a unified, albeit paranoid, update sequence is simpler than two least-effort-necessary ones and treating minor-version-upgrades differently than major ones. Plus, there are no guarantees that my code doesn't self-destruct on a minor-version-upgrade.

Thanks again!

[alkhaef]

Just wanted to give a quick update on this...

I tried out a slightly modified version of the sequence above, and it works great. Soooo much less painful to roll out an update!

FYI for anyone that lands on this thread later, I just did it slightly different in the following ways:
a) I forgot to put the plugin on the updating machine before updating, so I manually put it in OpenDentImages myself after updating the first machine.
b) Made the plugin just check for major/minor version match... Not patch version. As you said, less screaming... I'm nervous though - I've written my code so I can take advantage of OpenDental's own code as much as possible (namely, OpenDentBusiness layer). Some things changing on a patch release may make my plugins explode. Currently, I don't see any documentation on the website stating what may/may not change between major, minor, and patch releases.

Thanks again!