Commented Feature: Code First: Allow timeout to be set for DbSet.SqlQuery [59]

March 25, 2013, 9:44 am

≫ Next: Closed Task: Removing/re-adding EF nuget package updates app.config, which can be confusing if code based configuration is used [797]

≪ Previous: Edited Feature: Code First: Allow timeout to be set for DbSet.SqlQuery [59]

This item was migrated from the DevDiv work item tracking system [ID=307945].

Comments: Fixed in c43e3bf466a0 TimeGotTheTimeTickTickTickinInMyHead (Add first-class support for CommandTimeout in DbContext) It was previously possible to set the CommandTimeout for most operations by dropping down to ObjectContext. This change introduces a property of context.Database.CommandTimeout which will be used for all operations of the context. This includes DDL and implicit Migrations operations. Static (i.e. non-context) DDL methods on database obviously don't use this timeout. DbMigrationsConfiguration already contained a CommandTimeout property used when running Migrations. This is now also used for history context operations.

↧

Closed Task: Removing/re-adding EF nuget package updates app.config, which can be confusing if code based configuration is used [797]

March 25, 2013, 9:49 am

≫ Next: Closed Task: Rename WrapService to ReplaceService [942]

≪ Previous: Commented Feature: Code First: Allow timeout to be set for DbSet.SqlQuery [59]

Per current design of EF, many configuration settings can be configured via both app.config and code based config (DbConfiguration.) App.config based configuration has priority over code based configuration.

One example where this has confused me while testing various scenarios is the DefaultConnectionFactory.

I have a code based configuration which sets DefaultConectionFactory to LocalDbConnectionFactory:

```
public class MyConfiguration : DbConfiguration
{
public MyConfiguration()
{
SetDefaultConnectionFactory(new LocalDbConnectionFactory("v11.0"));
}
}
```

From app.config, I removed (commented out) the relevant section, which sets SqlConnectionFactory as the default:

``

If I remove/re-add EF nuget package to the project again (which is common during testing), this section gets automatically added to app.config file. Unless I remember to go back and remove it again, my database will be in SqlExpress, while I (incorrectly) expect it to be LocalDb, based on the code I'm seeing on my screen.

Perhaps we can detect that there's code based configuration, and warn the user that their app.config is being updated, and she should probably take an action?

↧

Closed Task: Rename WrapService to ReplaceService [942]

March 25, 2013, 9:52 am

≫ Next: Source code checked in, #f986cb32d0a3

≪ Previous: Closed Task: Removing/re-adding EF nuget package updates app.config, which can be confusing if code based configuration is used [797]

Per design meeting: the intention of the WrapService method provided for OnLockingConfiguration is to allow an existing service to be wrapped by a new service. However, the new service does not need to wrap the existing service—it could instead just replace it. Therefore we will change the name to ReplaceService to reflect this more general applicability.

↧

Source code checked in, #f986cb32d0a3

March 25, 2013, 10:19 am

≫ Next: Commented Task: Remove InternalsVisibleTo EntityFramework from FunctionalTests [224]

≪ Previous: Closed Task: Rename WrapService to ReplaceService [942]

StayInLinePlease (Make newsequentialid() default for store-generated GUID columns) This change makes newsequentialid() instead of newid() the default for SQL Server store-generated GUID columns created with Migrations except for SQL Azure where newsequentialid() is not supported. A new provider manifest token for Azure was required to allow Migrations to know when Azure is being targeted rather than on-premises SQL Server. Also included here is the fix for CodePlex 202 where SqlProviderServices was assuming that the StoreItemCollection contains a SqlProviderManifest. This is fixed by asking the database for the version during the create call rather than getting the version from the item collection. It is possible that this could result in different behavior if the item collection was ceated for a database version different than the one actually being used, but if this does happen the behavior is more likely to be correct (i.e. not throw/work well) now than it was before.

↧

Commented Task: Remove InternalsVisibleTo EntityFramework from FunctionalTests [224]

March 25, 2013, 10:21 am

≫ Next: Created Issue: AutoAndGenerateScenarios seem to run twice against SQL Server and never against SQL Compact [986]

≪ Previous: Source code checked in, #f986cb32d0a3

