Rick Strahl

This must be a simple thing but I can't seem to get the context to connect once I've generated a new model. The model is created and compiled. I created the model in a Classlibrary project and it added an app.config connection string.

I then use a Web app to access the model. I've added the same connection string into web.config but it continues to fail.

I'm not sure what to make of the connection string and its reference to the 3 schema files that don't exist even after compilation/generation. The error is:

The specified metadata path is not valid. A valid path must be either an existing directory, an existing file with extension '.csdl', '.ssdl', or '.msl', or a URI that identifies an embedded resource.

I tried this both through the business object (seperate project) and by directly adding the model to the Web project. In both situations it compiles and I see the objects properly but the connection fails.

Any idea what's missing

TimeTrakkerEntities.TimeTrakkerContext context = new TimeTrakkerEntities.TimeTrakkerContext();
 
 var result = from c in context.tt_customers
            where c.Company.CompareTo("G") < 0
            select c;
 
 foreach(tt_customers cust  in result)
 {
    Response.Write(cust.Company + "<br>");
 }
 
Also tried:
 
TimeTrakkerEntities.TimeTrakkerContext context = new TimeTrakkerEntities.TimeTrakkerContext("TimeTrakkerModel");
 
where the that's the key for the connection string in web.config.
 
 
 


Re: ADO.NET (Pre-release) Entity Framework Connection failing

Zlatko Michailov - MSFT

Rick,

Please post:

1. the portion of your web.config that contains the entity connection string

2. the folder structure of your web app

Thanks,

Zlatko






Re: ADO.NET (Pre-release) Entity Framework Connection failing

Julie Lerman

Rick,

While you edit the EDMX file (either in the designer or the raw code) it outputs csdl, ssdl and msl file into the debug folder.

Those are in your class library project.

The connection string has a reference to those files and a relative path. That's the metadata attribute.

So in the connection string in the web.config, you need to point directly to them.

I am trying to see how you can tell the code generator where to place the output files. But in the meantime, I moved them into c:\efmodels\ so that I can share the dll and anythig that uses them.

By defaul the connection strin glooks like this:

<add name="Entities" connectionString="metadata=.\Model.csdl|.\Model.ssdl|.\Model.msl;provider=System.Data.SqlClient;provider connection string='Data Source=.\SQLEXPRESS;AttachDbFilename=&quot;C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\AdventureWorksLT_Data.mdf&quot;;Integrated Security=True;Connect Timeout=30;User Instance=True'" providerName="System.Data.EntityClient" />

in the web site that references the dll, the connection string looks like this:

<add name="Entities"
connectionString="metadata=c:/efmodels/aw/Model.csdl|c:/efmodels/aw/Model.ssdl|c:/efmodels/aw/Model.msl;
provider=System.Data.SqlClient;
provider connection string='Data Source=.\SQLEXPRESS;AttachDbFilename=&quot;C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\AdventureWorksLT_Data.mdf&quot;;Integrated Security=True;Connect Timeout=30;User Instance=True'"
providerName="System.Data.EntityClient" />

So now I just need to be sure that whenever I modify the EDMX and it regens those files, it puts them into c:\efmodels\aw. I don't want ALL of the compiler output to go there. Hopefully this won't require an MSBuild task. It is much too common of a scenario.

In fact, rather than spending all day trying to figure that out, I'll start a new thread!





Re: ADO.NET (Pre-release) Entity Framework Connection failing

Craig Lee

The three main project systems that we support each have their own way of telling the runtime where to find the C/M/S files that are generated during build.

Windows Applications

* metadata=.\Model.csdl|.\Model.ssdl|.\Model.msl;provider=...

The '.' here is a reference to the current working directory when the Windows application is executed. This doesn't work as well for class libraries, since they are going to be loaded by some other process.

Web Applications

* metadata=~/bin/Model.csdl|~/bin/Model.ssdl|~/bin/Model.msl;provider=...

The '~' here is interpreted by the runtime as the root of the virtual directory for the web application. If you change the directory structure of the application when you deploy it, you will need to adjust this path as well. In a web application, the runtime can't use absolute paths (and there is no current working directory), so it has to use a path relative to the virtual directory root.

Web Sites

* metadata=res://*;provider=...

The web site project system builds code on the fly using Build Providers, and places these assemblies in temp folders deep in the .Net directory structure. There is no way to reliably deploy files that, you could argue, are really code (the C/M/S files) but don't actually compile into assemblies. So, for Web Sites, the C/M/S files are embedded as resources into the assembly. If you look at a web site project, the EDMX item template will add a reference to a new build provider for all EDMX files (this build provider splits the file into its three parts and then embeds them).

Because we don't know the name of the assembly that ASP.NET will build, the '*' in there tells the runtime to search through all embedded resources in all loaded modules looking for C/M/S resources.

One thing we have on our list is to add an MSBuild task (and get rid of EdmxDeploy.exe) so that you could also embed the C/M/S files as resources in a Windows or Web Application. It looks like, from your post Julie, that we should consider adding some additional nobs to this MSBuild task, giving you some control over the target directory.






