fix to issue 2394 - this is test issue revolving around implementation of OFFSET - FETCH for paging. We were incorrectly resolving provider manifest token (hardcoded based on context name, rather than actual version of the database).
     This resulted in some tests breaking on Azure, as well as some other tests not covering the OFFSET - FETCH when targeting SQL 2012 database.

     Fix is to restructure the tests, and generate expected sql based on the actual version of targeted sql server. We are adding run against sql 2008 to the CI server to cover that scenario extensively. Also removed some duplicates where expected sql was the same for 2008 and 2012, but we stored in in two separate places.

     CR: Luke, Brennan
All publicity is good publicity... (2361: Add publicly accessible constructors to ObjectResult classes)

There doesn't seem to be any reason not to add publicly accessible constructors here, beyond the normal caveat that everything breaks if the constructor is used for anything other than test doubles. Also made publicly accessible methods virtual.
[Polycheck violation; title suppressed] (2306: Suppress finalizers in InterceptableDbCommand)

InterceptableDbCommand ultimately inherits from Component which has a finalizer, but DbCommands are not disposed by EF and InterceptableDbCommand doesn't suppress finalizers. This means that InterceptableDbCommands and all the objects referenced from them do not get garbage collected until after the finalizer thread gets a chance to finalize them. This in turn can result in out-of-memory when the finalizer thread can't keep up.

The initial fix is to make sure finalizers are suppressed. See the issue for discussion of further changes that might be made.
Optimistically optimistic... (2380: Remove reference to ObjectStateManager from optimistic concurrency message)

Optimistic concurrency exception contains reference to ObjectStateManager even when DbContext is being used. Fix is to remove and replace with link to optimistic concurrency documentation.
Playing checkers in public... (Make DatabaseTableChecker functionality public so that other providers can implement)

This change makes public the DatabaseTableChecker functionality that is currently only implemented for SQL Server and SQL Server CE. There is no change to the way the functionality is implemented and no default implementation for other providers. The idea is simply to allow other providers to do what SQL Server and SQL CE currently do, if this is useful for other providers.

The changes are basically:
- Make public the interface implemented by providers and make it a base class
- Resolve an instance of this class from DbConfiguration
- Move the SQL Server and SQL CE implementations into their respective provider assemblies
- Make public some methods around transactions and interception so that these methods can be used from provider assemblies
- Have the SQL Server and SQL CE providers register the service in the normal way
In case of multiple properties referenced via a navigation property, the query pipline creates subqueries that project the corresponding columns and then OUTER APPLYs them. The OUTER APPLYs are later transformed into duplicate LEFT OUTER JOINS. The join elimnation phase is supposed to eliminate the duplicates. However it handles only equi-joins (with predicate of form columnA = columnB). In the repro case the navigation property returns a base type, which results in having an additional predicate that filters using the Discriminator column:

      [Extent2].[Discriminator] IN (N'DerivedTypeA',N'DerivedTypeB',N'DerivedTypeC',N'DerivedTypeD',N'DerivedTypeE')

     The join elimination phase simply shortcuts the exection and does not do anything if the joins are not exclusively equi-joins, the final query ends having unnecessary joins which seem to cause performance problems.

     An ideal solution would be to try to project all properties referenced via the navigation property in the given scope, thus not producing unnecessary joins. That requires rewritting the IQT, and after spending some time on it, it seemed complex and highly risky to do. The second option, which is implemented here, is to enhance the join elimination phase to handle some cases of non equi-join predicates.

     The JoinElimination phase builds a graph of tables and joins, then performs elimination by trying to turn left outer joins into inner joins, generating transitive edges, eliminating self joins, star self joins and parent child joins, then rebuilding the IQT.

     First I removed the top level check in JoinGraph.BuildJoinEdges that shortcuts the execution for non equi-joins. This allowed the code to build the parts of the graph that correspond to non equi-joins (have OtherPredicate). Then I moved the check into JoinEdge.RestrictedElimination, which is already called at a more granular level during join elimination, to make sure that the additional edges in the graph don't impact cases that don't know how to handle non equi-joins (generate transitive edges, eliminate self joins, parent-child joins). With these changes the code still runs on the path that eliminates star self joins (X join T1 join T2 join T3 ..., where T1, T2, T3 are instances of the same table). The rest of the changes handle the OtherPredicate on this execution path.

     The join edges that represent joins like "X join Ti" are grouped and then elimination is performed. To qualify for starting a start self join group a join edge has to respect conditions implemented by JoinGraph.QualifiesForStarSelfJoinGroup. I added code to this method to also check the non equi-join predicate (OtherPredicate). A relatively good condition for OtherPredicate is to refer columns from the right table only (behave like a filter on the right table). Additional edges are added to the group if the predicate matches. I added code to also match the OtherPredicate. Non equi-join predicate nodes match if their Ops match, and they have the same number of matching child nodes. In case of VarRefOp with ColumnVar the nodes match if they reference the same column.