The object model for EDM needs to be made public before this can occur.

This item was migrated from the DevDiv work item tracking system [ID=346041].

Comments: Note that the EntityFramework.SQLServer assembly still has internals visible to the non-transitional functional tests.

↧

Created Issue: AutoAndGenerateScenarios seem to run twice against SQL Server and never against SQL Compact [986]

March 25, 2013, 10:25 am

≫ Next: Edited Issue: SqlClientProviderServices may throw System.ArgumentException: The provider manifest given is not of type 'System.Data.SqlClient.SqlProviderManifest' [202]

≪ Previous: Commented Task: Remove InternalsVisibleTo EntityFramework from FunctionalTests [224]

It was my understanding that these tests would run foe the following combinations:
* SQL Server, C#
* SQL Compact, C#
* SQL Server, VB

and I seem to remember seeing this behavior in the past, but currently they instead seem to be repeating a SQL Server run and missing the SQL Compact run:

* SQL Server, C#
* SQL Server, C#
* SQL Server, VB

↧

Edited Issue: SqlClientProviderServices may throw System.ArgumentException: The provider manifest given is not of type 'System.Data.SqlClient.SqlProviderManifest' [202]

March 25, 2013, 10:44 am

≫ Next: Commented Issue: SqlClientProviderServices may throw System.ArgumentException: The provider manifest given is not of type 'System.Data.SqlClient.SqlProviderManifest' [202]

≪ Previous: Created Issue: AutoAndGenerateScenarios seem to run twice against SQL Server and never against SQL Compact [986]

↧

Commented Issue: SqlClientProviderServices may throw System.ArgumentException: The provider manifest given is not of type 'System.Data.SqlClient.SqlProviderManifest' [202]

March 25, 2013, 10:44 am

≫ Next: Edited Feature: Use NEWSEQUENTIALID() instead of NEWID() for GUID keys [71]

≪ Previous: Edited Issue: SqlClientProviderServices may throw System.ArgumentException: The provider manifest given is not of type 'System.Data.SqlClient.SqlProviderManifest' [202]

"SqlClientProviderServices is using StoreItemCollection.StoreProviderManifest to get store provider manifest checks if this is a SqlProviderManifest, and if it is not then it throws. There are a few issues with this:
- for wrapping providers (vide EFCaching/EFTracing providers) it does not work since the manifest stored in StoreProviderManifest is acutally a manifest wrapping SqlProviderManifest
- StoreItemCollection.StoreProviderManifest is an internal field - it means that SqlClientProviderServices is able to see what a third party provider is not able to see
- SqlClientProviderServices is kind of breaking a contract by trying to upcast StoreProviderManifest to SqlProviderManifest - we probably should work with just DbProviderManifest

The above may indicate that either there is a problem with SqlClientProviderServices et al or the design of our provider model is broken and SqlClientProviderServices is working around these problems
The above shows up immediately when using CodeFirst since the code that causes problems is in CreateDatabase() code path but we should also review other places to see if we are using non-public methods or make assumptions that don't have to be true."

This item was migrated from the DevDiv work item tracking system [ID=385243].

Comments: Fixed in f986cb32d0a3 StayInLinePlease (Make newsequentialid() default for store-generated GUID columns) This change makes newsequentialid() instead of newid() the default for SQL Server store-generated GUID columns created with Migrations except for SQL Azure where newsequentialid() is not supported. A new provider manifest token for Azure was required to allow Migrations to know when Azure is being targeted rather than on-premises SQL Server. Also included here is the fix for CodePlex 202 where SqlProviderServices was assuming that the StoreItemCollection contains a SqlProviderManifest. This is fixed by asking the database for the version during the create call rather than getting the version from the item collection. It is possible that this could result in different behavior if the item collection was ceated for a database version different than the one actually being used, but if this does happen the behavior is more likely to be correct (i.e. not throw/work well) now than it was before.

↧

Edited Feature: Use NEWSEQUENTIALID() instead of NEWID() for GUID keys [71]

March 25, 2013, 10:45 am

≫ Next: Commented Feature: Use NEWSEQUENTIALID() instead of NEWID() for GUID keys [71]

