Does it really matter??

Topics: Prism v2 - Silverlight 2
Jan 21, 2009 at 4:19 PM

I have upgraded my project with Prism 2 Drop 9 today. I was a bit disappointed a bit. 

1. Microsoft.Practices.ServiceLocation.Silverlight.dll

Why did you guys rename this assembly? We are totally fine with Microsoft.Practices.ServiceLocation.Silverlight.dll or Microsoft.Practices.ServiceLocation.dll. but we have been using Microsoft.Practices.ServiceLocation.Silverlight.dll for all of our modules since early drop. Now, we have to change the reference manually for all projects and also, SVN. 

And also, it's not in the doc. Initally, Microsoft.Practices.Unity.Silverlight.dll was renamed to Microsoft.Practices.Unity.dll in Drop 7 too. 

3. Command  (cmd:Command.Click => cmd:Click.Command)

I'm not sure why you guys did this. Actually, I like cmd:Command.Click instead of cmd:Click.Command. We endup changing all of Silverlight XAML. But thanks! we have VS "Find and Replace" function. 

I really like to request you not to change the name if it's not really needed. There are some people who are using Prism vs "Alpha" in real project because we want to support both WPF and Silverlight. 


Jan 22, 2009 at 1:33 PM
Be careful what you ask for...  When the Microsoft teams provide "drops" for us they are giving us a peek at what's coming down the pipe.   A Golden rule with one of my contracts is that I am not allowed to use Beta or CTP - it must be released.  In the case of our last sprint I sold the team on Prism V2 drop 8 because there were no other viable solutions (short of the Web Client Software Factory which doesn't support Unity).

Like yourself, I've been forced to refactor (and will have to again)....  The alternative is to rewrite "when there is a release" because I wrote an application on a framework I can no longer use; I'd rather refactor than rewrite...

My concern would be that if there are two many complaints that Microsoft may find "drops" to be counter productive (reputation black-eye).    As Agile programmers we constantly change/refactor as requirements dictate - let's not tie their hands or we may have to wait until the CTP.
Jan 22, 2009 at 2:14 PM
Sorry if my post is not good.  It's just a suggestion. I was wondering if there is any value after re-naming. 

1) Okay. Let's them rename. At least, it should have mentioned in ReadMe or Doc or etc, right? This is the breaking changes.

2) If Prism team is adding super cool feature by re-naming the namespace or class, I would be really happy to refactor the code.  Now, it's just nothing but re-name. Do you think this is really good to change cmd:Command.Click to cmd:Click:Command .. maybe, it might be like cmd:Command in next release. 

Jan 23, 2009 at 4:17 PM

I completely understand your frustration around this.  Despite all appearances, we like to think we have reasons for the renames. :)  For instance, the Command.Click to Click.Command was a change discussed at length with our advisor board and the WPF/SL team as one that would be easier for users to 'extend' in a logical way and may better align with the direction of the platform.  With the Command.Click approach, if someone wanted to extend the library to have a new event they would have needed to modify the Command class in the library or provide their own Command class with the new event.   With the current approach, they can follow the pattern used for the Click event for their own event.

I agree we can do a better job with highlighting the breaking changes.  And to let you know, there will be another change in the assembly names (not namespaces) in the next drop that may affect you as well.  We are dropping the .Desktop and .Silverlight extensions to these assembly names.  One of the primary reasons for this is that it makes Xaml less portable if we have the extensions in the assembly name and, as you've pointed out previously, there is no #SILVERLIGHT option in Xaml.


Jan 27, 2009 at 6:20 AM
Thanks a lot, B
Feb 3, 2009 at 12:14 PM

Hi Michael,


To help with the assembly name changes Ezequiel Jadib created a Powershell script that “will look for all the .csproj and .xaml that contain references to the old prism assemblies and will update it to the new version of them.”


He blogged about it and uploaded the script so it can be downloaded:

·         Prism v2: Migrating from Drop 9 to Drop 10



Please let me know if this helps.


Damian Schenkelman