Correct path to SymbolsPackages
CodePlex 2369: FilterOpRules.Rule_FilterOverLeftOuterJoin is deferred until after the NullSemantics and JoinElimination phases to allow the expansion of the filter predicate to account for nulls (required by the Predicate.PreservesNulls), and respectively to eliminate duplicate left out joins before promoting to inner join (necessary due to a limitation in the JoinElimination phase). ApplyOpRules.Rule_OuterApplyOverFilter needs to be deferred as well. In case of one to one relationships when something is queried from the principal via the navigation property on the dependent, the interdependency between these two transformation rules results in an expression tree with unnecessary joins that cannot be eliminated because of another limitation in the JoinElimination phase (see case b. described in the comments on JoinGraph.TryTurnLeftOuterJoinsIntoInnerJoins).
The fix defers ApplyOpRules.Rule_OuterApplyOverFilter by skipping execution when PlanCompiler.DeferredTransformations flag is true. The rule is executed during the PostJoinElimination transformations phase.
Making the Kessel Run in less than 12 parsecs - Fix for #2298

This changeset contains performance optimizations of hot paths of the model building code. This is functionally equivalent to the old code but I'm rewriting the hot paths to not use Linq and prefer direct iterators. I also added a cache of the key properties in class EntityTypeBase.

The fixes were tested against a large code first model. Using EF5, the startup time is about 12400ms. Using EF6 before these changes the startup time is about 22400ms. After these changes, EF6 takes about 18800ms.

There's room for improvement but not without major refactoring. The two largest CPU consumers in this process at this point is TypeUsage and the way it rebuilds everything when setting EdmProperty.PrimitiveType.

All tests passing.
Fixes work item #2345
Merge branch 'master' of https://git01.codeplex.com/entityframework
Fix for work item: #2391
fixing bug in SqlCe table checker, where we were checking for invalid metadata table name. CR: Arthur
Donuts for the FxCop
Merge branch 'master' of https://git01.codeplex.com/entityframework
Fix for 2087: TPT different name for the PK columns ignored when DbSet for derived type is included

The fix is multifaceted as there are multiple issues with derived type configurations:
  Configuration object assigned to property when it's being configured will be cloned so that when its mutated other properties wont be affected
  Configuration for inherited properties will not be removed whether the base type is discovered first or not
  When discovering properties all ancestor type configurations will also be checked for ignored properties
  When removing duplicate TPH column configurations they will be merged in S-Space instead of C-Space
  PrimitivePropertyConfiguration will only configure IsNullable, ConcurrencyMode and DatabaseGeneratedOption in C-Space
  Custom annotations configuration will only be merged in S-Space
  BinaryPropertyConfiguration will only configure ColumnType in S-Space
Hybrid technology requires more gas... (2254: TPT/TPH hybrid generates database, but derived properties are not nullable)

The default configuration is TPH and columns coming from properties in derived types are made nullable. When mapping switches to TPT the nullability of these columns is reset. But if the mapping is actually hybrid with TPT at the base and then TPH below it then the nullability of some columns should not be reset.

Note that there is a fairly good chance that this change will cause a perf hit for model building with large models containing inheritance. We should investigate/profile as necessary.
"Threads are easy" said no one, ever - Fix for #2429
Test KeyProperties_is_thread_safe failed while running a build in a development machine. Assert.True(keys != null) failed because the getter to KeyProperties would allow for a change of value in the _keyProperties member between the check for nullity and the return instruction. This is solved by copying the value of _keyProperties to a local variable before checking for nullity and using it as the return value.
Additionally, there was a second concurrency problem which would manifest as a failure in the Assert.False(ReferenceEquals(keys, keysAfterReset)). It was caused by the event subscription model used. The KeyProperties getter, when _keyProperties is null, first creates the instance and then registers an event handler onto KeyMembers.SourceAccessed. When KeyMembers.Source is touched, it calls the handler which in turn tries to clear the value of _keyProperties to null and then unregisters the event handler of KeyMembers.SourceAccessed. The issue was solved by inverting the order of the instructions in the KeyProperties getter to first set the event handler and then initialize the value of _keyProperties.
Note that in my development machine the test always passed when executed, and so far it hasn't failed in the CI environment either. That said, before this change the test would fail consistently when executed under a debugger, which presumably changes the concurrency characteristics of the environment.
Issue 2264. Separated out the part of EFToolsMsi.wixproj which pulls out all the runtime dependencies into a separate .msbuild file so that it can be overridden for Servicing.
Hey Mom, that's my stuff! (2418: ObjectContext.ExecuteStoreQueryInternal disposes DbCommand too early)

In previous versions of EF the command was not disposed at all. See https://entityframework.codeplex.com/workitem/2306 for more info. In EF6 we started disposing the commands immediately, which is wrong because the command should not be disposed until after the reader is disposed. The easiest fix would be to revert to the EF5 behavior. In this case I chose to instead keep disposing but only when the returned ObjectResult is disposed. This seems like the least change in EF6 functionality that fixes the issue.