≪ Previous: Commented Issue: SqlClientProviderServices may throw System.ArgumentException: The provider manifest given is not of type 'System.Data.SqlClient.SqlProviderManifest' [202]

↧

Commented Feature: Use NEWSEQUENTIALID() instead of NEWID() for GUID keys [71]

March 25, 2013, 10:45 am

≫ Next: Edited Issue: Cannot use a property with a private setter that is declared in a non-mapped base types as key for an entity set [137]

≪ Previous: Edited Feature: Use NEWSEQUENTIALID() instead of NEWID() for GUID keys [71]

This item was migrated from the DevDiv work item tracking system [ID=32229].

This work item originated from connect.microsoft.com. A member of the EF team at Microsoft should close the related Connect issue when closing this work item.

Comments: Fixed in f986cb32d0a3 StayInLinePlease (Make newsequentialid() default for store-generated GUID columns) This change makes newsequentialid() instead of newid() the default for SQL Server store-generated GUID columns created with Migrations except for SQL Azure where newsequentialid() is not supported. A new provider manifest token for Azure was required to allow Migrations to know when Azure is being targeted rather than on-premises SQL Server. Also included here is the fix for CodePlex 202 where SqlProviderServices was assuming that the StoreItemCollection contains a SqlProviderManifest. This is fixed by asking the database for the version during the create call rather than getting the version from the item collection. It is possible that this could result in different behavior if the item collection was ceated for a database version different than the one actually being used, but if this does happen the behavior is more likely to be correct (i.e. not throw/work well) now than it was before.

↧

Edited Issue: Cannot use a property with a private setter that is declared in a non-mapped base types as key for an entity set [137]

March 25, 2013, 10:48 am

≫ Next: New Post: Registering providers globally with code during runtime

≪ Previous: Commented Feature: Use NEWSEQUENTIALID() instead of NEWID() for GUID keys [71]

"The following scenario in which the entity set is of the base type works as expected:
using System.Data.Entity;

namespace ConsoleApplication13
{
class Program
{
static void Main(string[] args)
{
using (var context = new MyContext())
{
context.Customers.Add(new Customer() { Name = ""a"" });
context.SaveChanges();
}
}
}

public class BaseEntity
{
public int Id { get; private set; }
}

public class Customer : BaseEntity
{
public string Name { get; set; }
}

public class MyContext : DbContext
{
//public DbSet<Customer> Customers { get; set; }
public DbSet<BaseEntity> Customers { get; set; }

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
base.OnModelCreating(modelBuilder);
//modelBuilder.Entity<Customer>().HasKey(e => e.Id);
}
}
}

Changing the code to make the entity set of the derived type as follows:
using System.Data.Entity;

namespace ConsoleApplication13
{
class Program
{
static void Main(string[] args)
{
using (var context = new MyContext())
{
context.Customers.Add(new Customer() { Name = ""a"" });
context.SaveChanges();
}
}
}

public class BaseEntity
{
public int Id { get; private set; }
}

public class Customer : BaseEntity
{
public string Name { get; set; }
}

public class MyContext : DbContext
{
public DbSet<Customer> Customers { get; set; }
//public DbSet<BaseEntity> Customers { get; set; }

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
base.OnModelCreating(modelBuilder);
//modelBuilder.Entity<Customer>().HasKey(e => e.Id);
}
}
}

Causes the following exception to be thrown in the line containg the call to the Add method (notice the non-text characters used in the exception message):

