I am building a project in VS 2015 and I am trying to enable-migrations to create a database using Entity Framework, but I am getting an error:
Cannot determine a valid start-up project. Using project 'Data
Manager' instead. Your configuration file and working directory may
not be set as expected. Use the -StartUpProjectName parameter to set
one explicitly. Use the -Verbose switch for more information. No
context type was found in the assembly 'Data Manager'.
I found several threads and potential solutions, but no luck. So far I have tried:
Rebuilding the Solution and Resetting VS
I confirmed that the default project is set to 'DataManager' with
both a 'nuget.org' and 'All' package source
Enable-Migrations -ProjectName DataManager
I reinstalled with the commmand: Install-Package EntityFramework
-IncludePrerelease
What am I missing?
It seems you don't have a context class on your Data Manager project.You have to specify it as shown below.
namespace MigrationsAutomaticDemo
{
public class YourContext : DbContext
{
public DbSet<Blog> Blogs { get; set; }
}
public class Blog
{
public int BlogId { get; set; }
public string Name { get; set; }
}
}
Hope it will work after that.
You can read more about it here : Automatic Code First Migrations
Related
I have some data in my database in a table called "Test".
I've made a duplicate of that table called "CopyTest".
If i change:
modelBuilder.Entity<IISLog>()
.ToTable("Test");
to:
modelBuilder.Entity<IISLog>()
.ToTable("CopyTest");
I get an error saying:
context has changed since the database was created. Consider using
Code First Migrations to update the database
How can i stop this from showing? It's just a table name change :)
Solution 1:
Delete First Migration and than try:
Add-Migration <migration-name>
Then open Migration file and change Table Name Manually. After that:
update-database -verbose
If it not works.
Solution 2:
Try to delete Migration History from SQL server Management studio .
Reference URL - Resetting Entity Framework Migrations to a clean Slate
Migrate to the initial DB
with
Update-Database -TargetMigration:"name_of_migration"
then update to your current state:
Update-Database
if necessary add your migration again:
Add-Migration TableNameUpdate
Add a new migration using add-migration Rename_Test_To_CopyTest
Then, in the resulting file, use the RenameTable method:
public partial class Rename_Test_To_CopyTest : DbMigration
{
public override void Up()
{
RenameTable("dbo.Test", "dbo.CopyTest");
}
public override void Down()
{
RenameTable("dbo.CopyTest", "dbo.Test");
}
}
Then use update-database as usual.
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
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);
If you have the following:
[TestFixture]
public class SuccessTests
{
[Test]
[Category("Long")]
public void VeryLongTest()
{ /* ... */ }
}
How can you - from within VS Test Explorer, or as part of a build config - run only those tests marked as belonging to the "Long" category?
In your build, you can run the nunit console runner:
nunit-console.exe TestAssembly.dll /include:Long
More here: http://www.nunit.org/index.php?p=consoleCommandLine&r=2.2
Summary
I currently have a NAnt build script that performs a vssget on either the latest source code, or a specific branch (using a ${branch} parameter).
Whenever we do a production build/deployment the code-tree that was built has a branch created, (so that we can continue development and still know what codebase is on production, pretty standard stuff...)
Problem
The process of creation of that branch is still a manual one, performed by someone going into Visual Source Safe Explorer and performing the branching procedure. I was wondering if there is any way in NAnt of creating a VSS branch.
Current Plan
I already know about using <exec program="ss"> and am trying to avoid that, but in the absence of any better solutions, that is the most probable route I will take.
Does anyone know if there is a NAnt or NAntContrib target for this, or if anyone has a script task that they have used to do this in the past and could provide the code for that, that would be very much appreciated.
Disclaimer
I know about cvs, svn, git and all the other Source Control solutions, and to change the tool is not an option at present
We actually need this where I work. I whipped together a small task called 'vssbranch' (not particularly creative but here is the code...an example build file and the output of its execution:
CODE:
using System;
using System.Collections.Generic;
using System.IO;
using System.Text;
using SourceSafeTypeLib;
using NAnt.Core;
using NAnt.Core.Attributes;
namespace NAnt.Contrib.Tasks.SourceSafe
{
[TaskName("vssbranch")]
public sealed class BranchTask : BaseTask
{
/// <summary>
/// The label comment.
/// </summary>
[TaskAttribute("comment")]
public String Comment { get; set; }
/// <summary>
/// Determines whether to perform the branch recursively.
/// The default is <see langword="true"/>
/// </summary>
[TaskAttribute("recursive"),
BooleanValidator()]
public Boolean Recursive { get; set; }
[TaskAttribute("branchname", Required = true)]
public String BranchName { get; set; }
protected override void ExecuteTask()
{
this.Open();
try
{
if (VSSItemType.VSSITEM_PROJECT != (VSSItemType)this.Item.Type)
throw new BuildException("Only vss projects can be branched", this.Location);
IVSSItem newShare = null;
this.Comment = String.IsNullOrEmpty(this.Comment) ? String.Empty : this.Comment;
if (null != this.Item.Parent)
newShare = this.Item.Parent.NewSubproject(this.BranchName, this.Comment);
if (null != newShare)
{
newShare.Share(this.Item as VSSItem, this.Comment,
(this.Recursive) ?
(int)VSSFlags.VSSFLAG_RECURSYES : 0);
foreach (IVSSItem item in newShare.get_Items(false))
this.BranchItem(item, this.Recursive);
}
}
catch (Exception ex)
{
throw new BuildException(String.Format("Failed to branch '{0}' to '{1}'", this.Item.Name, this.BranchName), this.Location, ex);
}
}
private void BranchItem(IVSSItem itemToBranch, Boolean recursive)
{
if (null == itemToBranch) return;
if (this.Verbose)
this.Log(Level.Info, String.Format("Branching {0} path: {1}", itemToBranch.Name, itemToBranch.Spec));
if (VSSItemType.VSSITEM_FILE == (VSSItemType)itemToBranch.Type)
itemToBranch.Branch(this.Comment, 0);
else if (recursive)
{
foreach (IVSSItem item in itemToBranch.get_Items(false))
this.BranchItem(item, recursive);
}
}
}
}
BUILD FILE:
<echo message="About to execute: VSS Branch" />
<echo message="Source Safe Path: ${SourceSafeRootPath}/${CURRENT_FILE}" />
<vssbranch
username="my_user_name"
password="my_password"
recursive="true"
comment="attempt to make a branch"
branchname="test-branch"
dbpath="${SourceSafeDBPath}"
path="${SourceSafeRootPath}/${CURRENT_FILE}"
verbose="true"
/>
</foreach>
</target>
OUTPUT:
NAnt 0.85 (Build 0.85.2478.0; release; 10/14/2006)
Copyright (C) 2001-2006 Gerry Shaw
http://nant.sourceforge.net
Buildfile: file:///C:/scm/custom/src/VssBranch/bin/Debug/test.build
Target framework: Microsoft .NET Framework 2.0
Target(s) specified: run
run:
[loadtasks] Scanning assembly "NAnt.Contrib.Tasks" for extensions.
[loadtasks] Scanning assembly "VssBranch" for extensions.
[echo] About to execute: VSS Branch
....
[vssbranch] Branching SecurityProto path: $/VSS/Endur's Source/C#/DailyLive/proto/test-branch/SecurityProto
....
BUILD SUCCEEDED
Total time: 12.9 seconds.
Obviously the output would vary, I was pulling in the items to branch from a text file named 'params.txt'. This task performs what is known in the VSS world as 'Share and Branch' (Branching immediately after Sharing)...other source control systems do not need to share before branching, eh...that's for another day
The vss tasks live in the NAntContrib project and no, currently there is no task that supports branching. Though, following the model of the existing vss tasks (add, checkout, checkin, etc) in NAntContrib, you could grab the source and extend it yourself. That is, if the VSS API supports branching.