New Posts New Posts RSS Feed: DevForce Silverlight cannot locate client side model assembly
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

DevForce Silverlight cannot locate client side model assembly
 Post Reply Post Reply
Author
  Share Topic Share Topic  Topic Search Topic Search  Topic Options Topic Options
WardBell View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 31-Mar-2009
Location: Emeryville, CA,
Posts: 338 		Post Options Post Options   Quote WardBell Quote  Post ReplyReply Direct Link To This Post Topic: DevForce Silverlight cannot locate client side model assembly
    Posted: 06-Jul-2009 at 7:27pm
You build (or run) and get the message:
 
DevForce Silverlight requires that both the client and server assemblies containing your domian model classes have the same fully qualified name on both sides.
 
DevForce was unable to locate a client side assembly matching the server side assembly with the following name:
 
"Something.Model, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"
Everything seemed to complile fine except you get this message.
 
You've checked the obvious:
  • There are client and server side model projects
  • Despite the different project names, the project properties reveals that the assembly names are identical and really are "Something.Model"
  • You check that the assembly versions match; they are both "Version=1.0.0.0" for example
  • The app.config in the Silverlight Client Application Project (the only app.config that matters) has the proper probe assembly with strongly typed name for the model assembly ("Something.Model, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null")
  • The web.config in the .NET Web project identifies exactly the same model assembly (it need not be ... perhaps should not be ... strongly named).
  • The IdeaBlade assembly versions are up-to-date everywhere

What did you forget?

Maybe, like me, you neglected to have a reference to the Silverlight model assembly in your Silverlight Application project!
 
It's really easy to leave this out ... or delete the reference because ReSharper tells you nothing in that project is referencing the Silverlight Model assembly. Indeed, thanks to your instinct for loose coupling, nothing in that project should reference the model.
 
Unfortunately, as of this writing (v.5.2.0 and earlier), DevForce needs that reference or it can't connect the dots.
 
I'll look to see if we can change this in future. Until then, add the reference to the Silverlight Client Model project and the message should go away.
 
Ward
Back to Top
ryanhaney View Drop Down
Newbie
Newbie


Joined: 20-Mar-2008
Location: United States
Posts: 15 		Post Options Post Options   Quote ryanhaney Quote  Post ReplyReply Direct Link To This Post Posted: 17-Jul-2009 at 1:34pm
Ward,

I get the same error you've outlined above.

Here's how my project is structured:

Solution
- DomainModel
- SL1
- SL2
- WebApp (with edmx)

I'd like the two SL apps to be able to reference the same domain model.  When I compile and run the WebApp pointing to a page linked to SL1, everything works great.  When I try to run a page pointing to SL2 (or even just try to build SL2), I get the "cannot locate client side model assembly" error.  The app.config files are identical.

The "SilverlightTargetProjectName" in the ibedmx file is "SL1", which I suspect has something to do with it.

Is there a way to support this scenario?
Back to Top
ryanhaney View Drop Down
Newbie
Newbie


Joined: 20-Mar-2008
Location: United States
Posts: 15 		Post Options Post Options   Quote ryanhaney Quote  Post ReplyReply Direct Link To This Post Posted: 17-Jul-2009 at 1:53pm
Well, I don't quite know if I have answered my own question, but by creating a new model via the DevForce Object Mapper and pointing it to the same domain model and SL2, I can compile both projects now, despite that the ibedmx is now pointing to SL2.  Can you give me some insight to the magic being pulled off here?  Aside from the actual linking of domain model files, are there any additional steps to manually linking a domain model to an SL project so it can compile?

Thanks,

Ryan
Back to Top
ryanhaney View Drop Down
Newbie
Newbie


Joined: 20-Mar-2008
Location: United States
Posts: 15 		Post Options Post Options   Quote ryanhaney Quote  Post ReplyReply Direct Link To This Post Posted: 17-Jul-2009 at 1:55pm
And....can we get support in the DevForce Object Mapper to link the domain model to many SL projects?
Back to Top
ryanhaney View Drop Down
Newbie
Newbie


Joined: 20-Mar-2008
Location: United States
Posts: 15 		Post Options Post Options   Quote ryanhaney Quote  Post ReplyReply Direct Link To This Post Posted: 17-Jul-2009 at 2:27pm
As you can tell, I like to talk to myself.....

Something to point out, you don't NEED to create a new model, just open the existing one via the DevForce Object Mapper, change the "Silverlight Project" option to the Silverlight project you wish to add the domain model to, and save it.  After that you should be able to compile.
Back to Top
WardBell View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 31-Mar-2009
Location: Emeryville, CA,
Posts: 338 		Post Options Post Options   Quote WardBell Quote  Post ReplyReply Direct Link To This Post Posted: 19-Jul-2009 at 8:55pm

