Re: R# - Have encountered this too. I am a R# fan. Not sure what to do. Tempted to blame R# :-)
I believe the root cause is the ordering of the usings which plays into the compiler's resolution of competing extension methods. That's why one ordering of the "usings" works and the other does not. I'm not sure that there is anything we COULD do about it.
Personally, I think of it as a PITA, not a "big problem". You encounter it once per ViewModel class. If you're writing that many ViewModel classes by hand, I'd be tempted to (a) write a CodeSnippet, (b) write a R# live template or (c - my fav) write a Visual Studio VM class file template to spit out the boiler plate.
--
Re: Designer Troubles
"Our Bad".
Through DevForce v.6.0.3 we required that the paired model assemblies (regular .NET and Silverlight .NET) have the same assembly name. Our bad. The application compiles and works with this convention but tooling hates it.
The Designers (and R# and TFS btw) get confused when they see two assemblies with the same name. Only one of them is used in Silverlight.
Unfortunately, the tooling lives in regular .NET and decides to look at both assemblies EVEN THOUGH ONLY THE SL ASSEMBLY COULD EVER BE USED.
Fat chance getting Microsoft (or R#) to fix this. We must accommodate them.
As of DF v.6.0.4 (to be released shortly), the desktop and SL model assemblies can AND SHOULD have distinct assembly names (e.g., Model.Desktop and Model.SL).
Our templates will take care of this for new applications. You will have to change the assembly names of model projects in existing applications (like yours). Your Designer problems will go away.
N.B.:
The namespaces must be the same. The employee class must be "YourModel.Employee" in both "YourModel.Desktop" and "YourModel.SL"
--
When converting simple demo applications with two projects (SL and Web), the Web project is the regular .NET model project. For example, in apps created with templates from v.6.0.3, the assembly names in MyApp and MyApp.Web are both "MyApp". I recommend that you leave that assembly name alone in the web project. Go to the Silverlight application project and change it's name to "MyApp.SL".
--
Sometimes, when you change the name of the regular .NET assembly with the EDMX in it, the app won't start; you'll see an exception complaining about not being able to find the endpoint and asking you to try all kinds of stuff (e.g, set Copy Local = true for the IdeaBlade assemblies). These are all common causes of the problem DevForce is struggling to resolve. They are NOT the cause in this case.
The problem is that both Visual Studio and EntityFramework EDMX got confused. It's holding on to an old EF connection string that describes the location of the Entity Framework part files (CSDL, MSL, and SSDL).
The telltale sign of this: open the EDMX and "Update from Database". If it needs help finding the database (it will show a wizard for finding the database), you know that the EF connection string has changed.
Often you can't find the difference. It's there but the string is so long that it's hard to see.
- Help it find the database.
- Find its updated <ConnectionString> either in the model app.config or the web.config.
- Copy that <connection string> to the config file(s) that need it (e.g., web project's web.config, test project app.configs, etc.).
- If your config defines EDM keys, update them with the string
** Extra Voodoo **
Sometimes you STILL get trouble. Maddening. Here are some steps that I follow (after hitting my head on the desk):
- Clean the solution
- Delete bin directories
- Close and reopen Visual Studio