using migrate.exe from powershell script - entity-framework

As part of my continuous integration flow I need to apply the latest migration generated by EntityFramework to a database.
After some research I learned I can use the following script to accomplish that.
#copy migrate.exe to path\to\project\binfolder
Copy-Item packages\EntityFramework*\tools\migrate.exe path\to\project\binFolder
#apply latest migration
path\to\project\binFolder\migrate.exe pathto\projectGenerated.dll /startupConfigurationFile = "pathTo\Web.config"
I am saving this in a file and using power shell to run it.
I have two connection strings inside the web.config file like the following
<connectionStrings>
<add name="firstConnName" connectionString="connectionstring" providerName="System.Data.SqlClient" />
<add name="secondConnName" connectionString="connectionstring" providerName="System.Data.SqlClient" />
And in code I have the following so that entity framework uses secondConnName
public partial class myContext : DbContext
{
static myContext()
{
Database.SetInitializer<repreeContext>(null);
}
public myContext()
: base("Name=secondConnName")
{
Configuration.ProxyCreationEnabled = false;
}
...
I ran the powershell script above and this is the error i am getting
System.Data.Entity.Migrations.Design.ToolingException: No connection string named 'secondConnName' could be fo
und in the application config file.
at System.Data.Entity.Migrations.Design.ToolingFacade.Run(BaseRunner runner)
at System.Data.Entity.Migrations.Design.ToolingFacade.Update(String targetMigration, Boolean force)
at System.Data.Entity.Migrations.Console.Program.Run()
at System.Data.Entity.Migrations.Console.Program.Main(String[] args)
ERROR: No connection string named 'secondConnName' could be found in the
application config file.
Using EntityFramework 5.0, and Powershell 4.0
Any idea where I went wrong?
Thanks for the help

Related

Migrations Different Assembly

I have the following structure.
MyOrg.Api (AspNet Core Web App)
MoOrg.DataAccess (Containing the DbContext)
I want the Migrations live in the DataAccess Assembly.
Ive tried almost every combination of configuration but cant get it work probably.
MyOrg.Api (Startup.cs)
public void ConfigureServices(IServiceCollection services)
{
// default stuff..
services.AddDbContext<MyOrg.DataAccess.MyDatabaseContext>(options =>
{
options.UseSqlite("Filename=./myDbContext.db", b => b.MigrationsAssembly("MyOrg.DataAccess"));
});
}
MyOrg.DataAccess
public class MyDatabaseContext : DbContext
{
public DbSet<Something> Somethings { get; set; }
public MyDatabaseContext(DbContextOptions<MyDatabaseContext> options) : base(options)
{
}
}
How to do it right?
In your MyOrg.DataAccess, create a new class MigrationDbContext deriving from MyDatabaseContext with and OnConfiguring method override :
public class MigrationDbContext: MyDatabaseContext
{
public MigrationDbContext()
{
}
protected override void OnConfiguring(DbContextOptionsBuilder options)
{
options.UseSqlite("Filename=./myDbContext.db");
base.OnConfiguring(options);
}
}
Since .Net Core 2.1 you don't need to add a reference to Microsoft.EntityFrameworkCore.Tools, dotnet ef is a global tool.
If you use .Net Core 2.0 or above, add the Microsoft.EntityFrameworkCore.Tools.DotNet as a DotNetCliToolReference to your MyOrg.DataAccess project :
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet"
Version="1.1.6" />
</ItemGroup>
Then go to your MyOrg.DataAccess project directory using a command prompt and run :
dotnet ef --startup-project ../MyOrg.Api/ migrations add Initial -c MigationDbContext
to create an initial migration named Initial (I assume ../MyOrg.Api/ is the relative path to your startup project)
To update your database run:
dotnet ef --startup-project ../MyOrg.Api/ database update
For more information read the doc Entity Framework Core tools reference - .NET CLI
I've managed to get it working as follows (whilst also adhering to Onion Architecture):
Create a class library 'App.Core'
Add a 'Country' domain model to this library:
public class Country
{
public int Id { get; set; }
public string Name { get; set; }
}
This is just a simple class to get things working quickly
Create a class library 'App.Infrastructure'
Add a DbContext to this library:
public class AppDbContext : DbContext
{
public DbSet<Country> Countries { get; set; }
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
optionsBuilder.UseSqlServer(#"Server=localhost;Database=App;Trusted_Connection=True;",
x => x.MigrationsAssembly("App.Migrations"));
}
}
'App.Migrations' will be our separate class library just for migrations
'App.Infrastructure' needs to reference 'Microsoft.EntityFrameworkCore.SqlServer' and 'Microsoft.EntityFrameworkCore.Tools'
Run dotnet ef migrations add InitialCreate
Do this from the command line in the 'App.Infrastructure' directory
This will create a 'Migrations' folder in your 'App.Infrastructure' class library with a migration called 'InitialCreate'
Create a class library 'App.Migrations'
Move the 'Migrations' folder from 'App.Infrastructure' to 'App.Migrations' - you will need to update the namespaces after the move
Add a project reference in 'App.Migrations' to 'App.Infrastructure'
Edit the .csproj file for 'App.Migrations' and add an output path:
netcoreapp2.1
App.Infrastructure\bin\$(Configuration)\
The above path will be correct if 'App.Infrastructure' and 'App.Migrations' are in the same directory, if not, the output path will need to be adjusted
On build this results in 'App.Migrations' being output to the 'App.Infrastructure' bin directory - we need to do this as we can't reference 'App.Migrations' in 'App.Infrastructure' as this results in a circular reference, so this is a workaround
Build the solution
Run dotnet ef database update from the command line in the 'App.Infrastructure' directory and this should create the database and create the 'Countries' table
Run dotnet ef migrations add AddCity --project App.Migrations for your next migration
'AddCity' is just another migration to create a 'Cities' table - this requires adding a 'City' class and updating the DbContext
Run the command from the 'App.Infrastructure' directory and the migration will be added to the 'App.Migrations' class library
Remember to rebuild the solution every time a migration is added

