Blend throwing System.MissingMethodException with custom-made Sample Data

Blend 3 has a pretty cool new feature called Sample Data. It's great for quickly building some design-time data that can be displayed in the design view and give the developer/designer a good idea of what the screen will look like at run-time (with a few quirks here and there).

Personally though, for developing a real application I don't like it much. It's cumbersome having to use the Blend UI for building the data when compared to the speed with which it can be accomplished writing a few lines of code. The UI has limitations too, for example, when creating a sample data object with several properties of the same complex data type. You can spend hours in the UI fiddling around with the data doing something that you could accomplish in code in minutes... or less. Additionally, you do additional things such as defining commands in your sample data, which you can quickly set breakpoints on when you run a test harness and confirm that your databindings are working correctly.

Oh, and don't ever try fiddingly around with the generated code for the sample data. You'll get bitten, trust me.

However, for our interaction designers here, it's absolutely perfect for their rapid prototypes they want to show to the client. Considering they also don't have much of a clue about coding in .NET and it's pretty much a no-brainer.

That said, for our actual implementation I prefer that our team hand write the sample data. Ultimately it's quicker.

That leads me to a problem I spent the entirety of the last day on at work. During design-time, Blend starting throwing System.MissingMethodExceptions, and the design-time data on some controls was not working. Attaching Blend to the Visual Studio debugger revealed that when loading the offending XAML file, .NET was complaining of the type being declared in multiple DLLs.

Turns out the problem (it appears) was to do with the fact that the project in question is targeted at both WPF and Silverlight, with both projects in the same solution (and using the P&P Project Linker to help manage the shared code). Since both project haves some DLLs with exactly the same name (in this case, the Models DLL that is generated from the WCF service's WSDL) Blend was getting confused. In the end I saw no alternative other than to separate the WPF and Silverlight projects into separate solution files. The problem disappeared immediately

Oddly enough, I couldn't find anything about this anywhere on the web. So I figured I'd write about it here before I forget about it and wonder why things had been split into separate solutions.