When Entity Framework June 2011 CTP was out, we were asked by our users to provide support for it in the Entity Framework Profiler.

As we started to investigate how to provide support for it, we discovered that it’s not that easy task to do. The way that Entity Framework Profiler appender works in nutshell is by replacing the instances of DbProviderFactory (like SqlClientFactory or OracleClientFactory) that the client has on his machine with a custom provider factory that wrap the original provider factory. This wasn’t easy task to do, because Entity Framework June CTP made a few assumptions that make our life more complicated. Specifically:

• There is an assumption that the provider factory type is not a generic type. This broke our code which is uses a generic provider factory type which wrap each of the providers factories that the client have on the fly, since the client can use any provider factory that he wants.
• Even if we use non-generic providers for each of the client’s providers, we found out that each provider should be compiled in a separate assembly because of the way that Entity Framework matches providers.

We’re working with the Entity Framework team in order to find a solution for this in the future versions, but in the mean time if you’re using the Entity Framework June 2011 CTP we temporary worked around this issue with a temp API that by providing a non-generic provider factory of type SqlClientFactory, which means that in the meantime you’ll be able to use the Entity Framework profiler only with Sql Server:

EntityFrameworkProfiler.TempApi_InitializeForV42_CTP();

In addition, you’ll need to add the following assembly redirection to your config file in order to instruct the profiler to use the correct version of Entity Framework:

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            <assemblyIdentity name="System.Data.Entity" publicKeyToken="b77a5c561934e089" culture="neutral" />
            <bindingRedirect oldVersion="4.0.0.0" newVersion="4.2.0.0" />
        </dependentAssembly>
    </assemblyBinding>
</runtime>

The main problem is that we can’t currently easily support providers other than SqlClient, if you do need that support on the new CTP, please let us know, and we will provide you with a custom version for that purpose. Considering that this is a CTP version, we decided to provide a partial solution that will work for most of our users and we’re working with the Entity Framework team in order to find a better solution.

Happy Profiling

The Hibernating Rhinos Team

When Entity Framework June 2011 CTP was out, we were asked by our users to provide support for it in the Entity Framework Profiler.

As we started to investigate how to provide support for it, we discovered that it’s not that easy task to do. The way that Entity Framework Profiler appender works in nutshell is by replacing the instances of DbProviderFactory (like SqlClientFactory or OracleClientFactory) that the client has on his machine with a custom provider factory that wrap the original provider factory. This wasn’t easy task to do, because Entity Framework June CTP made a few assumptions that make our life more complicated. Specifically:

• There is an assumption that the provider factory type is not a generic type. This broke our code which is uses a generic provider factory type which wrap each of the providers factories that the client have on the fly, since the client can use any provider factory that he wants.
• Even if we use non-generic providers for each of the client’s providers, we found out that each provider should be compiled in a separate assembly because of the way that Entity Framework matches providers.

We’re working with the Entity Framework team in order to find a solution for this in the future versions, but in the mean time if you’re using the Entity Framework June 2011 CTP we temporary worked around this issue with a temp API that by providing a non-generic provider factory of type SqlClientFactory, which means that in the meantime you’ll be able to use the Entity Framework profiler only with Sql Server:

EntityFrameworkProfiler.TempApi_InitializeForV42_CTP();

In addition, you’ll need to add the following assembly redirection to your config file in order to instruct the profiler to use the correct version of Entity Framework:

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            <assemblyIdentity name="System.Data.Entity" publicKeyToken="b77a5c561934e089" culture="neutral" />
            <bindingRedirect oldVersion="4.0.0.0" newVersion="4.2.0.0" />
        </dependentAssembly>
    </assemblyBinding>
</runtime>

The main problem is that we can’t currently easily support providers other than SqlClient, if you do need that support on the new CTP, please let us know, and we will provide you with a custom version for that purpose. Considering that this is a CTP version, we decided to provide a partial solution that will work for most of our users and we’re working with the Entity Framework team in order to find a better solution.

Happy Profiling

The Hibernating Rhinos Team

When Entity Framework June 2011 CTP was out, we were asked by our users to provide support for it in the Entity Framework Profiler.

