Create database for Entity Framework

down voteaccepted

Follow below steps: 1) First go to Server Explorer in Visual Studio, check if the ".mdf" Data Connections for this project are connected, if so, right click and delete. 2 )Go to Solution Explorer, click show All Files icon. 3) Go to App_Data, right click and delete all ".mdf" files for this project. 4) Delete Migrations folder by right click and delete. 5) Go to SQL Server Management Studio, make sure the DB for this project is not there, otherwise delete it. 6) Go to Package Manager Console in Visual Studio and type: Enable-Migrations -Force Add-Migration init Update-Database 7) Run your application Note: In step 6 part 3, if you get an error "Cannot attach the file...", it is possibly because you didn't delete the database files completely in SQL Server. if  this error :A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 50 - Local Database Runtime error occurred. The specified LocalDB instance does not exist. )        : sqllocaldb c Projects 11.0 Command line explained c - is for "create" "Projects - is the instance name 11.0 is the version

Wordpress Multiside migration

Moving or migrating a WordPress Multisite can be frustating. If you don't know how to move it safely, your site can break along the way. Either the database, the settings, or both. Let me share you how to migrate WordPress Multisite safely without breaking anything.

In this tutorial, I will explain how to moving WordPress Multisite from live server to localhost with an example case: we will move WordPress Multisite from http://example.com to http://localhost/example.

In this case, the live server is using cPanel and the localhost is running on XAMPP.

1. First, we have to copy all WordPress files from live server. You can download it all via FTP. Or if you prefer to download it directly from cPanel, you can go to 'File Manager' in your cPanel. Navigate to public_html. Select all files, click 'Compress'. Download the compressed file. Don't forget to delete the compressed file from live server after you finish download it.
2. Now we need to copy the database. Go to cPanel's phpMyAdmin. Export the entire database of WordPress Multisite that we want to move.
3. Create new folder 'example' in localhost folder (\xampp\htdocs\). Extract the compressed file that we have downloaded in step 1 to the folder 'example'. Now we have the WordPress files inside the folder 'example'.
4. Create new database in the local phpMyAdmin. Visit http://localhost/phpmyadmin/. For this tutorial, I will name it 'exampledb'. Import database that we have exported from live site in step 2.
5. Open .htaccess in the root folder (\xampp\htdocs\example\). Edit RewriteBase into:

   RewriteBase /example/

6. Open wp-config.php. Change database information to:

   /** The name of the database for WordPress */
   define('DB_NAME', 'exampledb');
   
   /** MySQL database username */
   define('DB_USER', 'root');
   
   /** MySQL database password */
   define('DB_PASSWORD', '');
   
   /** MySQL hostname */
   define('DB_HOST', 'localhost');

   Also, edit these two lines to:

   /* Multisite */
   
   define('DOMAIN_CURRENT_SITE', 'localhost');
   define('PATH_CURRENT_SITE', '/example/');