System.Data.Entity.ModelConfiguration.ModelValidationException was unhandled
Message=One or more validation errors were detected during model generation:
System.Data.Edm.EdmEntityType: : EntityType 'Customer' has no key defined. Define the key for this EntityType.
System.Data.Edm.EdmEntitySet: EntityType: EntitySet �Customers� is based on type �Customer� that has no keys defined.
Source=EntityFramework
StackTrace:
at System.Data.Entity.ModelConfiguration.Edm.EdmModelExtensions.ValidateAndSerializeCsdl(EdmModel model, XmlWriter writer)
at System.Data.Entity.ModelConfiguration.Edm.EdmModelExtensions.ValidateCsdl(EdmModel model)
at System.Data.Entity.DbModelBuilder.Build(DbProviderManifest providerManifest, DbProviderInfo providerInfo)
at System.Data.Entity.DbModelBuilder.Build(DbConnection providerConnection)
at System.Data.Entity.Internal.LazyInternalContext.CreateModel(LazyInternalContext internalContext)
at System.Data.Entity.Internal.RetryLazy`2.GetValue(TInput input)
at System.Data.Entity.Internal.LazyInternalContext.InitializeContext()
at System.Data.Entity.Internal.InternalContext.Initialize()
at System.Data.Entity.Internal.InternalContext.GetEntitySetAndBaseTypeForType(Type entityType)
at System.Data.Entity.Internal.Linq.InternalSet`1.Initialize()
at System.Data.Entity.Internal.Linq.InternalSet`1.get_InternalContext()
at System.Data.Entity.Internal.Linq.InternalSet`1.ActOnSet(Action action, EntityState newState, Object entity, String methodName)
at System.Data.Entity.Internal.Linq.InternalSet`1.Add(Object entity)
at System.Data.Entity.DbSet`1.Add(TEntity entity)
at ConsoleApplication13.Program.Main(String[] args) in C:\Users\divega\Documents\Visual Studio 2010\Projects\ConsoleApplication13\ConsoleApplication13\Program.cs:line 11
at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
InnerException:

Finally, uncommenting the line containing the call to HasKey in the OnModelCreating method as follows:
using System.Data.Entity;

namespace ConsoleApplication13
{
class Program
{
static void Main(string[] args)
{
using (var context = new MyContext())
{
context.Customers.Add(new Customer() { Name = ""a"" });
context.SaveChanges();
}
}
}

public class BaseEntity
{
public int Id { get; private set; }
}

public class Customer : BaseEntity
{
public string Name { get; set; }
}

public class MyContext : DbContext
{
public DbSet<Customer> Customers { get; set; }
//public DbSet<BaseEntity> Customers { get; set; }

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
base.OnModelCreating(modelBuilder);
modelBuilder.Entity<Customer>().HasKey(e => e.Id);
}
}
}

Causes the following exception in the line containing the call to the Add method:

System.InvalidOperationException was unhandled
Message=The key component 'Id' is not a declared property on type 'Customer'. Verify that it has not been explicitly excluded from the model and that it is a valid primitive property.
Source=EntityFramework
StackTrace:
at System.Data.Entity.ModelConfiguration.Configuration.Types.EntityTypeConfiguration.ConfigureKey(EdmEntityType entityType)
at System.Data.Entity.ModelConfiguration.Configuration.Types.EntityTypeConfiguration.Configure(EdmEntityType entityType, EdmModel model)
at System.Data.Entity.ModelConfiguration.Configuration.ModelConfiguration.ConfigureEntities(EdmModel model)
at System.Data.Entity.ModelConfiguration.Configuration.ModelConfiguration.Configure(EdmModel model)
at System.Data.Entity.DbModelBuilder.Build(DbProviderManifest providerManifest, DbProviderInfo providerInfo)
at System.Data.Entity.DbModelBuilder.Build(DbConnection providerConnection)
at System.Data.Entity.Internal.LazyInternalContext.CreateModel(LazyInternalContext internalContext)
at System.Data.Entity.Internal.RetryLazy`2.GetValue(TInput input)
at System.Data.Entity.Internal.LazyInternalContext.InitializeContext()
at System.Data.Entity.Internal.InternalContext.Initialize()
at System.Data.Entity.Internal.InternalContext.GetEntitySetAndBaseTypeForType(Type entityType)
at System.Data.Entity.Internal.Linq.InternalSet`1.Initialize()
at System.Data.Entity.Internal.Linq.InternalSet`1.get_InternalContext()
at System.Data.Entity.Internal.Linq.InternalSet`1.ActOnSet(Action action, EntityState newState, Object entity, String methodName)
at System.Data.Entity.Internal.Linq.InternalSet`1.Add(Object entity)
at System.Data.Entity.DbSet`1.Add(TEntity entity)
at ConsoleApplication13.Program.Main(String[] args) in C:\Users\divega\Documents\Visual Studio 2010\Projects\ConsoleApplication13\ConsoleApplication13\Program.cs:line 11
at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
InnerException:

