This isn't an issue, but I thought this information might be useful for someone in the future and didn't really know where else to put it. If there's somewhere better to add it, feel free to do so and remove this.
I recently upgraded our project to EF6 mainly so we could take advantage of the new transient error handling feature. I got everything working with EF6 again and then implemented the transient error handling and suddenly my unit tests all broke with an error
similar to this:
Test method UnitTests.Tests.CallTests.Call_GetCallHistoryByMatchID_InvalidMatchIDReturnsEmpty threw exception:
System.InvalidOperationException: The default DbConfiguration instance was used by the Entity Framework before the 'ExecutionStrategyConfiguration' type was discovered. An instance of 'ExecutionStrategyConfiguration' must be set at application start before using any Entity Framework features or must be registered in the application's config file. See http://go.microsoft.com/fwlink/?LinkId=260883 for more information.
ExecutionStrategyConfiguration in my case is the class I made that sets up the transient error handling as described in the tutorials for EF6. It's a simple class that inherits from DbConfiguration and sets up a SqlAzureExecutionStrategy. I banged my head against
the wall for at least 5 hours on this error before finally stumbling across this
Don't know why I didn't realize it sooner, but the problem was that my ExecutionStrategyConfiguration class needed to be loaded into the database instance somehow. (They coded it so that normally you can just place the custom class into the same project as
the database context and it'll get picked up automatically. This doesn't happen if you're loading the context from a different area though.)
The solution ended up requiring two changes, and was adding the following two lines to the testing setup class:
public static void SetUp(TestContext testContext)
// Register the Effort provider and initialize Entity Framework using our custom configuration settings. If we don't do this,
// it can't find the custom configuration properly and will throw an exception.
Hope this is useful for someone. It's too bad the transient error handling doesn't actually work within the unit tests, but I understand why, and it's not a huge issue.