Quantcast
Channel: Entity Framework
Viewing all 10318 articles
Browse latest View live

Source code checked in, #95d8e5ef628531aa4ba31cdf6ccaa205a28b383c

0
0
Build: Update $(ProgramFiles)\MSBuild to $(MSBuildExtensionsPath32) Work Item: 2472

Edited Issue: Update EntityDesignPackage.csproj to use MSBuildExtensionsPath32 [2472]

0
0
In src/EFTools/EntityDesignPackage/EntityDesignPackage.csproj, we should be using `$(MSBuildExtensionsPath32)` instead of `$(ProgramFiles)\MSBuild`. `$(ProgramFiles)` is different depending on whether the process is 32-bit or 64-bit.

Commented Issue: EF 6.1.1: Sql CE connection closing even when context owns connection is set to false [2389]

0
0
When using manual managed connection and transaction to sql ce with EF 6.1.1 and EF.SqlServerCompact 6.1.1 every attempt to call transaction.commit results in System.ObjectDisposedException. This occurs both when contextOwnsConnection is set to false and true.

It seems that EF closes underlying connection after first use of DbContext.

Assuming one installs EntityFramework.SqlServerCompact 6.1.1 following code will fail:

```
using (var connection = new SqlCeConnection("DataSource=testdb.sdf"))
{
connection.Open();

using (var transaction = connection.BeginTransaction())
{
using (var dbContext = new ProductsDbContext(connection, false))
{
dbContext.Database.UseTransaction(transaction);

dbContext.Products.Add(new Product() {Name = "newProduct"});
dbContext.SaveChanges();
}

transaction.Commit();
}
}
```

With ProductDbContext and Product defined as follows:
```
public class ProductsDbContext : DbContext
{
public ProductsDbContext(DbConnection dbConnection, bool contextOwnsConnection)
: base(dbConnection, contextOwnsConnection)
{
}

public IDbSet<Product> Products { get; set; }
}

public class Product
{
[Key]
public int Id { get; set; }

[Required]
public string Name { get; set; }
}
```

This works as expected when using EntityFramework.SqlServerCompact 6.1.0

Attached one can find simple console application with failing scenario.

Comments: I agree with Erik. Using the 6.1.2 nightly build I cannot repro this.

Edited Issue: Update EntityDesignPackage.csproj to use MSBuildExtensionsPath32 [2472]

0
0
In src/EFTools/EntityDesignPackage/EntityDesignPackage.csproj, we should be using `$(MSBuildExtensionsPath32)` instead of `$(ProgramFiles)\MSBuild`. `$(ProgramFiles)` is different depending on whether the process is 32-bit or 64-bit.

Commented Issue: Update EntityDesignPackage.csproj to use MSBuildExtensionsPath32 [2472]

0
0
In src/EFTools/EntityDesignPackage/EntityDesignPackage.csproj, we should be using `$(MSBuildExtensionsPath32)` instead of `$(ProgramFiles)\MSBuild`. `$(ProgramFiles)` is different depending on whether the process is 32-bit or 64-bit.
Comments: Fixed in changeset 95d8e5ef628531aa4ba31cdf6ccaa205a28b383c

Commented Unassigned: Allow running migrations contained in an Assembly via console [2440]

0
0
I have a Web project referencing another assembly that contains Entity Framework models, contexts and migrations.

WebProject (Startup project)
=> ModelProject.dll (contains EF models, contexts, migrations).

I know that if ModelProject is added as a project reference (not assembly reference) I can run that migrations by using -ConfigurationTypeName switch, specifying the type name of the Configuration contained in ModelProject, and works like a charm.

In my case, I have multiple main projects that reference the same "common" assembly, that is, my EF models are in a shared assembly.

I would like to run Update-Database cmdlet to run migrations in that external referenced assembly without reference the source code for that project.

My suggestion is add a switch -Assembly to work in conjunct with -ConfigurationTypeName in order to help finding the specified type.
Comments: This doesn't seem to work - we need to know what the startup project assembly. Workaround would be to use migrate.exe tool directly.

Edited Issue: Allow running migrations contained in an Assembly via console [2440]

0
0
I have a Web project referencing another assembly that contains Entity Framework models, contexts and migrations.

WebProject (Startup project)
=> ModelProject.dll (contains EF models, contexts, migrations).

I know that if ModelProject is added as a project reference (not assembly reference) I can run that migrations by using -ConfigurationTypeName switch, specifying the type name of the Configuration contained in ModelProject, and works like a charm.

In my case, I have multiple main projects that reference the same "common" assembly, that is, my EF models are in a shared assembly.

I would like to run Update-Database cmdlet to run migrations in that external referenced assembly without reference the source code for that project.

