locked
Use Entity Framework via SVN, how to get .edmx file mapped automatically? RRS feed

  • Question

  • So what happen is that I created a EF model using a database on my local machine. I then commit my whole solution to source control and my colleague suppose to pick it up to work on it using her own local database, which is exactly the same as the one that I used to create the EF model. Now what happen is when she try to use it, the .edmx says that all the entity type is not mapped. I thought it suppose to map it automatically since the database is the same on both machine?
    • Moved by CoolDadTx Monday, September 8, 2014 5:25 PM EF related
    Monday, September 8, 2014 2:25 PM

Answers

  • This one doesnt work for me. I end up using this:

    context.Database.Connection.ConnectionString = connectionString;

    • Marked as answer by Fred Bao Monday, September 22, 2014 7:50 AM
    Tuesday, September 16, 2014 6:47 PM

All replies

  • You need the same connection string to work as well as database name etc.

    If  one of you decided to name their instance of sql server then that'll cause a problem.

    It's a bad idea to develop against a local database on each developer's machine.

    If you both map to the same one on a server then when someone changes it you know immediately you need to sort it out.


    Hope that helps
    Please don't forget to up vote answers you like or which help you and mark one(s) which answer your question.



    • Edited by Andy ONeill Monday, September 8, 2014 3:05 PM
    Monday, September 8, 2014 3:01 PM
  • So what do you suggest? What we want is that we can work on the the localhost then later on, migrate the database to a server. ultimately, it should be possible to let us modify the data source, password and user id as people doesnt want to use the same account.
    Monday, September 8, 2014 3:07 PM
  • Well in the short term you want to check what you both called your sql server instances, because that's the simplest answer.

    If the connection string will work then maybe your two databases are already out of sync.

    Personally I would always work with a dev database on a server.

    You're just asking for database versioning issues otherwise.

    I would also recommend database first rather than code first.

    It's faster and you get horrible designs very easily with code first.


    Hope that helps
    Please don't forget to up vote answers you like or which help you and mark one(s) which answer your question.

    Monday, September 8, 2014 3:13 PM
  • I am using database first. We got the database set up already. Just generate EF from the database after we import the dump into our localhost. We use Oracle btw
    Monday, September 8, 2014 3:14 PM
  • I've never used oracle on the localhost but I think you can name instances like sql server.

    I'm not that great at Oracle as I only occasionally use it.

    Thing to do is to test your connection string on his computer.
    Does it work or does it not?


    Hope that helps
    Please don't forget to up vote answers you like or which help you and mark one(s) which answer your question.

    Monday, September 8, 2014 3:48 PM
  • After changing the specific machine name to localhost in the connectionstring in the app.config file, it run fine now. But I have one more question though. Since we both run the database on localhost, it is ok to call data source: localhost.XE (XE stand for oracle express edition). But say when we use the actual database on a server, what can we do in this situation? I know that you can modify the connection string and parse in username, datasource, password and the like, would it work when I migrate the db somewhere else?
    Monday, September 8, 2014 4:15 PM
  • So what happen is that I created a EF model using a database on my local machine. I then commit my whole solution to source control and my colleague suppose to pick it up to work on it using her own local database, which is exactly the same as the one that I used to create the EF model. Now what happen is when she try to use it, the .edmx says that all the entity type is not mapped. I thought it suppose to map it automatically since the database is the same on both machine?

    Well, you have to keep everything in sync with the EDMX, database and the connectionstring. We had 5 developers with local copies of the MS Server Database using SQL Server Express on each machine. The solution also had a MS Server project in the solution too.  We never had a problem with anything getting out of sync.

    Monday, September 8, 2014 9:51 PM
  • I am using database first. We got the database set up already. Just generate EF from the database after we import the dump into our localhost. We use Oracle btw

    Oh, you are using the Oracle nightmare. I am using that complicated crap at work now really for the first-time with using SQL Plus, PL-SQL Developer and got the 1,000 page PL-SQL Developer book for 12c. Yeah that Oracle is a real piece of work. <pfft>

    Monday, September 8, 2014 9:59 PM
  • You could stick your connection strings in a file and switch them as you like.

    That way you can easily point to local, dev, test etc by just copying one xml file.

    EF is built on ADO so there's a connection being made there.

    http://social.msdn.microsoft.com/Forums/en-US/d2ab9b40-c2bc-4829-8db0-4666390b17ed/connectionstring-in-dbcontext-constructor?forum=adodotnetentityframework

    public partial class DistributionEntities: DbContext
    
        {
    
            public DistributionEntities(string connectionString)
    
                : base(connectionString)
    
            {
    
            }
    
        }
    Pass in your string when you new up the dbcontext.


    Hope that helps
    Please don't forget to up vote answers you like or which help you and mark one(s) which answer your question.

    Tuesday, September 9, 2014 7:41 AM
  • Exactly, and EF distinct() function wouldn't work with oracle 11c or lower cause Oracle doesn't use APPLY. We don't have the luxury to upgrade the database, so I went ahead and make a view there... -_- (this is a different issue but was resolved) :)
    Tuesday, September 16, 2014 6:31 PM
  • This one doesnt work for me. I end up using this:

    context.Database.Connection.ConnectionString = connectionString;

    • Marked as answer by Fred Bao Monday, September 22, 2014 7:50 AM
    Tuesday, September 16, 2014 6:47 PM