I have investigated the issue and found that this is because we require properties to have a setter (even private), but if the property is obtained from an inheriting type, not the declaring type, and there is only a private setter on the declaring type we fail to recognize that. This assumption is scattered in many places: code first, ObjectItemConventionAssemblyLoader, materialization (translator). While I have prototyped a fix that passes “dp run”, the change seems risky to me for RC. My main worry is that there may be many other places were this assumption is made that we may not be seeing/catching. In addition is would be a breaking change, as we would be mapping properties that we did not map/”see” before: i.e. properties with these characteristics.

(There is a prototype of this bug fix already. Details are included in the internal bug entry)
"

This item was migrated from the DevDiv work item tracking system [ID=323531].

↧

New Post: Registering providers globally with code during runtime

March 25, 2013, 11:32 am

≫ Next: New Post: Unit testing with EFa3

≪ Previous: Edited Issue: Cannot use a property with a private setter that is declared in a non-mapped base types as key for an entity set [137]

@tamasflamich DbConfiguration holds the app-domain wide (I.e. global) configuration for EF. It is therefore the correct place to register an EF provider. However, note that with the decoupling of the EF provider (DbProviderServices) from the ADO.NET provider (DbProviderFactory) it is necessary to register both of these. The ADO.NET provider is still obtained from the config file registration above, although this can be bypassed if necessary. The EF provider is registered using one of the AddDbProviderServices methods on DbConfiguration.

Thanks,
Arthur

↧

New Post: Unit testing with EFa3

March 25, 2013, 1:01 pm

≫ Next: Reviewed: Entity Framework 6.0.0 (三月 26, 2013)

≪ Previous: New Post: Registering providers globally with code during runtime

Got it working. AsyncEnumerableQuery needed a Provider wrapper too. Change the AsyncEnumerableQuery<T> class above with this:

    public class AsyncEnumerableQuery<T> : EnumerableQuery<T>, IDbAsyncEnumerable<T>, IQueryable
    {
        public AsyncEnumerableQuery(IEnumerable<T> enumerable)
            : base(enumerable)
        {
        }

        public AsyncEnumerableQuery(Expression expression)
            : base(expression)
        {
        }

        public IDbAsyncEnumerator<T> GetAsyncEnumerator()
        {
            return new AsyncEnumeratorWrapper<T>(this.AsEnumerable().GetEnumerator());
        }

        IDbAsyncEnumerator IDbAsyncEnumerable.GetAsyncEnumerator()
        {
            return GetAsyncEnumerator();
        }

        IQueryProvider IQueryable.Provider
        {
            get { return new AsyncQueryProviderWrapper<T>(this); }
        }
    }

↧

Reviewed: Entity Framework 6.0.0 (三月 26, 2013)

March 26, 2013, 3:31 am

≫ Next: Created Issue: DisplayAttribute Name property called instead of GetName [988]

≪ Previous: New Post: Unit testing with EFa3

Rated 5 Stars (out of 5) - aaaadfsfsdfsdfsdfs

↧

Created Issue: DisplayAttribute Name property called instead of GetName [988]

March 26, 2013, 7:27 am

≫ Next: Commented Issue: EF 6 and SQL Azure Federations [978]

≪ Previous: Reviewed: Entity Framework 6.0.0 (三月 26, 2013)

At line 15 of class System.Data.Entity.Utilities.ValidationContextExtensions.cs, you are using the property Name instead of calling the method GetName to get a localized string of the display name. This means that the ResourceType of the DisplayAttribute is ignored and will return the name of the resource instead of the localized resource.

Now: var displayName = displayAttribute == null ? null : displayAttribute.Name;
Should be: var displayName = displayAttribute == null ? null : displayAttribute.GetName();

↧

Commented Issue: EF 6 and SQL Azure Federations [978]

March 26, 2013, 8:53 am

≫ Next: Edited Issue: InvalidOperationException now that MARS is off by default [979]

≪ Previous: Created Issue: DisplayAttribute Name property called instead of GetName [988]

Hi,

I'm currently working on a new project with EF6 (ntityFramework 6.0.0-alpha3) and I encounter a problem with the SQL Azure federations...

