Metadata issue with multiple Breeze models and contexts

Question

Has anyone else tried using the Breeze.js server component in a solution with multiple Api controllers for multiple EF models?

I find that after calling a MetaData endpoint in one context, all subsequent calls to MetaData endpoints in other contexts return MetaData from the first context that was called, for example, I say that I have two Api controllers, each with its own MetaData Endpoint :

public class CoreController : ApiController { readonly EFContextProvider<CoreEntities> contextProvider = new EFContextProvider<CoreEntities>(); } public class FormsController : ApiController { readonly EFContextProvider<FormsEntities> contextProvider = new EFContextProvider<FormsEntities>(); } 

A call to ~ / Core / MetaData will return JSON for the base model, however a subsequent call to ~ / Forms / MetaData will not return Forms JSON, but kernel metadata is returned instead. If I call them in the reverse order, I get Forms metadata both times, this problem persists until the host process returns.

I can confirm that I can access object data from both models as I expected, so I doubt that this is a routing problem.

Perhaps someone will tell me if there is any kind of caching somewhere that I need to disable?

Hello,

Tom Tregenna

Answer 1

Well, that should be fixed in Breeze 0.73.4, available either via nuget or zipped on the breeze website.

Answer 2

You're right. I tested this problem and the behavior you reported happened. Putting breakpoints for each Metadata() method for two controllers and using Fiddler, I came to the conclusion that this is not a routing problem . The two controllers use a different context property ( contextProvider ), but the first metadata that was called is always returned. I assume this is a problem with the Breeze library. I read the Breeze documentation, but I did not find anything that could help.

Answer 3

There is another problem with the same symptoms. This is due to ambiguous references to the Entity Framework metadata in the connection string. I had two separate EDMX files, both of which were named Model.edmx (separate projects). When I referenced the assembly containing the second EDMX file, the connection string below became ambiguous: the metadata files from both EDMX files correspond to the description.

 metadata=res://*/Model.csdl|res://*/Model.ssdl|res://*/Model.msl; 

I managed to solve the problem by renaming one of the EDMX files.

An alternative solution would be to replace the asterisk with the full name of the assembly, which contains embedded metadata - this is actually a performance advantage. See the MSDN documentation for the Entity Framework Connection String for more information.

assemblyFullName

The fully qualified name of the assembly with the embedded resource. The name includes a simple name, a version name, a supported culture, and publicly available, as follows:

ResourceLib, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = null

Resources can be embedded in any assembly available to the application.

If you specify a wildcard character (*) for assemblyFullName, the Entity Runtime Framework will look for resources at the following locations in this order:

The calling assembly.

Related assemblies.

Assemblies in the bin directory of the application.

If the files are not located in one of these places, an exception will be thrown.

Cc716756.note (en-us, VS.100) .gif Note: When you use the wildcard character (*), the Entity Framework should look at all assemblies for resources with the correct name. To improve performance, specify an assembly instead of a wildcard.