Ryan, my friend. Oh my!

Just to be sure, I'm going to state what I believe to be your wish ... and then answer it. I think you want one model and you want multiple SL assemblies to be able to refer to it.
 
Let's get some basics down. If you want one model, then EXACTLY one SL assembly should hold that model. In your original example, it was SL1. Everything would have been fine had your SL2 referenced SL1. You may not want SL2 to reference SL1 ... but that's an architecture issue, not a technology one.
 
In attempting to create a "second" model based on the first, it looks like what you really did was tell the ObjectMapper that the corresponding SL project is SL2.
 
The OM -- which will generate one model designer file in the (.NET) Domain Model project -- thinks that the SL companion is in SL2. Indeed, in SL2 there is a link to the (.NET) model designer file named something like xxx.DomainModel.Designer.cs. You can tell it is a file link by the little shorcut symbol in the lower-left of the file icon in the VS Solution Explorer.
 
Meawhile, back in SL1, you've left behind a similar link back to this same (.NET) model designer file in DomainModel. The only difference at this point is that the OM thinks to maintain the link in SL2 and has "forgotten" the link in SL1.
 
Your VS Solution hasn't forgotten. Both SL1 and SL2 have links back to the same file in DomainModel. When you compile them, SL1 and SL2 each compile and each get their own copies of the domain model classes. If you defined a DomainModel.Customer in DomainModel project you will have another in SL1 and a third in SL2.
 
The amazing thing is that this actually works!
 
As long as SL1 and SL2 never refer to each other and no other assembly refers to both SL1 and SL2 you might survive. I'm not sure if the EntityManager will get confused after running in both SL1 and SL2; it probably will because once it learns about the model from either SL1 or SL2 it thinks it knows what the model looks like ... and won't relearn. Since DomainModel.Customer is structurally identical in both SL1 and SL2 there shouldn't be a problem.
 
If you rerun the OM, all three project models are updated. More precisely, you only ever update the DomainModel file (even if you manually edit ... which you shouldn't); the 2 file links point to it so, after compile, it is as if the OM updated all 3.
 
But it's a really bad idea. I'm going to completely forget about the fact that you are carrying the extra weight of two entire model definitions in your SL assemblies. I'm worried about confusion, mistakes, and the risk of referencing two assemblies that both have models (when you do that, the compiler will complain about duplicate definitions of some of your model classes).
 
Suppose you want to add custom logic, e.g., by adding Customer file with partial Customer class. You should put this in your DomainModel project and link to it in ... well you'll have to remember to link to it in SL1 and SL2.
 
When you want multiple SL assemblies to share the same model, CREATE A SILVERLIGHT MODEL PROJECT. Do as I did in Model and Prism Explorer; add a Silverlight "ClientModel" project. This is where you put the link files. This is where the OM should think to look for the doppleganger of the DomainModel Designer.cs file. 
 
Then let SL1, SL2, SL3 .. SLn make reference to ClientModel. Now you have ONE copy of the model in Silverlight land.
 
How do you get there from where you are now? You're already hooked into SL2.
  • Rename SL2 to "ClientModel"
  • Create a new Silverlight project called "SL2"
  • Move everything except the model link file from ClientModel to the new SL2
  • Add a reference to ClientModel to SL2
  • Remove the model link file from SL1
  • Add a reference to ClientModel to SL1
  • Open the xxx.DomainModel.ibedmx in the OM
  • Change the associated SL project to "ClientModel"

I think this should get you back on the right track.

Happy trails! ... Ward
Back to Top
ryanhaney View Drop Down
Newbie
Newbie


Joined: 20-Mar-2008
Location: United States
Posts: 15 		Post Options Post Options   Quote ryanhaney Quote  Post ReplyReply Direct Link To This Post Posted: 19-Jul-2009 at 10:18pm
Thanks for the in depth response.  Your solution makes sense and is infinitely cleaner :-).  I must have been smoking crack that day, because I should have thought to point the OM to a separate assembly.  It begs the question though, shouldn't the project template handle the creation of the SL domain model class library?  And while we're at it, shouldn't it also create a (non-SL) domain model class library as well?
Back to Top
ryanhaney View Drop Down
Newbie
Newbie


Joined: 20-Mar-2008
Location: United States
Posts: 15 		Post Options Post Options   Quote ryanhaney Quote  Post ReplyReply Direct Link To This Post Posted: 20-Jul-2009 at 9:40am
The other thing I would like to mention, is that I was getting the error despite that the domain model was linked in SL2, the same as SL1.  Is there any behind the scenes magic that the OM is doing to create those links?  It didn't seem to work until I pointed the OM to SL2.
Back to Top
WardBell View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 31-Mar-2009
Location: Emeryville, CA,
Posts: 338 		Post Options Post Options   Quote WardBell Quote  Post ReplyReply Direct Link To This Post Posted: 20-Jul-2009 at 11:00am

