Hi Rob,

 

I know you've blogged about this topic some time ago.  I am currently writing a Pluggable design for a UI administrative application where the UI screens are implemented as extensible plugins.  I load these screens using a combination of Assembly.LoadFraom, Assebly.CreateInstance and then load the control asseblies' resources using Application.LoadComponent.  One of the requires of the application is that I can load multiple versions (i.e. 1.0.0.0 and 2.0.0.0) of the same extension.  I can load the resources of one version fine, but LoadComponent fails when I attempt to load the second version's resources with the 'The assembly used when compiling might be different than that used when loading...'.

 

I followed the steps you outlined previously (don't use * versioning, build supporting globalization, etc.) to no effect.  Is there anything else I can be missing?

Chris-

I'm scared that you ran into this without signing.  Can you please give us repro steps or a project that shows the problem?

Thanks, Rob

Chris's comment that this can occur without signing is a bit troubling - if that's going to be true for release, this would be more of a big deal.

 

But if it's as you say in the list, and that you only see this if all 4 conditions apply, this looks very low priority to me. I've always regarded the combination of "*" versioning and strong names to be a mistake. If you're doing that, it means you've got no control over your version numbers. It would mean you can't repeatably build a speciifc version of your code from source control for example.

 

So I've tended to regard the "*" as a bit of a safety net whose only purpose is to provide a slightly better default than 0.0.0.0. (And it's only 'better' in the sense that it has a tendency to make the failure to think about versioning obvious earlier than it might otherwise have been - it's essentially a way of making alarms go off.) Any serious software project should remove and replace this with something that fits into their build process.

 

So I wouldn't be in any hurry to see this issue fixed.

I'm sure we are going to see a lot more of 'we don't plan to fix this for v1'.  I've read previously that Microsoft is planning much more frequent and incremental updates in the future.  Can you say what the thinking is as regards WPF updates?  Not fixing stuff is less of an issue if an update with fixes can be expected in a reasonable timescale.

 

It would also be great to see Microsoft's wish list for WPF and when features might be incorporated, eg. V2/V3, so we can provide feedback as to what we would find most useful.

 

Oh, and tell Bill you guys deserve a pay raise!  WPF is FANTASTIC! :)