My suggestion is add a switch -Assembly to work in conjunct with -ConfigurationTypeName in order to help finding the specified type.

Closed Issue: EntityEntry.IsPropertyChanged throws ArgumentOutOfRangeException [2435]

0
0
When I call IsPropertyChanged(string propertyName) on an EntityEntry object whose Entity's property has not been changed an ArgumentOutOfRangeException is thrown.
The property I want to check is of type short.
I use EntityFramework 6.1.1 for .net 4.0.
Creating a debug build from the source I found out that the Exception occurs on line 1935 in EntityEntry.cs. It seems the field _originalValues contains only the original values of the properties that have been changed.

Comments: verified, closing

Closed Issue: EntityKey objects created from a column value do no perform required type mappings [2313]

0
0
I'm in the process of writing a new EF provider. The database engine which this provider is for uses an unsigned 32bit integer for "autoinc" columns. As unsigned types are not supported by EF, these columns (and other unsigned column types) are mapped to the next larger signed integer type in the model.

This generally works correctly for mapping between columns and properties in the model.

But it does not work if the unsigned column is used as an EntityKey.

The EntityKey instances are created inside a compiled expression which was generated by System.Data.Entity.Core.Common.Internal.Materialization.Translator

The problem is in:

internal override TranslatorResult Visit(ScalarColumnMap columnMap, TranslatorArg arg)

When generating expressions for assigning column values to properties, the RequestedType from arg generally matches the type of the property in the model, so for an uint32 column, taking into account the mapping, the requested type would be an int64. Which translates into a call to the GetInt64 method on the DbDataReader to get the value.

But when generating expressions for the construction of an EntityKey instance, the requested type is always "object". This results in a simple call the DbDataReader.GetValue. Which returns a boxed uint32.

That boxed uint32 is then directly passed to the constructor of EntityKey and stored in _singletonKeyValue.

Later a call to ValidateTypeOfKeyValue of the EntityKey object then compares the type of the boxed value (uint32) with the type expected by the model (int64) and raises an InvalidOperationException complaining about an incorrect value type.

I think that if the requested type for a call to Visit(ScalarColumnMap columnMap, TranslatorArg arg) is "object", it should always request the type specified by the column map from the DbDataReader and then box that value.

I've implemented a change to the Visit function that solves the problem for me, but can't say for sure if this is the best way to handle it:

```
internal override TranslatorResult Visit(ScalarColumnMap columnMap, TranslatorArg arg)
{
var type = arg.RequestedType;
var columnType = columnMap.Type;
var columnClrType = DetermineClrType(columnType.EdmType);
bool needsTypeMapping = (type != columnClrType) && (type == typeof(object)) && TypeSemantics.IsPrimitiveType(columnType);
var ordinal = columnMap.ColumnPos;
...
else
{
bool needsNullableCheck;
var readerMethod = CodeGenEmitter.GetReaderMethod(needsTypeMapping ? columnClrType : type, out needsNullableCheck);

result = Expression.Call(CodeGenEmitter.Shaper_Reader, readerMethod, Expression.Constant(ordinal));

if (needsTypeMapping)
result = Expression.Convert(result, type);

...
result = Expression.Convert(result, nonNullableType);
}
else if (type == typeof(object) && !needsTypeMapping)
{
Debug.Assert(
!needsNullableCheck,
...
```
Comments: verified by customer, closing

Edited Issue: [Perf] Regression introduced by changeset 604533a309d7 [2446]

