efwrappers Issue Tracker Rss Feed

Created Unassigned: CreateDbCommand throw System.NotSupportedException [8]

sawachikakenji — Tue, 07 May 2013 07:34:46 GMT

protected override DbCommand CreateDbCommand()
{
throw new NotSupportedException();
}

edit after:

protected override DbCommand CreateDbCommand()
{
return this.WrappedConnection.CreateCommand();
}

Commented Issue: The invoked member is not supported in a dynamic assembly. [7]

MatteoSp — Tue, 26 Mar 2013 12:03:14 GMT

Hello,
If your solution contains some dynamic assemblies, you can get an exception:
[NotSupportedException: The invoked member is not supported in a dynamic assembly.]
System.Reflection.Emit.InternalAssemblyBuilder.GetManifestResourceStream(String name) +56

To fix this you must add the check "asm.IsDynamic" to this file
Source\EFProviderWrapperToolkit\EntityConnectionWrapperUtils.cs

at the line 184

foreach (Assembly asm in assembliesToConsider.Where(asm => !IsEcmaAssembly(asm) && !IsSystemAssembly(asm) __&& !asm.IsDynamic__))

Please read this thread, to get an explanation, why it is necessary:
[Here](social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/b8847ef1-be17-404a-b35f-4b693ca23c58)

Thank you for this very useful project, - it helps us really to get track of what is going wrong with sql queries on the database side.
Sincerely,
Yevgeniy Fliegel
Comments: The proposed fix worked for me.

Created Issue: The invoked member is not supported in a dynamic assembly. [7]

febus — Mon, 18 Mar 2013 15:11:43 GMT

Created Issue: Spatial Data Type Support? [6]

rvandehei — Wed, 30 Jan 2013 02:36:32 GMT

When i use the EFTracingProvder and EF5 with a sql server table that contains a Geography datatype, i get the following error when i do a simple linq query against it.

System.Data.ProvderIncompatibleException.

{"The provider did not return a DbSpatialServices instance."}

Should spatial datatypes work with EF5 and the EFTracingProvider?

-Randy

Commented Issue: Support tracing for Code-First [1]

jrummell — Mon, 13 Aug 2012 14:02:15 GMT

I can get it working with the EF 4.1 Database First DbContext T4 templates by adding this constructor:

public abstract class MyDbContext : DbContext
{
protected MyDbContext(string nameOrConnectionString)
: base(EFTracingProviderUtils.CreateTracedEntityConnection(nameOrConnectionString), true)
{
// enable sql tracing
((IObjectContextAdapter) this).ObjectContext.EnableTracing();
}
}

But it doesn't work with Code First because EFTracingProviderUtils.CreateTracedEntityConnection() requires an Entity ConnectionString, not a normal ConnectionString. Is it possible to use a normal (non-EF) ConnectionString?

See http://efwrappers.codeplex.com/discussions/262707 for the full thread.
Comments: This is possible, I gave my solution in the linked thread.

Edited Issue: Support tracing for Code-First [1]

jrummell — Mon, 13 Aug 2012 14:02:15 GMT

Created Issue: Oracle ODP.NET Support [5]

sourishkrout — Sat, 10 Mar 2012 01:54:02 GMT

I got the EFTracingProvider working with Oracle's ODP.NET. Only a few minor changes to both the code base of EFTracingProvider as well as the example code were necessary to get it mostly working.

One problem remains though. Whenever I plugin the EFTracingConnection intead of a OracleConnection somehow the Entity Framework believes it's talking to SQLServer and submits two queries that will in turn fail and produce ugly exceptions (Please see quires below).

I'm sure something in the codebase of the EFTracingProvider makes it believe it'll be necessary to issue those two queries. Anyway, due to the closed source nature of the Entity Framework I find it hard to debug and identify the cause of the issue. I'd love to get this fixed and shared it with other devs who are working with ODP.NET + EF. - Any ideas?

1.) SELECT
"GroupBy1"."A1" AS "C1"
FROM ( SELECT
COUNT(1) AS "A1"
FROM "dbo"."__MigrationHistory" "Extent1"
) "GroupBy1"

2.) SELECT *
FROM (
SELECT
"Project1"."C1" AS "C1",
"Project1"."ModelHash" AS "ModelHash"
FROM ( SELECT
"Extent1"."ModelHash" AS "ModelHash",
CAST( "Extent1"."Id" AS number(10,0)) AS "C1"
FROM "dbo"."EdmMetadata" "Extent1"
) "Project1"
ORDER BY "Project1"."C1" DESC
)
WHERE (ROWNUM <= (1)

Edited Issue: Document disposing behavior [4]

coeamyd — Tue, 13 Dec 2011 17:11:32 GMT

I just discovered a baaaaaad pitfall concerning disposing of contexts when using EFWrappers. Even if you dispose any created ObjectContexts, the connection will NOT be disposed. I checked the ObjectContext class' Dispose implementation, and discovered, that it will only dispose of the inner connection, if it was created by the ObjectContext itself. This only occurs when passing in a connectionString in its constructor. Since the EFWrappers require you to create a context by passing in the connection wrapper, the connection will not be disposed, when the ObjectContext is. What you must instead do is dispose of the wrapped connection yourself. This can be done by overriding the Dispose(bool disposing) method of the context:

protected override void Dispose(bool disposing)
{
var con = this.Connection;

base.Dispose(disposing);

try
{
con.Dispose();
}
catch (ObjectDisposedException)
{
}
}

This should be documented to prevent database connection pile ups.

Created Issue: Document disposing behavior [4]

coeamyd — Tue, 13 Dec 2011 17:11:00 GMT

Commented Issue: Multi-threaded application support [3]

tamasflamich — Fri, 18 Nov 2011 14:05:24 GMT

To be able to use it in a multi threaded application I needed to make a simple modification to the EntityConnectionWrapperUtils.cs file. I added a static lock object at the class level (private static object lockObject = new object();) and then added a lock statement around that if in the CreateEntityConnectionWithWrappers method:

MetadataWorkspace workspace;
lock (lockObject)
{
if (!metadataWorkspaceMemorizer.TryGetValue(ecsb.ConnectionString, out workspace))
{
workspace = CreateWrappedMetadataWorkspace(ecsb.Metadata, wrapperProviders);
metadataWorkspaceMemorizer.Add(ecsb.ConnectionString, workspace);
}
}

If you could update the NuGet package with this fix it would be awesome. Thanks!

Louis
Comments: Note: This bug has been fixes already http://efwrappers.codeplex.com/SourceControl/changeset/changes/495320e30aa1

Created Issue: Multi-threaded application support [3]

lpperras — Thu, 03 Nov 2011 14:23:12 GMT

Created Issue: Issue with dynamic assemblies [2]

lpperras — Thu, 03 Nov 2011 14:11:50 GMT

You get an unhandled exception when you have dynamic assemblies built with Castle or any Mock unit testing system. In the file EntityConnectionWrapperUtils.cs, you should modify the line 188 to verify for dynamic assemblies.

Ex: foreach (Assembly asm in assembliesToConsider.Where(asm => !IsEcmaAssembly(asm) && !IsSystemAssembly(asm) && !asm.IsDynamic))

It would be nice to see the NuGet package updated with this modification. Thanks!

Louis

Created Issue: Support tracing for Code-First [1]

jrummell — Tue, 12 Jul 2011 20:23:30 GMT