CodePlex2465: Issue with navigation properties & entity splitting.

Change 7bbd3a57f40638b7e3955e3df40fe914eff19c26 added a setter for ForeignKeyBuilder.Name. The implementation updated the name of the referenced association type but did not update the name of the referenced association set. This causes identity conflicts. The fix updates the association set name.
Fix for #2433
The value returned by GetHashCode was not deterministic because it seems there are scenarios where _node.GetNodeInfo(_command).HashValue changes between the TryGetValue and the Add calls in VisitNavPropertyOp, while the navigation property node tree is rewritten. The fix computes the hashCode in the constructor and stores it into a field that is returned by the GetHashCode method, thus making it deterministic. Also using RuntimeHelpers.GetHashCode for root and property to ensure that potential overrides of GetHashCode in Node and EdmMember do not interfere with this logic.
Fix for Issue 2267: Code First, table splitting: Sequence contains more than one matching element

Issue:
When configuring the principal key column names we assumed that the principal entity type from the pair sharing the table is configured first.

Solution:
Configure the dependent key columns to match the principal ones even if the dependent entity type was configured first.
Also removed the KeyNamesType annotation as it doesn't appear to serve any purpose.
Bug 952621: Second issue with previous fix for duplicate joins (duplicate key exception while adding to dictionary)

For the dictionary lookup and additions to function properly the key's hash code has to be deterministic, and the fields involved in the Equals comparison have to be immutable. Apparently there are scenarios when _node is changed by the Rewrite or Visit calls that happen between TryGetValue and Add, in the VisitNavPropertyOp method. The fix seals a NavigationPropertyOpInfo instance by cloning the _node field. Thus, changes to the original node will not affect the result of Equals. Cloning _node does not clone the referenced navigation property (same instance is used). Also the roots are compared by reference so changes in their sub-trees do not affect the result of Equals.

While this is theoretically likely the reason for the failure, the customer did not provide a repro and I wasn't able to come up with one so far.
CodePlex 2365: DropTable DB-Hang

DROP TABLE executed outside a transaction hangs if ALTER TABLE has been executed within the transaction. In the migrations' Down methods we generate DropForeignKey operations (i.e. ALTER TABLE) before DropTable. In lots of cases this is not necessary and the issue can be worked-around by removing the DropForeignKey operations and arranging the DROP table operations to drop first those that reference other tables to be dropped. However this does not work if circular foreign key constraints exist. For that reason this change groups subsequent statements with SuppressTransaction = false and executes them within separate transactions that are committed before the statements with SuppressTransaction = false are executed. With this change the migration statements can potentially execute in separate transactions, thus not ensuring full rollback in case of failure. However those cases should be rare, if any, because in the majority of the cases the statements with SuppressTransaction = true are (or can be placed) all at the beginning or end.
Fixed incorrect query plan cache when switching ExecutionStrategy retrying behavior.
Fixed or disabled tests that fail on Sql Azure
Renamed internal properties from "Behaviour" to "Behavior"
Fix for #2253
Turing on unit tests for VS14. Two tests don't work at the moment - these are #if'd out til I find out why.
Merge branch 'master' of https://git01.codeplex.com/entityframework
Cosmo and Dibs...  (Fix for 2382: Explicit Composite Index Only Includes One of Two Specified Columns)

The issue here was the foreign key index convention which was replacing any existing index on the column with the convention index. This didn't usually happen because if an explicit index is defined for the FK columns then the convention doesn't kick in. In this case the explicit index only spanned one column of the composite foreign key and so the convention still kicked in and the existing annotation on the column was clobbered.
Fix for #2253

Initial fix exposed a Code First issue, which was that we need to ensure dependents in table-splitting do not have any store-generated keys.
Donuts for the FxCop
 byte and short properties, parameters, constants used with LINQ are up-converted to int, resulting in unnecessary casts in the translated SQL in some cases, which can degrade performance when used in filters. The fix processes comparison operations, removes unnecessary converts, and replaces the involved constants with equivalent ones down-converted to the type of the other operand if the value is in the type's range. Also, because of limitations in the LINQ expressions (Expression.MakeBinary throw if operands are enum and operator is greater than, less than, etc) the fix converts to the underlying type of the enum, the resulting SQL casts being eliminated in SqlGenerator.

Comments from contributor:

To Convert or to not convert?
Fix for issue 186 and 823.

This fix is divided in 2 parts, first part kicks in during CQT generation trying to remove redundant Convert, this is necessary since the .Net Framework generates an expression with unnecessary convert even when not needed, there is even a bug on connect, see here
https://connect.microsoft.com/VisualStudio/feedback/details/549615/remove-unnecessary-converts-from-expression-trees

This can be easily tested with following code (copy and paste in linqpad)

void Main()
{
 Expression<Func<Foo, bool>> expression = foo => foo.Bar == Bar.Value1;
 expression.Dump();
}

public class Foo
{
 public Bar Bar { get; set; }
}

public enum Bar : short
{
 Value1,
 Value2,
}

Although with the above fix EF to strips out the unnecessary cast on filter for equality, filter for inequality remain still broken (i.e. the cast is still present) because of how the SqlGenerator handles DbNotExpression,
so the second fix is to switch from VisitBinaryExpression to VisitComparisonExpression  inside the Visit(DbNotExpression) to allow EF calculate correctly if the cast are really required.

Added a bunch of unit test to verify the correctness of the fix and updated some unit test to strip out the unnecessary convert from the expected sql.
Fix for 2488: Tests marked with [UseDefaultExecutionStrategy] are flaky on SQL Azure

Adding explicit ExtendedSqlAzureExecutionStrategy calls to the affected tests.

Workitem: 2488
Making the SQL Server provider use the ExecutionStrategy for Create and Drop operations

Workitem: 2494
Updating EntityFramework code to pass CodeAnalysis (on Release & Debug
builds). Updating DesignXmlCore code to pass CodeAnalysis (on Release &
Debug builds).

Getting UnitTests running - fixing problems with (localdb)\MSSQLLocalDB
and to expect the v12 version of Microsoft.SqlServer.Types for DbGeography
and DbGeometry.
Updating EntityFramework.SqlServer and EntityFramework.SqlServerCompact to pass CodeAnalysis
CodePlex2457: EF6 String Concatenation SQL Does Not Honor UseDbNullSemantics.
The fix flows down the useDatabaseNullSemantics flag to StripNull and does not create the case expression in case it is true.
Missed one CodeAnalysis error in EntityFramework