Re: ADO.NET (Pre-release) Entity Framework Connection failing

Julie Lerman

I guess I got distracted and didn't start a new thread.

You make a great case for not creating EDMs inside of a website project! I hate not knowing where my stuff is.

A class project creates the CSDL the winforms way.

In a single developer solution (on one machine), it makes sense to just say that for the purposes of development, modify the config of the client project that is using the dll, pointing the metadata to whatever path the dll builds the files into. When it comes to deployment, you can put the schema files whereever you want and modify the metadata attribute in the config accordingly.

In a multi-developer environment, being able to define the target directory gets more critical. Especially if the model is getting adjusted while other developers are coding against it.

Is there a workaround to do this currently Even if it's not pretty

And yes please ... add those nobs!





Re: ADO.NET (Pre-release) Entity Framework Connection failing

Zlatko Michailov - MSFT

Julie,

You can use the |DataDirectory| macro. By default it's set by ASP.NET to the App_Data subfolder of your web app but you can override it in your .asax to point anywhere else, e.g.:

Code Snippet
AppDomain.CurrentDomain.SetData(@¡±|DataDirectory|¡±, your_local_path);

Zlatko Michailov

Program Manager, Data Programmability

Microsoft Corp.






Re: ADO.NET (Pre-release) Entity Framework Connection failing

Craig Lee

If you look in the .csproj file, the item template added a build step that calls EdmxDeploy.exe.

EdmxDeploy.exe -
Usage: EdmxDeploy input_path output_path

These are set to default to your project directory and the VS output directory, but you could change these to point to where ever you want. EdmxDeploy reads all EDMX files, in all directories starting at 'input_path' and then writes out the C/M/S files to the 'output_path' (recreating any directory structures).

EdmxDeploy.exe is only used for Windows and Web Applications and will be replaced by an MSBuild task in later releases. Web Sites use the build provider.






Re: ADO.NET (Pre-release) Entity Framework Connection failing

Rick Strahl

Thanks everybody...

I got it running by using virtual path syntax for the path pointers.

I guess I'm confused why these files are even required at runtime. Shouldn't this stuff be self contained and external Why this requirement for external files, three of them no less Seems like the default should be to embed them into the assembly that compiled the model with an *option* to store the files externally.

I suspect the idea is that you can make some adjustments to the model without recompilation How important is this really

So, based on what you said here right now there's nothing that can automatically move the generated model files from a class project to the 'deployed' location short of creating my own build task (or leaving the model alone after copying).





Re: ADO.NET (Pre-release) Entity Framework Connection failing

Julie Lerman

Rick

since this hasn't been replied to yet, I just wanted to point out that having the files separate allows loose coupling.

for example you can have your csdl defined, then a storage model and a mapping between the two.

What if you wanted to point to a different database. You can flip in a new ssdl and mapping file without having to change the csdl.

On the other hand, I guess you could also flip in a whole new edmx file, where the mapping and storage have been modified.





Re: ADO.NET (Pre-release) Entity Framework Connection failing

Cees Versteeg

Craig,

Please don't forget the test project as project to support.

Cees





Re: ADO.NET (Pre-release) Entity Framework Connection failing

Craig Lee | MSFT

Cees,

I assume that you are talking about a Visual Studio unit test project Do you have a requirement to use an Entity model in a unit test project

Thanks.






Re: ADO.NET (Pre-release) Entity Framework Connection failing

Cees Versteeg

Craig,

Your are right I am talking about VS unit test projects. I like, and with me I suppose many others, like to use unit tests.

Some of the unit tests will run against a database filled with test data. I think it is necessary to have the Entity Model available to run this kind of tests. I see no other way. Do you

Cees





Re: ADO.NET (Pre-release) Entity Framework Connection failing

Craig Lee | MSFT

I guess that you could also create a Class Library project and work on your model there and then share it with your unit test project. This would be very useful if you find yourself wanting to use the same database among multiple test projects.

Would this work for you or would you need an EDM model in the actual unit test project

I am not trying to pursuade you either way, just very interested in understanding how important these scenarios are to you.

Thanks!






Re: ADO.NET (Pre-release) Entity Framework Connection failing

Tommy Williams - MSFT

Julie Lerman has a nice blog post explaining how to share Entity Framework projects among multiple projects that might be helpful for this as well.






Re: ADO.NET (Pre-release) Entity Framework Connection failing

Cees Versteeg

Graig,

I'am not sure that I am precise enough. I mean the model metadata files. .csdl, .ssdl and .msl.

In one of your replies you say:

The three main project systems that we support each have their own way of telling the runtime where to find the C/M/S files that are generated during build.

The three project types are Windows, Web and WebSite. You explain how you will handle the metadata files for these projects. My question is how will you handle this issue for Test projects.

You suggestion to move to model (.emdx file) to a class library project is oke but that is already the case.

The point is that in many of our tests, the connection is opened in the Unit Tests which are part of the test project. Therefore we need to know the path to the c/m/s files. Where will they be

Is this a real issue At least for our way of working. But I think I is common to open the connection in the unit test for database oriented tests.

Cees