I started looking at Silverlight.FX by Nikhil Kothari to replace Prism/Unity with our Silverlight 3 project.
So far I like the code layout and structure. It looks well thought out.
But I can't get a lot of the samples working due to a System.Reflection.AmbiguousMatchException. Anyone else seeing this? Should I not be using this framework with Silverlight 3?
I'm using the framework with Silverlight 3 without issue. Referencing the pre-built dlls works for my project but I haven't tried compiling the source myself. Have you tried using the dlls?
After some heavy debugging this error is coming because some of the class names that Nikhil used I believe are now in Silverlight 3 beta 1. In the TaskList example the ListView's DataTemplate has a HoverEffect
<fxeffects:ColorFill FillColor="#406795D1" Duration="0:0:0.25"/>
This is the one causing all the problems I saw. Removing this took away the AmbiguousMatchException.
Well, that is avoiding the problem, not solving it. It looks like the problem is much deeper, and anything that uses classes that derive from the Effect base class is broken. That makes the use of Silverlight FX pretty boring.
I have tried to use the lib in the past, and had issues with it. While Nikhil Kothari is amazing in the things he has worked on, and his technical abilities, I find that he is not so responsive to solving issues (BTW, someone already posted this problem on his blog, without his response). I do not want this to sound like a knock on Nikhil, it is just something you need to consider when using open source for real-world projects.
I sure hope someone can figure out what the deal is with those classes, I have spent many hours debugging, without solving the issue.
I tried the Amazon Store sample and the TaskList sample using the latest version of the library (3.1 built against SL3), and samples seem to work fine, including the ColorFill effect.
I did rename the Effect class to AnimationEffect which you'd need to avoid the ambiguous API compile error you'd see if you tried to recompile the sources... but precompiled binaries would have been fine. Not sure I see why you'd get a runtime reflection issue however.
Sorry, I know it can be frustrating to not see a response/fix immediately, but theres just too many things going on esp. before a release. My hope is having the source around at least enables you to debug into/break into so at least one is not completely blocked. Yes, I realize its suboptimal, but at the same time it is the reality, as Noam pointed out... :-(