7. After that, we need to change all urls. DO NOT manually search and replace everything. WordPress database use data serialization. Any mistakes can make your site cannot work properly. You have to use tools or scripts to search and replace database. As recommended on WordPress, we will use Search and Replace Database script from interconnectit.com. Download that script (We use V 2.1.0 Stable).
8. Extract that script's .zip file. You will see .php file inside. For security reason, rename it to difficult name. Something like: w39opzzzzzzzt.php. Make it hard to be guessed!
9. Copy it to the root folder.
10. Run the script by visiting http://localhost/example/w39opzzzzzzzt.php (or your choosen file name in step 8).
11. Check 'Pre-populate the DB values form with the ones used in wp-config? It is possible to edit them later.' Click 'submit'.
12. Click 'Submit DB details'.
13. Select all tables. Leave 'Leave GUID column unchanged?' unchecked. Click 'Continue'.
14. Search for http://example.com, replace with http://localhost/example. Click 'Submit Search string'.
15. Don't forget to DELETE Search and Replace Database script .php file as soon as you finish use it!! It is very very important for security reason. You don't want someone to use it and break your site, do you? 
16. Go to database (http://localhost/phpmyadmin/).
17. Check wp_site table (or yourtableprefix_site). Change domain, from example.com to localhost. And path, from / to /example/
18. Also change domain and path in wp_blogs table (or yourtableprefix_blogs).
19. Now, visit the site in http://localhost/example. You should see it running smoothly without problem. 

ref : https://interconnectit.com/products/search-and-replace-for-wordpress-databases/

ROW_NUMBER() Performance optimization

You could try creating an Indexed View on the two tables:

CREATE VIEW dbo.YourIndexedView
WITH SCHEMABINDING 
AS
    SELECT  az.ArticleID,
            az.ChannnelID,
            az.ZoneID,
            a.LastEditDate,
            a.LastEditDateTime,
            az.ArticleOrder
    FROM    dbo.Article_tbl a
            INNER JOIN dbo.ArticleZone_tbl az
                ON a.ArticleID = az.AtricleID;

GO
CREATE UNIQUE CLUSTERED INDEX UQ_YourIndexView_ArticleID_ChannelID_ZoneID 
    ON dbo.YourIndexedView (ArticleID, ChannelID, ZoneID);

Once you have your clustered index in place you can create a nonclustered index that would assist in the sorting:

CREATE NONCLUSTERED INDEX IX_YourIndexedView_LastEditDate_ArticleOrder_LastEditDateTime
    ON dbo.YourIndexedView (LastEditDate DESC, ArticleOrder ASC, LastEditDateTime DESC);

You can then reference this in your query:

WITH OrderedOrders AS
(   SELECT  RowNum = ROW_NUMBER() OVER(ORDER BY LastEditDate DESC, ArticleOrder ASC, LastEditDateTime DESC),
            ArticleID,
            ChannelID,
            ZoneID,
            LastEditDateTime,
            ArticleOrder
    FROM    dbo.YourIndexedView WITH (NOEXPAND)
    WHERE   ChannelID = 1 
    AND     ZoneID = 0
)
SELECT  *
FROM    OrderedOrders
WHERE   RowNum BETWEEN 1 AND 10;

N.B. I may have missed some columns from your article table, but I couldn't infer them from the question

Furthermore, if your query is always going to have the same zone and channel, you could filter the view, then your clustered index column simply becomes ArticleID:

CREATE VIEW dbo.YourIndexedView
WITH SCHEMABINDING 
AS
    SELECT  az.ArticleID,
            az.ChannnelID,
            az.ZoneID,
            a.LastEditDate,
            a.LastEditDateTime,
            az.ArticleOrder
    FROM    Article_tbl a
            INNER JOIN ArticleZone_tbl az
                ON a.ArticleID = az.AtricleID
    WHERE   az.ChannelID = 1
    AND     Az.ZoneID = 1;

GO
CREATE UNIQUE CLUSTERED INDEX UQ_YourIndexView_ArticleID 
    ON dbo.YourIndexedView (ArticleID);

Which means your indexes will be smaller, and faster to use.

src : http://stackoverflow.com/questions/20230172/row-number-performance-optimization

EF Migrations Command Reference

 

Posted on 2012-03-19 by Anders Abel

EF Migrations series

• Using Entity Framework to Create a Database
• Adding Indexes with EF Migrations
• Updating a Table with EF Migrations
• Indexes in Code-Based EF Migrations
• EF Migrations and a Merge Conflict
• Prevent EF Migrations from Creating or Changing the Database
• EF Code First Change Tracking
• EF Migrations Command Reference
• EF Code First Navigation Properties and Foreign Keys
• Update-Database MSI Custom Action

Entity Framework Migrations are handled from the package manager console in Visual Studio. The usage is shown in various tutorials, but I haven’t found a complete list of the commands available and their usage, so I created my own. There are four available main commands.

• Enable-Migrations: Enables Code First Migrations in a project.
• Add-Migration: Scaffolds a migration script for any pending model changes.
• Update-Database: Applies any pending migrations to the database.
• Get-Migrations: Displays the migrations that have been applied to the target database.

This post was updated 2014-07-02 with Entity Framework 6.1.1

There are also three extra commands that are used by NuGet packages that install Entity Framework providers. These commands are not usually used as part of normal application development.

• Add-EFProvider: Adds or updates an Entity Framework provider entry in the project config file.
• Add-EFDefaultConnectionFactory: Adds or updates an Entity Framework default connection factory in the project config file.
• Initialize-EFConfiguration: Initializes the Entity Framework section in the project config file and sets defaults.

The information here is the output of running get-help command-name -detailed for each of the commands in the package manager console (running EF 4.3.1 6.1.1). I’ve also added some own comments where I think some information is missing. My own comments are placed under the Additional Information heading.

Please note that all commands should be entered on the same line. I’ve added line breaks to avoid horizontal scrollbars.

Enable-Migrations

Enables Code First Migrations in a project.

Syntax

Enable-Migrations [-ContextTypeName <String>] [-EnableAutomaticMigrations] [-MigrationsDirectory <String>] [-ProjectName <String>] [-StartUpProjectName <String>] [-ContextProjectName <String>] [-ConnectionStringName <String>] [-Force] [-ContextAssemblyName <String>] [-AppDomainBaseDirectory <String>] [<CommonParameters>]   Enable-Migrations [-ContextTypeName <String>] [-EnableAutomaticMigrations] [-MigrationsDirectory <String>] [-ProjectName <String>] [-StartUpProjectName <String>] [-ContextProjectName <String>] -ConnectionString <String> -ConnectionProviderName <String> [-Force] [-ContextAssemblyName <String>] [-AppDomainBaseDirectory <String>] [<CommonParameters>]

Description

Enables Migrations by scaffolding a migrations configuration class in the project. If the target database was created by an initializer, an initial migration will be created (unless automatic migrations are enabled via the EnableAutomaticMigrations parameter).

Parameters

-ContextTypeName <String>

Specifies the context to use. If omitted, migrations will attempt to locate a single context type in the target project.

-EnableAutomaticMigrations [<SwitchParameter>]

Specifies whether automatic migrations will be enabled in the scaffolded migrations configuration. If ommitted, automatic migrations will be disabled.

-MigrationsDirectory <String>

Specifies the name of the directory that will contain migrations code files. If omitted, the directory will be named “Migrations”.

-ProjectName <String>

Specifies the project that the scaffolded migrations configuration class will be added to. If omitted, the default project selected in package manager console is used.

-StartUpProjectName <String>

Specifies the configuration file to use for named connection strings. If omitted, the specified project’s configuration file is used.

-ContextProjectName <String>

Specifies the project which contains the DbContext class to use. If omitted, the context is assumed to be in the same project used for migrations.

-ConnectionStringName <String>

Specifies the name of a connection string to use from the application’s configuration file.

-ConnectionString <String>

Specifies the the connection string to use. If omitted, the context’s default connection will be used.

-ConnectionProviderName <String>

Specifies the provider invariant name of the connection string.

-Force [<SwitchParameter>]

Specifies that the migrations configuration be overwritten when running more than once for given project.

-ContextAssemblyName <String>

Specifies the name of the assembly which contains the DbContext class to use. Use this parameter instead of ContextProjectName when the context is contained in a referenced assembly rather than in a project of the solution.

-AppDomainBaseDirectory <String>

Specifies the directory to use for the app-domain that is used for running Migrations code such that the app-domain is able to find all required assemblies. This is an advanced option that should only be needed if the solution contains several projects such that the assemblies needed for the context and configuration are not all referenced from either the project containing the context or the project containing the migrations.

<CommonParameters>

This cmdlet supports the common parameters: Verbose, Debug, ErrorAction, ErrorVariable, WarningAction, WarningVariable, OutBuffer, PipelineVariable, and OutVariable. For more information, seeabout_CommonParameters.

Examples

-------------------------- EXAMPLE 1 -------------------------- C:\PS>Enable-Migrations   # Scaffold a migrations configuration in a project with only one context   -------------------------- EXAMPLE 2 -------------------------- C:\PS>Enable-Migrations -Auto   # Scaffold a migrations configuration with automatic migrations enabled for a project # with only one context   -------------------------- EXAMPLE 3 -------------------------- C:\PS>Enable-Migrations -ContextTypeName MyContext -MigrationsDirectory DirectoryName   # Scaffold a migrations configuration for a project with multiple contexts # This scaffolds a migrations configuration for MyContext and will put the configuration # and subsequent configurations in a new directory called "DirectoryName"

Remarks

To see the examples, type: get-help Enable-Migrations -examples.
For more information, type: get-help Enable-Migrations -detailed.
For technical information, type: get-help Enable-Migrations -full.

Additional Information

The flag for enabling automatic migrations is saved in the Migrations\Configuration.cs file, in the constructor. To later change the option, just change the assignment in the file.

public Configuration() { AutomaticMigrationsEnabled = false; }

Add-Migration

Scaffolds a migration script for any pending model changes.

Syntax

Add-Migration [-Name] <String> [-Force] [-ProjectName <String>] [-StartUpProjectName <String>] [-ConfigurationTypeName <String>] [-ConnectionStringName <String>] [-IgnoreChanges] [-AppDomainBaseDirectory <String>] [<CommonParameters>]   Add-Migration [-Name] <String> [-Force] [-ProjectName <String>] [-StartUpProjectName <String>] [-ConfigurationTypeName <String>] -ConnectionString <String> -ConnectionProviderName <String> [-IgnoreChanges] [-AppDomainBaseDirectory <String>] [<CommonParameters>]

Description

Scaffolds a new migration script and adds it to the project.

Parameters

-Name <String>

Specifies the name of the custom script.

-Force [<SwitchParameter>]

Specifies that the migration user code be overwritten when re-scaffolding an existing migration.

-ProjectName <String>

Specifies the project that contains the migration configuration type to be used. If ommitted, the default project selected in package manager console is used.

-StartUpProjectName <String>

Specifies the configuration file to use for named connection strings. If omitted, the specified project’s configuration file is used.

-ConfigurationTypeName <String>

Specifies the migrations configuration to use. If omitted, migrations will attempt to locate a single migrations configuration type in the target project.

-ConnectionStringName <String>

Specifies the name of a connection string to use from the application’s configuration file.

-ConnectionString <String>

Specifies the the connection string to use. If omitted, the context’s default connection will be used.

-ConnectionProviderName <String>

Specifies the provider invariant name of the connection string.

-IgnoreChanges

Scaffolds an empty migration ignoring any pending changes detected in the current model. This can be used to create an initial, empty migration to enable Migrations for an existing database. N.B. Doing this assumes that the target database schema is compatible with the current model.

-AppDomainBaseDirectory <String>

Specifies the directory to use for the app-domain that is used for running Migrations code such that the app-domain is able to find all required assemblies. This is an advanced option that should only be needed if the solution contains several projects such that the assemblies needed for the context and configuration are not all referenced from either the project containing the context or the project containing the migrations.

<CommonParameters>

This cmdlet supports the common parameters: Verbose, Debug, ErrorAction, ErrorVariable, WarningAction, WarningVariable, OutBuffer, PipelineVariable, and OutVariable. For more information, seeabout_CommonParameters.

-------------------------- EXAMPLE 1 -------------------------- C:\PS>Add-Migration First   # Scaffold a new migration named "First"   -------------------------- EXAMPLE 2 -------------------------- C:\PS>Add-Migration First -IgnoreChanges   # Scaffold an empty migration ignoring any pending changes detected in the current model. # This can be used to create an initial, empty migration to enable Migrations for an existing # database. N.B. Doing this assumes that the target database schema is compatible with the # current model.

<CommonParameters>

Remarks

To see the examples, type: get-help Add-Migration -examples.
For more information, type: get-help Add-Migration -detailed.
For technical information, type: get-help Add-Migration -full.

Update-Database

Applies any pending migrations to the database.

Syntax

Update-Database [-SourceMigration <String>] [-TargetMigration <String>] [-Script] [-Force] [-ProjectName <String>] [-StartUpProjectName <String>] [-ConfigurationTypeName <String>] [-ConnectionStringName <String>] [-AppDomainBaseDirectory <String>] [<CommonParameters>]   Update-Database [-SourceMigration <String>] [-TargetMigration <String>] [-Script] [-Force] [-ProjectName <String>] [-StartUpProjectName <String>] [-ConfigurationTypeName <String>] -ConnectionString <String> -ConnectionProviderName <String> [-AppDomainBaseDirectory <String>] [<CommonParameters>]

Description

Updates the database to the current model by applying pending migrations.

Parameters

-SourceMigration <String>

Only valid with -Script. Specifies the name of a particular migration to use as the update’s starting point. If ommitted, the last applied migration in the database will be used.

-TargetMigration <String>

Specifies the name of a particular migration to update the database to. If ommitted, the current model will be used.

-Script

Generate a SQL script rather than executing the pending changes directly.

-Force

Specifies that data loss is acceptable during automatic migration of the database.

-ProjectName <String>

Specifies the project that contains the migration configuration type to be used. If ommitted, the default project selected in package manager console is used.

-StartUpProjectName <String>

Specifies the configuration file to use for named connection strings. If omitted, the specified project’s configuration file is used.

-ConfigurationTypeName <String>

Specifies the migrations configuration to use. If omitted, migrations will attempt to locate a single migrations configuration type in the target project.

-ConnectionStringName <String>

Specifies the name of a connection string to use from the application’s configuration file.

-ConnectionString <String>

Specifies the the connection string to use. If omitted, the context’s default connection will be used.

-ConnectionProviderName <String>

Specifies the provider invariant name of the connection string.

-AppDomainBaseDirectory <String>

Specifies the directory to use for the app-domain that is used for running Migrations code such that the app-domain is able to find all required assemblies. This is an advanced option that should only be needed if the solution contains several projects such that the assemblies needed for the context and configuration are not all referenced from either the project containing the context or the project containing the migrations.

<CommonParameters>

This cmdlet supports the common parameters: Verbose, Debug, ErrorAction, ErrorVariable, WarningAction, WarningVariable, OutBuffer, PipelineVariable, and OutVariable. For more information, seeabout_CommonParameters.

Examples

-------------------------- EXAMPLE 1 -------------------------- C:\PS>Update-Database   # Update the database to the latest migration   -------------------------- EXAMPLE 2 -------------------------- C:\PS>Update-Database -TargetMigration Second   # Update database to a migration named "Second" # This will apply migrations if the target hasn't been applied or roll back migrations # if it has   -------------------------- EXAMPLE 3 -------------------------- C:\PS>Update-Database -Script   # Generate a script to update the database from it's current state to the latest migration   -------------------------- EXAMPLE 4 -------------------------- C:\PS>Update-Database -Script -SourceMigration Second -TargetMigration First   # Generate a script to migrate the database from a specified start migration # named "Second" to a specified target migration named "First"   -------------------------- EXAMPLE 5 -------------------------- C:\PS>Update-Database -Script -SourceMigration $InitialDatabase   # Generate a script that can upgrade a database currently at any version to the latest version. # The generated script includes logic to check the __MigrationsHistory table and only apply changes # that haven't been previously applied.   -------------------------- EXAMPLE 6 -------------------------- C:\PS>Update-Database -TargetMigration $InitialDatabase   # Runs the Down method to roll-back any migrations that have been applied to the database

Remarks

To see the examples, type: get-help Update-Database -examples.
For more information, type: get-help Update-Database -detailed.
For technical information, type: get-help Update-Database -full.

Additional Information

The command always runs any pending code-based migrations first. If the database is still incompatible with the model the additional changes required are applied as an separate automatic migration step if automatic migrations are enabled. If automatic migrations are disabled an error message is shown.

Get-Migrations

Displays the migrations that have been applied to the target database.

Syntax

Get-Migrations [-ProjectName <String>] [-StartUpProjectName <String>] [-ConfigurationTypeName <String>] [-ConnectionStringName <String>] [-AppDomainBaseDirectory <String>] [<CommonParameters>]   Get-Migrations [-ProjectName <String>] [-StartUpProjectName <String>] [-ConfigurationTypeName <String>] -ConnectionString <String> -ConnectionProviderName <String> [-AppDomainBaseDirectory <String>] [<CommonParameters>]

Description

Displays the migrations that have been applied to the target database.

Parameters

-ProjectName <String>

Specifies the project that contains the migration configuration type to be used. If ommitted, the default project selected in package manager console is used.

-StartUpProjectName <String>

Specifies the configuration file to use for named connection strings. If omitted, the specified project’s configuration file is used.

-ConfigurationTypeName <String>

Specifies the migrations configuration to use. If omitted, migrations will attempt to locate a single migrations configuration type in the target project.

-ConnectionStringName <String>

Specifies the name of a connection string to use from the application’s configuration file.

-ConnectionString <String>

Specifies the the connection string to use. If omitted, the context’s default connection will be used.

-ConnectionProviderName <String>

Specifies the provider invariant name of the connection string.

-AppDomainBaseDirectory <String>

Specifies the directory to use for the app-domain that is used for running Migrations code such that the app-domain is able to find all required assemblies. This is an advanced option that should only be needed if the solution contains several projects such that the assemblies needed for the context and configuration are not all referenced from either the project containing the context or the project containing the migrations.

<CommonParameters>

This cmdlet supports the common parameters: Verbose, Debug, ErrorAction, ErrorVariable, WarningAction, WarningVariable, OutBuffer, PipelineVariable, and OutVariable. For more information, seeabout_CommonParameters.

Remarks

To see the examples, type: get-help Get-Migrations -examples.
For more information, type: get-help Get-Migrations -detailed.
For technical information, type: get-help Get-Migrations -full.

Add-EFProvider

Adds or updates an Entity Framework provider entry in the project config file.

Syntax

Add-EFProvider [-Project] <Object> [-InvariantName] <String> [-TypeName] <String> [<CommonParameters>]

Description

Adds an entry into the ‘entityFramework’ section of the project config file for the specified provider invariant name and provider type. If an entry for the given invariant name already exists, then that entry is updated with the given type name, unless the given type name already matches, in which case no action is taken. The ‘entityFramework’ section is added if it does not exist. The config file is automatically saved if and only if a change was made.

This command is typically used only by Entity Framework provider NuGet packages and is run from the ‘install.ps1′ script.

Parameters

-Project <Object>

The Visual Studio project to update. When running in the NuGet install.ps1 script the ‘$project’ variable provided as part of that script should be used.

-InvariantName <String>

The provider invariant name that uniquely identifies this provider. For example, the Microsoft SQL Server provider is registered with the invariant name ‘System.Data.SqlClient’.

-TypeName <String>

The assembly-qualified type name of the provider-specific type that inherits from ‘System.Data.Entity.Core.Common.DbProviderServices’. For example, for the Microsoft SQL Server provider, this type is ‘System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer’.

<CommonParameters>

This cmdlet supports the common parameters: Verbose, Debug, ErrorAction, ErrorVariable, WarningAction, WarningVariable, OutBuffer, PipelineVariable, and OutVariable. For more information, seeabout_CommonParameters.

Remarks

To see the examples, type: get-help Add-EFProvider -examples.
For more information, type: get-help Add-EFProvider -detailed.
For technical information, type: get-help Add-EFProvider -full.

Add-EFDefaultConnectionFactory

Adds or updates an Entity Framework default connection factory in the project config file.

Syntax

Add-EFDefaultConnectionFactory [-Project] <Object> [-TypeName] <String> [-ConstructorArguments <String[]>] [<CommonParameters>]

Description

Adds an entry into the ‘entityFramework’ section of the project config file for the connection factory that Entity Framework will use by default when creating new connections by convention. Any existing entry will be overridden if it does not match. The ‘entityFramework’ section is added if it does not exist. The config file is automatically saved if and only if a change was made.

This command is typically used only by Entity Framework provider NuGet packages and is run from the ‘install.ps1′ script.

Parameters

-Project <Object>

The Visual Studio project to update. When running in the NuGet install.ps1 script the ‘$project’ variable provided as part of that script should be used.

-TypeName <String>

The assembly-qualified type name of the connection factory type that implements the ‘System.Data.Entity.Infrastructure.IDbConnectionFactory’ interface. For example, for the Microsoft SQL Server Express provider
connection factory, this type is ‘System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework’.

-ConstructorArguments <String[]>

An optional array of strings that will be passed as arguments to the connection factory type constructor.

<CommonParameters>

This cmdlet supports the common parameters: Verbose, Debug, ErrorAction, ErrorVariable, WarningAction, WarningVariable, OutBuffer, PipelineVariable, and OutVariable. For more information, seeabout_CommonParameters.

Remarks

To see the examples, type: get-help Add-EFDefaultConnectionFactory -examples.
For more information, type: get-help Add-EFDefaultConnectionFactory -detailed.
For technical information, type: get-help Add-EFDefaultConnectionFactory -full.

Initialize-EFConfiguration

Initializes the Entity Framework section in the project config file and sets defaults.

Syntax

Initialize-EFConfiguration [-Project] <Object> [<CommonParameters>]

Description

Creates the ‘entityFramework’ section of the project config file and sets the default connection factory to use SQL Express if it is running on the machine, or LocalDb otherwise. Note that installing a different provider may change the default connection factory. The config file is automatically saved if and only if a change was made.

In addition, any reference to ‘System.Data.Entity.dll’ in the project is removed.

This command is typically used only by Entity Framework provider NuGet packages and is run from the ‘install.ps1′ script.

Parameters

-Project <Object>

The Visual Studio project to update. When running in the NuGet install.ps1 script the ‘$project’ variable provided as part of that script should be used.

<CommonParameters>

This cmdlet supports the common parameters: Verbose, Debug, ErrorAction, ErrorVariable, WarningAction, WarningVariable, OutBuffer, PipelineVariable, and OutVariable. For more information, seeabout_CommonParameters.

Remarks

To see the examples, type: get-help Initialize-EFConfiguration -examples.
For more information, type: get-help Initialize-EFConfiguration -detailed.
For technical information, type: get-help Initialize-EFConfiguration -full.

Additional Information

The powershell commands are complex powershell functions, located in the tools\EntityFramework.psm1 file of the Entity Framework installation. The powershell code is mostly a wrapper around theSystem.Data.Entity.Migrations.MigrationsCommands found in thetools\EntityFramework\EntityFramework.PowerShell.dll file. First a MigrationsCommands object is instantiated with all configuration parameters. Then there is a public method on the MigrationsCommands object for each of the available commands.

REF : http://coding.abel.nu/2012/03/ef-migrations-command-reference/