Can EF Code First work with LocalDB in a ClickOnce application? -

so, i'm trying out ef code first, can have code drive updates database. i'm working on clickonce app using localdb, figured may best solution me, since otherwise changes mdf file cause overwritten on client when deployed, losing entered before.

however, i'm having fair share of new problems around code first migrations. i've followed through code first migrations on msdn, , i've managed initial configuration created, initial database creation.

the problems begin when try make first actual migration. added 1 single field 1 of models, , tried make explicit migration handle schema change next time publish. well...

pm> add-migration addispercentfield

unable generate explicit migration because following explicit migrations pending: [201601052011180_initialcreate]. apply pending explicit migrations before attempting generate new explicit migration.

ok... i'll run update , try again:

pm> update-database

specify '-verbose' flag view sql statements being applied target database.
applying explicit migrations: [201601052011180_initialcreate].
applying explicit migration: 201601052011180_initialcreate.
unable update database match current model because there pending changes , automatic migration disabled. either write pending model changes code-based migration or enable automatic migration. set dbmigrationsconfiguration.automaticmigrationsenabled true enable automatic migration.
can use add-migration command write pending model changes code-based migration.

pm> add-migration addispercentfield

unable generate explicit migration because following explicit migrations pending: [201601052011180_initialcreate]. apply pending explicit migrations before attempting generate new explicit migration.

that's familiar, that's error (blatant lie?) told me earlier. well, maybe if undo changes , update again, move valid state:

pm> update-database

specify '-verbose' flag view sql statements being applied target database.
applying explicit migrations: [201601052011180_initialcreate].
applying explicit migration: 201601052011180_initialcreate.
running seed method.

ok, no warning time. should golden. field added back, project rebuilt. here go:

pm> add-migration addispercentfield

unable generate explicit migration because following explicit migrations pending: [201601052011180_initialcreate]. apply pending explicit migrations before attempting generate new explicit migration.

so... there actually working way generate explicit migrations changes beyond first?

edit: made forward progress on this, believe. did notice __migrationhistory table not generated in .mdf after running update-database, though said completed fine. believe issue around how local database works within application. connection string references attachdbfilename=|datadirectory|. think going on is deploying .mdf temporarily, updating temporary deployment, not committing changes.

i'm working on solution have in mind, have migrations work against copy of blank .mdf put in static location, static .mdf used track , determine changes, while blank .mdf goes out clients deployment.

i found root of problem console commands not able make changes, track migrations, data file. due connection string data file referencing deployed location, file being updated merely temporary.

this in part thing, because whole point of using code first migrations in project avoid hash signature change .mdf (which should have remained blank, placeholder) when publishing, data previous versions never overridden , discarded. however, introduced obvious (in retrospect) problem ef not track changes due there never being __migrationhistory table.

the solution upon arrived have 2 .mdf files. blank one, deployments, , second one, interact code first migrations. so, have initial mydata.mdf of build action content, , second mydatadesigntime.mdf of build action none. (the "design time" migration database shouldn't deployed.)

using approach, found work migrations, calling update-database , add-migration, making sure pass -connectionstring parameter attachdbfilename pointed full path design time database.

later, getting lazy supply long -connectionstring parameter on every migration command, added design time path config connection strings, , updated dbcontext uses design time path initially, change @ beginning of run-time use actual target data file:

public partial class mydata : dbcontext {     public const string designtimeconnection = "mydataconnectionstringdesigntime";      public static string connectionname { get; set; } = designtimeconnection;      public mydata()         : base("name=" + connectionname)     {     }      ... } 

and @ application initialization:

mydata.connectionname = "mydataconnectionstring"; 

this works, , makes things simpler on me. however, 1 minor issue i'm left have full static path applies environment left in app.config file. not issue, i'm dev on project, it's code smell i'm not happy with. there path variable can use, such still points actual design time data (not temporary, deployed file), relative active, open project?