.net, Troubleshooting

The Entity Framework provider type ‘System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer’…

You receive the following when running an app with an Entity Framework dependency:

The Entity Framework provider type ‘System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer’ registered in the application config file for the ADO.NET provider with invariant name ‘System.Data.SqlClient’ could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application

This issue can occur if you have the correct references to the Entity Framework in your class library, but not in you main executable project in Visual Studio.

In my case it was just a case of using NuGet to install the relevant packages in both the business logic project and also the main executable project.

.net, Troubleshooting, Visual Studio

Stopping vshub Requests Spamming Fiddler

I’ve been having some issues lately when debugging ASP.net web applications using Visual Studio and Fiddler. If you use Fiddler whilst running the app in debug mode, you’ll find it’s being spammed with traffic being sent to Visual Studio as your app runs.

The key symptom is you have hundreds of requests that look something like:



Aside from being slightly irritating, the volume of traffic is sufficient to make Fiddler borderline useless as all genuine traffic will be drowned out.

I didn’t have much luck applying standard Fiddler Filters for some reason. Most likely I was just wrong on the syntax for the exclusion.

Digging in a bit further, the traffic is being sent to the Diagnostic Tools window in Visual Studio and is used to populate those kinda cool/kinda horrendously distracting memory and processor charts.

Given that I don’t spend my entire Visual Studio day preoccupied with memory usage and CPU load it seems a little overkill to be sending that data by default. As such, to stop the spamming, open the Diagnostic Tools window (Ctrl + Alt + F2) and deselect the Memory Usage and CPU Usage tools as shown below:

Diagnostic Tools Window

This should stop the spam traffic, but you will need to remember to manually re-enable the Diagnostic Tools if you are doing some profiling that requires them.


.net, iis, sharepoint

Microsoft SharePoint is not supported in 32-bit process. Please verify that you are running in a 64-bit executable.

You might get the following error if you attempt to create a 32 bit application that references the 64 bit SharePoint dlls such as Microsoft.SharePoint.dll etc

Microsoft SharePoint is not supported in 32-bit process. Please verify that you are running in a 64-bit executable.

In a console or Windows application the fix to this is fairly straight forward – just make sure your Visual Studio project targets Any CPU or force it to have a Platform Target of 64 bit.

Resolving this during Visual Studio development with¬†IIS Express is a little more challenging. As far as I can tell IIS express runs as 32 bit process by default. This means it really won’t like them there 64 bit SharePoint DLLs.

The fix is to force IIS Express to run as a 64 bit process by making sure the following registry key is set to 1:

IIS Express as 64 bit

I hope that saves someone the 30 mins I just spent!