There would be an app.config in ModelExplorer.ModelDF
by default. That's the way comes out-of-the-box from the DevForce Object Mapper (OM) with its default settings.
However, the only Silverlight CLIENT app.config that DevForce needs ... or uses ... is the one in the Silverlight application project ... which is the "Shell" project in Prism Explorer.
People get really confused when there are a bunch of app.configs around. I had already moved the OM generated app.config to the Silverlight application project (or maybe OM did it automatigically ... I don't remember).
I didn't need one in "ModelDF" anymore. So I removed this unnecessary config and I told the Object Mapper not to create a new one (there's a check box for that).
There is one more app.config hanging around; it's in the ModelExplorer.ModelEF project. That one is for EntityFramework's own use; DevForce does not see or care about it.
Aside: if your DevForce and Entity Framework are in the same project, they can share the same app.config and there will be one there at least for EF's use. Just remember, DevForce only cares about the app.config in the APPLICATION project; thus, the app.config that supports Entity Framework doesn't have to have any DevForce in it at all.
Finally, there is the web.config in the SERVER project which serves the same purpose as an app.config. You will find that it has some of the material (the EDMKeys) that is in the CLIENT app.config. Of course it does *not* have connection strings; these are only needed ... and should only appear ... on the server-side.
Summary:
It is easy to accumulate confusing and unnecessary configuration files. All you really need are:
- app.config in the Silverlight client application project
- app.config in the EntityFramework project (for EF purposes)
- web.config in the server project.
Edited by WardBell - 24-Sep-2009 at 1:20pm