As we started to investigate how to provide support for it, we discovered that it’s not that easy task to do. The way that Entity Framework Profiler appender works in nutshell is by replacing the instances of DbProviderFactory (like SqlClientFactory or OracleClientFactory) that the client has on his machine with a custom provider factory that wrap the original provider factory. This wasn’t easy task to do, because Entity Framework June CTP made a few assumptions that make our life more complicated. Specifically:

• There is an assumption that the provider factory type is not a generic type. This broke our code which is uses a generic provider factory type which wrap each of the providers factories that the client have on the fly, since the client can use any provider factory that he wants.
• Even if we use non-generic providers for each of the client’s providers, we found out that each provider should be compiled in a separate assembly because of the way that Entity Framework matches providers.

We’re working with the Entity Framework team in order to find a solution for this in the future versions, but in the mean time if you’re using the Entity Framework June 2011 CTP we temporary worked around this issue with a temp API that by providing a non-generic provider factory of type SqlClientFactory, which means that in the meantime you’ll be able to use the Entity Framework profiler only with Sql Server:

EntityFrameworkProfiler.TempApi_InitializeForV42_CTP();

In addition, you’ll need to add the following assembly redirection to your config file in order to instruct the profiler to use the correct version of Entity Framework:

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            <assemblyIdentity name="System.Data.Entity" publicKeyToken="b77a5c561934e089" culture="neutral" />
            <bindingRedirect oldVersion="4.0.0.0" newVersion="4.2.0.0" />
        </dependentAssembly>
    </assemblyBinding>
</runtime>

The main problem is that we can’t currently easily support providers other than SqlClient, if you do need that support on the new CTP, please let us know, and we will provide you with a custom version for that purpose. Considering that this is a CTP version, we decided to provide a partial solution that will work for most of our users and we’re working with the Entity Framework team in order to find a better solution.

Happy Profiling

The Hibernating Rhinos Team

In order to support one click install experience for our profilers we’re providing our users with NuGet packages for some of our profilers. The profilers that currently have NuGet package are:

• NHibernate Profiler
• EntityFramework Profiler
• LinqToSql Profiler
• LLBLGen Profiler

When you install one of the profiler packages, your project is updated with some application start code that wiring your application with the profiler. This is great but it’s even greater since we are fully support VB projects alongside the C# once.

One thing that it’s interesting through is that no matter what project type you’re using, C# or VB, both files types are added to your project, one for each project type:

You may think that you’re going to get compilation error here, as C# projects can’t read the .vb file and vice versa, VB projects can’t read the .cs file, but it’s actually do compile. This is because that only one of the files are going to compile with your code while the other one added as content – which means that even that the file is there you actually do not do anything interesting with it - it’s not going to compile with your code.

In a C# project the files properties will like the following:

The .cs file build action value is compile.

The .vs file build action set value is content.

It’s may not be very intuitive to see a .vb file in C# project, but this behavior is inherited by NuGet, which is responsible to add those files. Looking on the NuGet documentation I wasn’t able to see any reference regards how is it behaves on different project types.

We can remove one of the files manually from the Install.ps1 files, depends on what project type you use, but since we think that this responsibility is of NuGet, we let NuGet to take care of that.

In order to support one click install experience for our profilers we’re providing our users with NuGet packages for some of our profilers. The profilers that currently have NuGet package are:

• NHibernate Profiler
• EntityFramework Profiler
• LinqToSql Profiler
• LLBLGen Profiler

When you install one of the profiler packages, your project is updated with some application start code that wiring your application with the profiler. This is great but it’s even greater since we are fully support VB projects alongside the C# once.

One thing that it’s interesting through is that no matter what project type you’re using, C# or VB, both files types are added to your project, one for each project type:

You may think that you’re going to get compilation error here, as C# projects can’t read the .vb file and vice versa, VB projects can’t read the .cs file, but it’s actually do compile. This is because that only one of the files are going to compile with your code while the other one added as content – which means that even that the file is there you actually do not do anything interesting with it - it’s not going to compile with your code.

In a C# project the files properties will like the following:

The .cs file build action value is compile.

The .vs file build action set value is content.

It’s may not be very intuitive to see a .vb file in C# project, but this behavior is inherited by NuGet, which is responsible to add those files. Looking on the NuGet documentation I wasn’t able to see any reference regards how is it behaves on different project types.

We can remove one of the files manually from the Install.ps1 files, depends on what project type you use, but since we think that this responsibility is of NuGet, we let NuGet to take care of that.