ConfigurationType error when using Entity Framework migrate.exe with multiple migration configurations

In my solution, I have a Data project that contains multiple Entity Framework 6.1.3 migration configuration classes. My goal is to run Entity Framework migration steps - for one of them, against an existing database - from TeamCity (or, to simplify, from a command line).
The migration configuration class I am using is the following:
namespace MyProject.Data
{
public partial class MyCustomMigrationConfiguration :
DbMigrationsConfiguration<MyCustomContext>
{
public MyCustomMigrationConfiguration()
{
AutomaticMigrationsEnabled = false;
AutomaticMigrationDataLossAllowed = true;
MigrationsDirectory = #"Migrations\MyCustomContext\MigrationSteps";
}
}
}
I can successfully run the following command from Package Manager Console in Visual Studio:
Update-Database -Verbose -StartUpProject Web -ConnectionString '-my
connection string here-' -ConfigurationTypeName
MyCustomMigrationConfiguration -ConnectionProviderName
'System.Data.SqlClient'
I want to do the same thing from a command line, so I run this:
migrate.exe MyProject.Data.dll "MyCustomMigrationConfiguration"
/startUpConfigurationFile=MyProject.Web.dll.config
/connectionString="-my connection string here-;"
/connectionProviderName="System.Data.SqlClient" /verbose
However, I get the following error:
ERROR: The migrations configuration type
MyCustomMigrationConfiguration was not be found in the assembly
‘MyProject.Data'.
Any suggestions on how to fix this, please?
You can specify the directory where are all the dependencies (assemblies) needed to run your code. You can do that by using the /startUpDirectory option, as explained here:
Specify working directory
Migrate.exe MyApp.exe /startupConfigurationFile=”MyApp.exe.config” /startupDirectory=”c:\MyApp”
If you assembly has dependencies or reads files relative to the working directory then you will need to set startupDirectory.
Found the solution (I ended up downloading the Entity Framework source code from http://entityframework.codeplex.com/ and debugging the migrate console application).
Apparently, all the dependencies of MyProject.Data.dll need to be copied in the same folder with it and migrate.exe, otherwise the Entity Framework migrate.exe tool will throw the misleading error message above.
Entity Framework could really use better error handling and a clearer error message in this case.
As a reference to Entity Framework devs: the following code in TypeFinder.cs was returning a null type because the dependencies of MyProject.Data.dll were not copied in the folder of migrate.exe:
type = _assembly.GetType(typeName, false);

Migrations after switching from EDMX to Code First throws MetadataException

I'm changing a project from using an EDMX file to Code First. The project is one of a few projects in a solution, and it only contains the entities and the DbContext class.
This is what I've done so far:
Removed the old project from the solution (but not deleted it just yet, just renamed the folder).
Added a new class library project to the solution, and given it the same name as the old one.
Used NuGet to add Entity Framework to the new project.
Copied all the entity classes that were generated by the old EDMX file to the new project and included them all.
Copied the DbContext class as well.
Modified the app.config file to change the connection string to a standard connection string without the metadata stuff.
Added a reference to all the other projects that uses to use the old project.
Everything looks good and it compiles with no errors, but when I try to enable-migrations it throws this error:
PM> enable-migrations
Checking if the context targets an existing database...
System.Data.Entity.Core.MetadataException: Unable to load the specified metadata resource.
at System.Data.Entity.Core.Metadata.Edm.MetadataArtifactLoaderCompositeResource.LoadResources(String assemblyName, String resourceName, ICollection`1 uriRegistry, MetadataArtifactAssemblyResolver resolver)
at System.Data.Entity.Core.Metadata.Edm.MetadataArtifactLoaderCompositeResource.CreateResourceLoader(String path, ExtensionCheck extensionCheck, String validExtension, ICollection`1 uriRegistry, MetadataArtifactAssemblyResolver resolver)
at System.Data.Entity.Core.Metadata.Edm.MetadataArtifactLoader.Create(String path, ExtensionCheck extensionCheck, String validExtension, ICollection`1 uriRegistry, MetadataArtifactAssemblyResolver resolver)
at System.Data.Entity.Core.Metadata.Edm.MetadataCache.SplitPaths(String paths)
at System.Data.Entity.Core.Common.Utils.Memoizer`2.<>c__DisplayClass2.<Evaluate>b__0()
at System.Data.Entity.Core.Common.Utils.Memoizer`2.Result.GetValue()
at System.Data.Entity.Core.Common.Utils.Memoizer`2.Evaluate(TArg arg)
at System.Data.Entity.Core.Metadata.Edm.MetadataCache.GetArtifactLoader(DbConnectionOptions effectiveConnectionOptions)
at System.Data.Entity.Core.Metadata.Edm.MetadataCache.GetMetadataWorkspace(DbConnectionOptions effectiveConnectionOptions)
at System.Data.Entity.Core.EntityClient.EntityConnection.GetMetadataWorkspace()
at System.Data.Entity.Core.Objects.ObjectContext.RetrieveMetadataWorkspaceFromConnection()
at System.Data.Entity.Core.Objects.ObjectContext..ctor(EntityConnection connection, Boolean isConnectionConstructor, ObjectQueryExecutionPlanFactory objectQueryExecutionPlanFactory, Translator translator, ColumnMapFactory columnMapFactory)
at System.Data.Entity.Internal.InternalConnection.CreateObjectContextFromConnectionModel()
at System.Data.Entity.Internal.LazyInternalConnection.CreateObjectContextFromConnectionModel()
at System.Data.Entity.Internal.LazyInternalContext.InitializeContext()
at System.Data.Entity.Internal.LazyInternalContext.get_ModelBeingInitialized()
at System.Data.Entity.Infrastructure.EdmxWriter.WriteEdmx(DbContext context, XmlWriter writer)
at System.Data.Entity.Utilities.DbContextExtensions.<>c__DisplayClass1.<GetModel>b__0(XmlWriter w)
at System.Data.Entity.Utilities.DbContextExtensions.GetModel(Action`1 writeXml)
at System.Data.Entity.Utilities.DbContextExtensions.GetModel(DbContext context)
at System.Data.Entity.Migrations.DbMigrator..ctor(DbMigrationsConfiguration configuration, DbContext usersContext, DatabaseExistenceState existenceState, Boolean calledByCreateDatabase)
at System.Data.Entity.Migrations.DbMigrator..ctor(DbMigrationsConfiguration configuration)
at System.Data.Entity.Migrations.Design.MigrationScaffolder..ctor(DbMigrationsConfiguration migrationsConfiguration)
at System.Data.Entity.Migrations.Design.ToolingFacade.ScaffoldRunner.Run()
at System.AppDomain.DoCallBack(CrossAppDomainDelegate callBackDelegate)
at System.AppDomain.DoCallBack(CrossAppDomainDelegate callBackDelegate)
at System.Data.Entity.Migrations.Design.ToolingFacade.Run(BaseRunner runner)
at System.Data.Entity.Migrations.Design.ToolingFacade.ScaffoldInitialCreate(String language, String rootNamespace)
at System.Data.Entity.Migrations.EnableMigrationsCommand.<>c__DisplayClass2.<.ctor>b__0()
at System.Data.Entity.Migrations.MigrationsDomainCommand.Execute(Action command)
Unable to load the specified metadata resource.
It looks like it still thinks I'm using an EDMX. I also get this error when I try to run the application.
What am I missing?
You have to change the connection string of the starter project (asp.net or winforms project).

EF Migrations migrate.exe generate script

I'm playing around with Entity framework and continuous builds. So far i'm able to run a migration or series of migrations without any problem by using migrate.exe and the appropriate arguments.
However, i've hit trouble when trying to get migrate.exe to kick out a script, rather than perform the migration, in the same way as I could get by running
update-database -TargetMigration TestMigration -script
from within Package Manager Console in Visual Studio.
Is there currently a way to do this?
Thanks.
Since the 10/22/2017 you can do it thanks to this PR:
https://github.com/aspnet/EntityFramework6/commit/02ec6b8c9279f93f80eeed1234e5ce0acfce5f31
Here the Entity Framework 6.2 release notes that implements this functionality (see 'Migrate.exe should support -script option' section):
https://blogs.msdn.microsoft.com/dotnet/2017/10/26/entity-framework-6-2-runtime-released/
Follow those steps:
Copy the file migrate.exe from the '\packages\EntityFramework.6.2.0\tools' to the target 'bin' folder (for example on the production server) after that you deployed the new assembly that contains the new migrations
Open the command line in the folder and launch this command:
migrate.exe yourMigrationAssembly.dll
/startupConfigurationFile=”..\web.config”
/scriptFile="migrationOutput.sql"
It will generate the the file "migrationOutput.sql" that contains the SQL you have to execute on your target environment DB based on the migrations that are not yet applied on it.
It is currently not supported. Please add your vote to the issue: Migrations: -Script for Migrate.exe
I encountered the same problem and indeed the option is available in the package manager console in Visual Studio. So I opened up the powershell script and the entity framework dll and built a small executable so you can generate the scripts from command line.The source code is available as-is and without any warranty here;
EF6
EF5
You can write a simple c# console application or use something like Linqpad to generate the script using the Entity Framework Infrastructure objects. You will just need to load the DLL with your DbMigrationsConfiguration class and instantiate it. Here is the code similar to what is working for me:
using System.Data.Entity.Infrastructure;
using System.Data.Entity.Migrations;
using System.Data.Entity.Migrations.Infrastructure;
const string ScriptFile = "Migration.sql";
const string ConnectionString = #"Server=.\SqlExpress;Database=...;Trusted_Connection=True;";
const bool AutomaticMigrationDataLossAllowed = false;
var targetDb = new DbConnectionInfo(ConnectionString, "System.Data.SqlClient");
var config = new MyDbMigrationsConfiguration
{
AutomaticMigrationDataLossAllowed = AutomaticMigrationDataLossAllowed,
TargetDatabase = targetDb,
};
var migrator = new DbMigrator(config);
var scripter = new MigratorScriptingDecorator(migrator);
var script = scripter.ScriptUpdate(null, null);
File.WriteAllText(ScriptFile, script);
Console.WriteLine("Migration Script Generated: " + ScriptFile);

Subsonic Access To App.Config Connection Strings From Referenced DLL in Powershell Script

I've got a DLL that contains Subsonic-generated and augmented code to access a data model. Actually, it is a merged DLL of that original assembly, Subsonic itself and a few other referenced DLL's into a single assembly, called "PowershellDataAccess.dll. However, it should be noted that I've also tried this referencing each assembly individually in the script as well and that doesn't work either.
I am then attempting to use the objects and methods in that assembly. In this case, I'm accessing a class that uses Subsonic to load a bunch of records and creates a Lucene index from those records.
The problem I'm running into is that the call into the Subsonic method to retrieve data from the database says it can't find the connection string. I'm pointing the AppDomain at the appropriate config file which does contain that connection string, by name.
Here's the script.
$ScriptDir = Get-Location
[System.IO.Directory]::SetCurrentDirectory($ScriptDir)
[Reflection.Assembly]::LoadFrom("PowershellDataAccess.dll")
[System.AppDomain]::CurrentDomain.SetData("APP_CONFIG_FILE", "$ScriptDir\App.config")
$indexer = New-Object LuceneIndexingEngine.LuceneIndexGenerator
$indexer.GeneratePageTemplateIndex("PageTemplateIndex");
I went digging into Subsonic itself and the following line in Subsonic is what's looking for the connection string and throwing the exception:
ConfigurationManager.ConnectionStrings[connectionStringName]
So, out of curiosity, I created an assembly with a single class that has a single property that just runs that one line to retrieve the connection string name.
I created a ps1 that called that assembly and hit that property. That prototype can find the connection string just fine.
Anyone have any idea why Subsonic's portion can't seem to see the connection strings?
Did you add the System.Configuration assembly to your PowerShell session? The following works for me:
PS> gc .\app.config
<?xml version='1.0' encoding='utf-8'?>
<configuration>
<connectionStrings>
<clear />
<add name="Name"
providerName="System.Data.ProviderName"
connectionString="Valid Connection String;" />
</connectionStrings>
</configuration>
PS> [appdomain]::CurrentDomain.SetData("APP_CONFIG_FILE", "$home\app.config")
PS> Add-Type -AssemblyName System.Configuration
PS> [Configuration.ConfigurationManager]::ConnectionStrings['Name']
Name : Name
ConnectionString : Valid Connection String;
...