I did an update to DevEx 7.3.6 today.  Everything seemed to be fine (no build errors...guess I shouldn't just go on that, huh?).  Then a user calls and alerts me to an error.  On her end it was the dreaded mscorlib error.  When I ran the same steps as she did I got this:

InvalidCastException
  Unable to cast object of type 'DevExpress.Utils.ImageCollectionStreamer' to type 'DevExpress.Utils.ImageCollectionStreamer'.

Source     : MicroFour StrataFrame Inherited UI

Stack Trace:
   at MicroFour.StrataFrame.UI.Windows.Forms.DevEx.BrowseDialogwindow.InitializeComponent()
   at MicroFour.StrataFrame.UI.Windows.Forms.DevEx.BrowseDialogwindow..ctor(BrowseDialog BrowseDialogSettings, Boolean PopulateOnShow)
   at MicroFour.StrataFrame.UI.Windows.Forms.DevEx.BrowseDialog.ShowDialog(Boolean PopulateOnShow)
   at Aspire.Sales.SalesOrders.cmdCustomerSearch_LinkClicked(Object sender, LinkLabelLinkClickedEventArgs e)
   at System.Windows.Forms.LinkLabel.OnLinkClicked(LinkLabelLinkClickedEventArgs e)
   at System.Windows.Forms.LinkLabel.OnMouseUp(MouseEventArgs e)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.Label.WndProc(Message& m)
   at System.Windows.Forms.LinkLabel.WndProc(Message& msg)
   at System.Windows.Forms.Control.ControlNativewindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativewindow.WndProc(Message& m)
   at System.Windows.Forms.Nativewindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

How would I prevent something like this from happening?  Everything builds fine, but the application will not run properly.  It is an assembly problem of some kind.  I am looking into it now.

Thanks for any help on this,
Bill

Ahhh...the dreaded version issue.  The message is a pain...and it is not specific to StrataFrame, but .NET.  The problem that you are having is that two assemblies of the same name (and potentially same version) exist.  One is the version to which your assembly was built, and the other is from a previous install or build (it is always a good idea to do a Clean and Rebuild).  Many times I will even "smoke" (Texan for delete) the source folder and get it all from source control again to make sure there are no residue assemblies out there.

This is something that should also be taken into account when deploying your product.  We have some relatively in-depth code in our install (SF and PracticeStudio (our medical software)) that removes any assemblies from the GAC (and other locations) and then adds the new assemblies to the GAC.  This is just a process that you will have to learn to work through...but once you run into it (and fix it) once or twice, it gets easier to work around.

Smokin' the source folder.  I like that.  Thanks! 

If you're still getting that issue, it might be that it's embedded in the source code.  When the .resx file (form resources) serializes an image stream like that, it saves off the assembly qualified type name of the type that was serialized, so the .resx file will most likely have the version in it.  You can sometimes fix this by getting the designer to reserialize it (by modifying the file and resaving it) or by opening the .resx file in the XML editor (right-click within the Solution Explorer and choose "Open With") and find all of the instances of 7.2.0.0 and replace them with 7.3.0.0 (or whatever version(s) you're converting to-from). 

Also, DevExpress might have a project conversion wizard which should take care of replacing the references within the .resx files, too.