Ryan - We struggle internally with what the template should do.

My personal preference (and that of some colleagues) is that we should favor separation into a SL UI project, SL DevForce Model Project ("ClientModel"), .NET DevForce Model Project ("DomainModel"), and .NET Entity Framework Model Project ("DomainModelEF") ... as in Prism & Model Explorer.
 
But that's FOUR projects. A great number of wonderful, potential DevForce users will look at that and say "Four projects to create 'Hello, World'?  You're KIDDING me! I'm outta here." ... and they will never see that DevForce makes your development life easier.
 
So we shot for the minimum two projects, expecting (praying) that the seasoned architect will reason (correctly) ... or at least ponder ... that he can easily build a DevForce application made of projects with separate responsibilities.
 
Of course "architects" are as likely to be prematurely dismissive as anyone. Heck, they are eager to dismiss without looking... just as I will happily offer you an in-depth review of a movie I've only read about.
 
Fact: there are fewer of them == fewer potential customers to lose.
Fact: the stridently dismissive kind are less likely to appreciate anything we do (they want to write everything themselves).
 
We MIGHT consider offering TWO templates: the "Hello, World" template and the 4 project template. The risk is that we'll lose people with confusion about which template to use. We'll research the pros and cons.
 
--
 
The "behind the scenes" is to be found in a few lines of the ibedmx XML. Go ahead, look at one. Here's Prism Explorer's in its entirety.
 
<?xml version="1.0" encoding="utf-8"?>
<IbEdmxRoot TargetProjectName="ModelExplorer.ServerModel" SilverlightTargetProjectName="ModelExplorer.ClientModel" CodeGenLanguage="C#" xmlns="http://schemas.ideablade.com/v4/edmx">
  <EdmxRef FileName="..\ModelExplorer.ServerModelEF\Model1.edmx" />
</IbEdmxRoot>
 
Notice the pointers to the three participating projects. Clearly one could hack this to change where the Object Mapper thinks things come from and go to.
 
Important Advisory: This is OUR file and its format is subject to change, release to release. Modify at your own risk. The only approved way to change this file is through the Object Mapper. You have been warned.
Back to Top
ryanhaney View Drop Down
Newbie
Newbie


Joined: 20-Mar-2008
Location: United States
Posts: 15 		Post Options Post Options   Quote ryanhaney Quote  Post ReplyReply Direct Link To This Post Posted: 20-Jul-2009 at 11:41am
Don't forget the WebApp to host the services - that's FIVE.  And I'm OK with that.

I've been in places where the architect wanted to build everything.  I know where you are coming from.  What about asking the question during template execution?

"Would you like to create separate domain layer class libraries?

- Yes: Greater separation of responsibilities

- No: Coupling between domain model and UI

(also known as)

- No:  I love refactoring!"

I do see your point.  I am curious, however, where the average threshold lies with respect to number of projects, and what is the "right" thing to do.

With respect to the "behind the scenes" comment, there must be something else.  The SL2 project had the domain model links, but upon build displayed an error dialog stating the domain model was not referenced in SL2.  This error only went away once I pointed the OM to SL2.  SL1 continued to compile even though the ibedmx was pointing to SL2.  Is there some type of one time only build validation you guys perform?
Back to Top
WardBell View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 31-Mar-2009
Location: Emeryville, CA,
Posts: 338 		Post Options Post Options   Quote WardBell Quote  Post ReplyReply Direct Link To This Post Posted: 20-Jul-2009 at 12:19pm
We could ask questions. That means you have to install a wizard (which, in fact, you are ... but a different wizard :-) ).
 
Like I said, we may revisit this decision ... as we get more feedback ... such as yours.
 
You may be right about other magic. I was working from memory. It is possible (likely) that the OM is also adjusting/adding build events in one or more of the projects. This would be another reason to avoid simply hacking the ibedmx! 
 
I don't know personally ... and I'm going to postpone looking for awhile if that is ok with you because I don't think the answer would materially change my recommendations. 
Back to Top
ryanhaney View Drop Down
Newbie
Newbie


Joined: 20-Mar-2008
Location: United States
Posts: 15 		Post Options Post Options   Quote ryanhaney Quote  Post ReplyReply Direct Link To This Post Posted: 20-Jul-2009 at 12:22pm
I think the minimalistic approach would be to cover this in a tutorial.

And no, I don't mind.  My issue was essentially solved.  Thanks for all your responses ;-).
Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down