0
0
The introduction of changeset [604533a309d7](https://entityframework.codeplex.com/SourceControl/changeset/604533a309d7e74a38cf9859a3ed2d442ea4d638) regressed model building between 16% and 18% for larger models, as shown by one of our perf tests.

The overall model building time is now to the same levels as EF 6.1.1 since this regression almost exactly matches the improvement made by the fix to #2298. See the attached image for details.

A fix is being worked on.

Closed Issue: [Perf] Regression introduced by changeset 604533a309d7 [2446]

0
0
The introduction of changeset [604533a309d7](https://entityframework.codeplex.com/SourceControl/changeset/604533a309d7e74a38cf9859a3ed2d442ea4d638) regressed model building between 16% and 18% for larger models, as shown by one of our perf tests.

The overall model building time is now to the same levels as EF 6.1.1 since this regression almost exactly matches the improvement made by the fix to #2298. See the attached image for details.

A fix is being worked on.
Comments: verified this when looking at perf for the original issue 2254, closing

Closed Issue: ObjectContext.ExecuteStoreQueryInternal disposes DbCommand too early [2418]

0
0
The ObjectContext.ExecuteStoreQueryInternal diposes the DbCommand too early, before the whole reader is processed. This is causing some issues when the reader needs to talk back to database via the command (like in Firebird).

Related discussion: https://entityframework.codeplex.com/discussions/554609
Comments: verified, closing

New Post: Unable to add annotations to EntityType

Commented Unassigned: MSSQL 2014, Update model are very slow [2445]

0
0
Hello,

I have migrate a project from MSSQL 2012 to MSSQL 2014. I run my application and no problem, all work fine.

I'm Database first with EF. Then I add a new column in a table. Go in the EF Designer and launch "Update model from database". Now, this action take around 30 minutes (versus 1 minute with MSSQL 2012).

I create a new blank EDMX, try "Update model from database" and it's take around 30min.

My config:
Visual Studio Pro 2013 Update 3
.Net Framework 4.5.1
Entity Framework 6.1.1
MS SQL 2014

100 Tables
238 Stored procedures
Comments: The regression was introduced in Sql Server 2014 by a change in their algorithm for cardinality estimation. Enabling flag 9481 changes the algorithm back to what it was in previous version of the product. For more information on how to enable the flag go to http://support.microsoft.com/kb/2801413. The EF designer will be modified to use the 9481 trace flag as a workaround for this performance regression in a future release.

Commented Feature: Designer: Better navigation property names when multiple relationships to the same table [125]

0
0
When multiple relationships to the same table are present the navigation properties are just postfixed with a name. We could consider using the FK name or some other means to make it clearer which is which.

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

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: This is an amazingly painful bug for those of us that have to use existing databases that periodically change. Please provide us a way to customize the navigation naming property on the database side.

Edited Issue: DatabaseLogger throws System.ArgumentOutOfRangeException [2468]

0
0
Can you please make a Thread safe StreamWriter?

System.ArgumentOutOfRangeException
Message Count cannot be less than zero. Parameter name: count
Source mscorlib
TargetSite Void CopyTo(Int32, Char[], Int32, Int32)
StackTrace at System.String.CopyTo(Int32 sourceIndex, Char[] destination, Int32 destinationIndex, Int32 count) at System.IO.StreamWriter.Write(String value) at System.Data.Entity.Infrastructure.Interception.DatabaseLogFormatter.Opened(DbConnection connection, DbConnectionInterceptionContext interceptionContext) at System.Data.Entity.Infrastructure.Interception.InternalDispatcher`1.<>c__DisplayClass3`2.<DispatchAsync>b__2(Task t) --- 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.Data.Entity.SqlServer.DefaultSqlExecutionStrategy.<>c__DisplayClass4.<<ExecuteAsync>b__3>d__6.MoveNext() --- 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.Data.Entity.SqlServer.DefaultSqlExecutionStrategy.<ExecuteAsyncImplementation>d__9`1.MoveNext() --- 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.Data.Entity.Core.EntityClient.EntityConnection.<OpenAsync>d__8.MoveNext


Env:
EntityFramework version="6.1.1"

<interceptors>
<interceptor type="System.Data.Entity.Infrastructure.Interception.DatabaseLogger, EntityFramework">
<parameters>
<parameter value="D:\Logs\LogOutput.txt"/>
</parameters>
</interceptor>
</interceptors>


Edited Issue: MSSQL 2014, Update model are very slow [2445]

0
0
Hello,

I have migrate a project from MSSQL 2012 to MSSQL 2014. I run my application and no problem, all work fine.

I'm Database first with EF. Then I add a new column in a table. Go in the EF Designer and launch "Update model from database". Now, this action take around 30 minutes (versus 1 minute with MSSQL 2012).

I create a new blank EDMX, try "Update model from database" and it's take around 30min.

My config:
Visual Studio Pro 2013 Update 3
.Net Framework 4.5.1
Entity Framework 6.1.1
MS SQL 2014

100 Tables
238 Stored procedures

Commented Issue: [Perf] Calling GetProviderManifestToken against invalid db server takes several minutes to error out [2462]

0
0
As part of investigating [workitem 2445](https://entityframework.codeplex.com/workitem/2445) I realized that when you click on "Update Model from Database...", the designer does some work to figure out things about the database it's running against, including a call to providerServices.GetProviderManifestToken.

If people change the connection string to an invalid one in their app.config (as I did), and then try to update their model, then the call to GetProviderManifestToken might take as long as 10 minutes doing nothing but retrying and getting exceptions at the SqlClient level. The exception never bubbles up to the user level but it's easy to capture it as a first-chance exception.

The following code demonstrates this performance issue. Note that the database server has to be non-existent, and this example assumes there's no KartServer instance of SqlServer in your network.

``` C#
using System;
using System.Data.Entity.SqlServer;
using System.Data.SqlClient;
using System.Diagnostics;

namespace ConsoleApplication14
{
class Program
{
static void Main(string[] args)
{
var providerServices = SqlProviderServices.Instance;
var dbConnection = new SqlConnection("Data Source=KartServer;Initial Catalog=RainbowWorld;uid=Mario;pwd=Yoshi;Connection Timeout=300;");

var sw = new Stopwatch();
sw.Start();
var providerManifestToken = providerServices.GetProviderManifestToken(dbConnection);
sw.Stop();
Console.WriteLine("Provider Manifest Token: {0} obtained in {1}ms", providerManifestToken, sw.ElapsedMilliseconds);
}
}
}
```
Comments: Looked into this using the model above and the original model that was causing the issue. It looks like the problem is actually that the connection string specifies "Connection Timeout=300". If you change that to a small number e.g. 5 - then the wizard appears after about 20 secs. When we do "Update Model from DB" we need to find out if the existing connection string works - so as to decide which page of the wizard to direct you to. We end up calling DatabaseEngineBase.CanCreateAndOpenConnection() which in turn calls through the VersioningFacade to call SqlProviderServices.GetProviderManifestToken(). This method first tries to connect using the connection string passed in. If that doesn't work it tries again but connecting to InitialCatalog=master. Other than this there is no repetition - and we can't remove that fallback. Unfortunately it seems to take approximately twice as long as the connection timeout for the connection to realize it has timed out and the we try both normal and master conncetions - so ~4 times the connection timeout.. Since the connection timeout is set to 300s above it ~20 mins for both attempts to fail. If you set the connection timeout to ~5s it takes ~20s. After talking this through with Dave we decided that this is the expected behavior - so closing as by design.

Closed Issue: [Perf] Calling GetProviderManifestToken against invalid db server takes several minutes to error out [2462]

0
0
As part of investigating [workitem 2445](https://entityframework.codeplex.com/workitem/2445) I realized that when you click on "Update Model from Database...", the designer does some work to figure out things about the database it's running against, including a call to providerServices.GetProviderManifestToken.

If people change the connection string to an invalid one in their app.config (as I did), and then try to update their model, then the call to GetProviderManifestToken might take as long as 10 minutes doing nothing but retrying and getting exceptions at the SqlClient level. The exception never bubbles up to the user level but it's easy to capture it as a first-chance exception.

The following code demonstrates this performance issue. Note that the database server has to be non-existent, and this example assumes there's no KartServer instance of SqlServer in your network.

``` C#
using System;
using System.Data.Entity.SqlServer;
using System.Data.SqlClient;
using System.Diagnostics;

namespace ConsoleApplication14
{
class Program
{
static void Main(string[] args)
{
var providerServices = SqlProviderServices.Instance;
var dbConnection = new SqlConnection("Data Source=KartServer;Initial Catalog=RainbowWorld;uid=Mario;pwd=Yoshi;Connection Timeout=300;");

var sw = new Stopwatch();
sw.Start();
var providerManifestToken = providerServices.GetProviderManifestToken(dbConnection);
sw.Stop();
Console.WriteLine("Provider Manifest Token: {0} obtained in {1}ms", providerManifestToken, sw.ElapsedMilliseconds);
}
}
}
```

Edited Issue: [Perf] Calling GetProviderManifestToken against invalid db server takes several minutes to error out [2462]

0
0
As part of investigating [workitem 2445](https://entityframework.codeplex.com/workitem/2445) I realized that when you click on "Update Model from Database...", the designer does some work to figure out things about the database it's running against, including a call to providerServices.GetProviderManifestToken.

If people change the connection string to an invalid one in their app.config (as I did), and then try to update their model, then the call to GetProviderManifestToken might take as long as 10 minutes doing nothing but retrying and getting exceptions at the SqlClient level. The exception never bubbles up to the user level but it's easy to capture it as a first-chance exception.

The following code demonstrates this performance issue. Note that the database server has to be non-existent, and this example assumes there's no KartServer instance of SqlServer in your network.

``` C#
using System;
using System.Data.Entity.SqlServer;
using System.Data.SqlClient;
using System.Diagnostics;

namespace ConsoleApplication14
{
class Program
{
static void Main(string[] args)
{
var providerServices = SqlProviderServices.Instance;
var dbConnection = new SqlConnection("Data Source=KartServer;Initial Catalog=RainbowWorld;uid=Mario;pwd=Yoshi;Connection Timeout=300;");

var sw = new Stopwatch();
sw.Start();
var providerManifestToken = providerServices.GetProviderManifestToken(dbConnection);
sw.Stop();
Console.WriteLine("Provider Manifest Token: {0} obtained in {1}ms", providerManifestToken, sw.ElapsedMilliseconds);
}
}
}
```
Viewing all 10318 articles
Browse latest View live




Latest Images