According to [this article (2013-01-07)](http://msdn.microsoft.com/en-us/library/windowsazure/hh703245.aspx), I send the USE statement and I open a new transaction:

```
using (TestEntities dc = new TestEntities())
{
((IObjectContextAdapter)dc).ObjectContext.Connection.Open();
dc.Database.ExecuteSqlCommand(@"USE FEDERATION TestFederation (FederationKey=0) WITH FILTERING = OFF, RESET"); // Exception occurs here

using (TransactionScope scope = new TransactionScope(TransactionScopeOption.RequiresNew))
{
[.......]
scope.Complete();
}
}
```

With Entity Framework 5 installed, the "USE FEDERATION..." is accepted but with Entity Framework 6 (same code, juste a different version of EF), an exception occurs: "USE FEDERATION statement not allowed within multi-statement transaction."

Anyone has a idea why it does not work?

Thanks in advance!
Comments: Hello, Thanks for raising this issue. We will be discussing it in an upcoming design meeting. In the meanwhile, one possible workaround would be to execute the command on the database connection directly, e.g. (I haven't compiled nor tested this code snippet but something similar should work): var connection = dc.Database.Connection; var command = connection.CreateCommand(); command.CommandText = @"USE FEDERATION TestFederation (FederationKey=0) WITH FILTERING = OFF, RESET"; connection.Open(); command.ExecuteNonQuery(); connection.Close(); You may as well encapsulate this in a method that would allow you to switch to different federation member.

↧

Edited Issue: InvalidOperationException now that MARS is off by default [979]

March 26, 2013, 8:55 am

≫ Next: Edited Issue: EF 6 and SQL Azure Federations [978]

≪ Previous: Commented Issue: EF 6 and SQL Azure Federations [978]

Hi

I recently upgraded to EF6 alpha 3 and I started receiving an exception when running my integration tests.

It took me a while to track it down, but I believe it is caused by the changeset [22ed3cab3f43](http://entityframework.codeplex.com/SourceControl/changeset/22ed3cab3f43) which changed MARS to be off by default.

I'm receiving an exception when making two asynchronous requests using the new asyc support in EF6. Below is the stack trace

```
System.Data.Entity.Core.EntityCommandExecutionException: An error occurred while executing the command definition. See the inner exception for details. ---> System.InvalidOperationException: The connection does not support MultipleActiveResultSets.
at System.Data.SqlClient.SqlCommand.<ExecuteDbDataReaderAsync>b__24(Task`1 result)
at System.Threading.Tasks.ContinuationResultTaskFromResultTask`2.InnerInvoke()
at System.Threading.Tasks.Task.Execute()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1.ConfiguredTaskAwaiter.GetResult()
at System.Data.Entity.Core.EntityClient.Internal.EntityCommandDefinition.<ExecuteStoreCommandsAsync>d__c.MoveNext()
--- End of inner exception stack trace ---
at Machine.Specifications.TaskSpecificationExtensions.Await[T](Task`1 task)
```

I can very easily get past the issue by enabling MARS explicitly, (below is the app.config of the integration test project), but the reason I'm raising this is that if async requires MARS, is it correct to have it disabled by default.

FYI app.config to fix the issue

``` xml
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
</configSections>
<entityFramework>
<defaultConnectionFactory type="System.Data.Entity.Infrastructure.LocalDbConnectionFactory, EntityFramework">
<parameters>
<parameter value="v11.0" />
<parameter value="Integrated Security=True;MultipleActiveResultSets=True" />
</parameters>
</defaultConnectionFactory>
</entityFramework>
</configuration>
```

↧

Edited Issue: EF 6 and SQL Azure Federations [978]

March 26, 2013, 10:29 am

≫ Next: Commented Issue: EF 6 and SQL Azure Federations [978]

≪ Previous: Edited Issue: InvalidOperationException now that MARS is off by default [979]

↧

Commented Issue: EF 6 and SQL Azure Federations [978]

March 26, 2013, 10:29 am

≫ Next: Edited Task: Async: Implement API Review Action Items [962]

≪ Previous: Edited Issue: EF 6 and SQL Azure Federations [978]

Hi,

I'm currently working on a new project with EF6 (ntityFramework 6.0.0-alpha3) and I encounter a problem with the SQL Azure federations...

According to [this article (2013-01-07)](http://msdn.microsoft.com/en-us/library/windowsazure/hh703245.aspx), I send the USE statement and I open a new transaction:

```
using (TestEntities dc = new TestEntities())
{
((IObjectContextAdapter)dc).ObjectContext.Connection.Open();
dc.Database.ExecuteSqlCommand(@"USE FEDERATION TestFederation (FederationKey=0) WITH FILTERING = OFF, RESET"); // Exception occurs here

using (TransactionScope scope = new TransactionScope(TransactionScopeOption.RequiresNew))
{
[.......]
scope.Complete();
}
}
```

With Entity Framework 5 installed, the "USE FEDERATION..." is accepted but with Entity Framework 6 (same code, juste a different version of EF), an exception occurs: "USE FEDERATION statement not allowed within multi-statement transaction."

Anyone has a idea why it does not work?

Thanks in advance!
Comments: Hello, Thanks for raising this issue. We will be discussing it in an upcoming design meeting. In the meanwhile, one possible workaround would be to execute the command on the database connection directly, e.g. (I haven't compiled nor tested this code snippet but something similar should work): ``` var connection = dc.Database.Connection; var command = connection.CreateCommand(); command.CommandText = @"USE FEDERATION TestFederation (FederationKey=0) WITH FILTERING = OFF, RESET"; if (connection.State!=ConnectionState.Open) connection.Open(); command.ExecuteNonQuery(); ``` You may as well encapsulate this in a method that would allow you to switch to different federation member.

↧

Edited Task: Async: Implement API Review Action Items [962]

March 26, 2013, 11:36 am

≫ Next: New Comment on "Code First Insert/Update/Delete Stored Procedure Mapping"

≪ Previous: Commented Issue: EF 6 and SQL Azure Federations [978]

See [async API review design meeting notes](http://entityframework.codeplex.com/wikipage?title=Design%20Meeting%20Notes%20-%20March%2018%2c%202013) for more details.

* [Rowan] Review and standardize use of <T> and <TSource> in IQueryableExtensions
* [Andriy] Remove generic on DbRawSqlQuery.ToList and just make it return a non-generic list.
* [Andriy] Add ReloadAsync to DbEntityEntry and DbEntityEntry<TEntity>
* [Andriy] The methods on IExecutionStrategy that don't take a CancellationToken can be changed to extension methods. They should go in the .Infrastrucutre sub-namespace. This makes them less discoverable but they are mostly just used by our stack anyway (and passing CancellationToken.None isn't so bad if you don't find them).
* [Andriy] Rename 'taskFunc' parameters on IExecutionStrategy (and related implementations) to match the non-async method parameter names.
* [Andriy] IDbAsyncEnumeratorExtensions and IDbAsyncQueryProviderExtensions should be made internal.
* [Andriy] Remove IRelatedEndExtensions. We don't use them internally and we don't really expect folks to interact with related ends very often.
* [Andriy] Remove the non-CancellationToken overloads on DbSpatialDataReader as we don't use them internally and we don't expect folks to really interact with DbSpatialDataReader.
* [Andriy] Update IQueryable_Not_Async message to: The source IQueryable doesn't implement IDbAsyncEnumerable{0}. Only sources that implement IDbAsyncEnumerable can be used for Entity Framework asynchronous operations. For more details see http://go.microsoft.com/fwlink/?LinkId=287068.
* [Andriy] Update IQueryable_Provider_Not_Async message to: The provider for the source IQueryable doesn't implement IDbAsyncQueryProvider. Only providers that implement IDbAsyncQueryProvider can be used for Entity Framework asynchronous operations. For more details see http://go.microsoft.com/fwlink/?LinkId=287068.
* [Andriy] Update ConcurrentMethodInvocation message to: A second operation started on this context before a previous asynchronous operation completed. Use 'await' to ensure that any asynchronous operations have completed before calling another method on this context. Any instance members are not guaranteed to be thread safe.

There are also two documentation tasks tracked by separate issues:
* http://entityframework.codeplex.com/workitem/964
* http://entityframework.codeplex.com/workitem/963

↧