Entity Framework Code First DbContext Checks the ConnectionString During Compile?

Question

It seems that the Code First DbContext really uses the given ConnectionString during compile? I don't even know how that is possible but to me it seems to be so. If I turn OFF my local SQL Server, I get the error stating "Failed to get the MetadataWorkspace for the DbContext type...". Turning the SQL Server ON, everything compiles fine.

Here's part of my context (I'm using an existing database and yes, I know, not actually code first)

public class MyContext : DbContext
{
    public MyContext() : base("MY_DYNAMIC_CONNECTIONSTRING")
    {
        Database.SetInitializer<MyContext>(null);
    }
    ...

If this is really the case, there's a huge problem. How can I prevent it from doing that? What if I'm using separate build machines where the ConnectionString doesn't work? Or am I doing something wrong? Any advice?

Is this in a WCF RIA services project? I see this error mentioned only in the context of RIA services+EF4.1. I think it doesn't occur in a "pure" EF 4.1 project. I had just shut down my SQL Server and I can still compile an EF 4.1 console project. Nonetheless it would interest me too what's going on. — Slauma, Sep 29 '11 at 14:19

score 6 · Accepted Answer · answered Sep 29 '11 at 15:19

6

WCF RIA Services instantiates a DbContext at design time and build time, not only at runtime:

Quote from http://jeffhandley.com/archive/2011/06/30/RIAServicesCodeFirst.aspx:

In order to generate code into your Silverlight project, RIA Services has to inspect your DbContext at build time in order to get the entity types that are available.

Quote from http://varunpuranik.wordpress.com/2011/06/29/wcf-ria-services-support-for-ef-4-1-and-ef-code-first/#comment-102

The difference between EF CodeFirst stand alone and with RIA Services is that we initialize a new DbContext at design time as well.

If the connection string is not valid or the connection can't be established you apparently get the exception you mentioned.

answered Sep 29 '11 at 15:19

Slauma

175,098
59
401
420

2

to add to Slauma's answer, you'll need to set the initializer somewhere that RIA will detect it at design time. (I haven't tangled with CF + RIA yet.) What about putting it in the connection string? http://blog.oneunicorn.com/2011/03/31/configuring-database-initializers-in-a-config-file/ – Julie Lerman Sep 29 '11 at 15:47
@Julie: Oh, I didn't know that setting the initializer in config is possible at all. Good to know. If it fixes the problem you must convert your comment to an answer. But I'm wondering: If RIA calls any constructor at design time to instantiate the derived context, shouldn't it be the *default* constructor which - as shown in the question - would set the initializer to `null`? It's weird that RIA still tries to connect to the database. – Slauma Sep 29 '11 at 16:23
Ok, lots of good info here. If you've looked up Jeff Handleys blog post, you can see that he has set the initializer to null when HttpContext is null to prevent RIA Service to initialize the context. I've done that too so RIA shouldn't initialize it? Maybe you can't affect the build-time initialization? – Antti Simonen Sep 29 '11 at 17:18
@Antti: I don't know. In the comments of both blog posts people complain a lot about the same problem but I can't really find a solution in those comments. Somewhere below the comment in my second link it is proposed to download and use RIA SP2 and claimed that this would fix the problem. But I can't see anyone confirming this. Did you try Julie's idea to set the initializer in config to `null`? – Slauma Sep 29 '11 at 17:51
As far as I know you cannot set the initializer to null in config? – Antti Simonen Sep 30 '11 at 09:59
@Antti: It seems that you can: see the very last code snippet (before "Summary") in the article linked in Julie's comment above. – Slauma Sep 30 '11 at 10:46
Couldn't make it work. Setting the initializer to null in config didn't make any difference. – Antti Simonen Sep 30 '11 at 11:49
1

Varun also stated that this might not be doable (http://varunpuranik.wordpress.com/2011/06/29/wcf-ria-services-support-for-ef-4-1-and-ef-code-first/#comment-122). I also tried it with WCF RIA Services SP2 bits without success. Conclusion was that building EF Code First + RIA Services -projects, you need a working DB during build time. – Antti Simonen Oct 05 '11 at 06:29

score 1 · Answer 2 · answered Nov 09 '11 at 20:33

1

Here is the way that I use to track down the root cause of the "Failed to get the MetadataWorkspace for the DbContext type '{type}'" error:

http://joshmouch.wordpress.com/2011/11/09/failed-to-get-the-metadataworkspace-for-the-dbcontext-type-type/

I know it doesn't specifically answer your question, but it could help others who search Google for this error message.

answered Nov 09 '11 at 20:33

Josh Mouch

3,480
1
37
34

Thanks for the tip! I'm sure that will come in handy in the future. At the moment I've abandoned the CodeFirst approach and waiting for vNext to see if things have improved. – Antti Simonen Nov 16 '11 at 11:23
Good choice. I regret even trying CodeFirst in its current version. For simple things it's fine, but start getting into scenarios beyond the given samples and you're asking for trouble. – Josh Mouch Jun 14 '12 at 12:46

Entity Framework Code First DbContext Checks the ConnectionString During Compile?

2 Answers2