Contains Malone and the attack of the killer hash codes: Fix for 425: Consider using Contains method if available

When checking whether or not an entity exists in a navigation property the code was always doing a linear search through the entities. In a lot of cases calling Contains on the collection will be faster. However, Contains may not work correctly in cases where Equals and GetHashCode are overridden. (This is arguably an issue in the app code, but we are trying to be resilient to this.)

The fix is to use Contains either or both of two conditions hold:
1. The navigation property is a HashSet that uses our reference equality comparer. This is what we create internally for null nav properties, but it can also be done explicitly by the app.
2. The entity type being added does not override Equals or GetHashCode. It is still possible that the collection is doing non-standard comparisons without using Equals or GetHashCode, but this seems like a good balance.
Adding new Model to functional tests, CR: AnPete
changes to csproj
fix to csproj
Knowing Key, Knowing You: A-Ha! (Additional fix for 1192: Making initializers and Migrations play nice)

The problem was that when the MigrationHistory table is created from Migrations it will use the ContextKey specified in the Migrations configuration. If model compatibility is then going to be checked it must also use this context key.

The solution is to moved Migrations configuration discovery to InternalContext and then use the ContextKey discovered when doing compatibility checks.
Not so complex after all... (Fix for 1278: DetectChanges throws when changing complex property instance on change tracking proxy)

This was a regression introduced post alpha 3 by a change to optimize original value tracking in the state manager. The problem is that when a complex object instance is changed in a change tracking proxy the change is updated immediately in the state manager. However, this was not taken into account by DetectChanges which then detected the snapshot difference and tried to make the same change again.

It might be possible to have DetectChanges not process complex object instance changes when change tracking proxies are being used, but this is not straightforward code and I am not confident that it would a) work b) have any significant benefit and c) not introduce more regressions. Therefore, the simple fix here is to make the new optimized code behave in the same way as it always has--that is, allow DetectChanges to make the change even though it has already been recorded.
Migrations: Fix for #1244 - Migrating from PK/FK to separated out FK as an IA scaffold invalid migration

Problem: We would incorrectly produce a RenameColumn operation when going from an FK to an IA when the previous FK property still exists in the target model.
Solution: Do not detect a rename when the previous FK property still exists in the target model. This causes a new IA fk column to be created.

Additional fix: I noticed that C#/VB scaffolding would generate an argument containing the target PK columns when emitting DropPrimaryKey calls, even though the DropPrimaryKey API has no corresponding argument (it worked because the argument was treated as a migrations anonymous argument). I changed scaffolding to no longer generate the redundant argument.

Work Item: 1244
Dude, where's your key? (Fix for 663: Exception when calling DetectChanges twice with nullable keys)

The issue was due to attempting to store a null FK incorrectly. The code was assuming that it was possible to create a new EntityKey using the PK value(s). But the PK key values are null in this case, so the FK is also null. EntityKey doesn't support null values and instead expects the FK to be stored as null. I checked the code for other places where the same thing might be happening and couldn't find anything.
Avoiding retries on connection failure during transaction commit.
Increasing timeout for deadlock tests.
Adding System.Data.Entity.Design.Executor -- a new component for tooling scenarios
Migrations: Fix for #1242 - Misleading exception thrown when trying to map entity with composite key, being a dependent of 1-Many relationship

Problem: When generating update trees for dependent entities of IAs whose principal end is required, we first need to change the relationship state to deleted before setting it to added.
Solution: This is actually the same requirement that was previously identified and fixed for one-to-ones (#1190). So, the fix was to broaden the solution to handle all IAs having a required principal.

Work Item: 1242
Shelling out for a new version... (Changes for 467: Determine correct way to reference Microsoft.VisualStudio.Shell)

I investigated several aspects of this:

1. I confirmed that on VS 2013 this mechanism of checking for web projects (web applications, web sites, and other projects) still works.

2. Given that neither the 10 or 11 Shell assemblies are present when just VS 2013 is installed it seems like this code should not have worked...but it did. The reason turned out to be that the VS app domain has binding redirects so that attempting to load 10 (or 11) causes the current version (e.g. 12) to be loaded. This is exactly what we want, which means that when used in the product we only need to load 10 dynamically and the correct version 11, 12, etc. will be loaded.

3. We have a test that can be used to execute this code when running the tests from Visual Studio. Since the test doesn't have the binding redirects setup it means that this test must load the correct version of the assembly. This is currently hard-coded for the test--see CodePlex 1367. We may choose to change this, but we probably won't do so before EF6.
Dude, that's not my key! (Additional fix for 1192)

The previous checkin for this issue made InternalContext use the context key from the discovered migrations configuration if possible. This worked for compatibility checking in initializers, but caused a problem with scaffolding initial create. The problem was that when scaffolding an initial create the first step involves creating a configuration. Later this is then discovered and the context key is used from it instead of using the default. The fix is to have initial create always use the default.
Switch build target for Test and Package. Allows for InternalsVisibleTo to be removed on nightly
Adding overloads for setting the container during EdmModel creation and making GlobalItems public again.
Making deadlock tests more robust.
Further improvement to deadlock tests.
Six herrings or half a dozen mackerel (Fix for 906: Database.UseTransaction may perform context initialization)

This is a bit of a red herring given where we landed with transactions and initializers. First, in order to use UseTransaction you need to have a connection to a database, so the initializer here cannot be being used to create the database. Second, initialization always uses a cloned connection because attempting to reuse the same connection caused more problems than it fixed (see 771). Since the initializer is always using a cloned connection it means that it will never be using the transaction associated with the current connection.

Therefore, regardless of whether the code is changed the initializer will not make use of a transaction supplied by UseTransaction. However, given that there is no need to initialize the database on a call to UseTransaction and this is a simple change it has been made.
Migrations: Fix for #1346 - Migrations/SPROCs: When scaffolding InitialCreate during Enable-Migrations SPROC bodies are blank

Added missing parameters to the differ on the ScaffoldInitialCreate code path.