.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.


infopath, sharepoint

InfoPath vs SharePoint 2013 Web Services

If like me you have spent the past couple of hours struggling to get past 401 Unauthorized errors when attempting to call SharePoint webservices via InfoPath, take a look at the following blog post from Susan Hernandez.

There are a lot of crazy posts out their explaining that InfoPath doesn’t understand the fully claims based model of authentication that comes as standard in SharePoint 2013. Some of them also go on to describe some fairly dubious approaches to getting round the problem. Susan has done a fantastic post that explains how you can use a combination of a Secure Store entry and a data connection file to get yourself authenticated with SharePoint 2013 web services. The approach described seems far more sensible than some of the others:


I haven’t fully tested the ins and outs of this approach. I’m not entirely sure if it can be used to call a web service where the calling user’s identity is important to the service result.

For web service calls where the caller’s identity is not relevant then this approach did the trick for me

sharepoint, sharepoint 2013

SharePoint 2013: New Document and Edit Document Buttons Not Working

Hi all

If you get a situation in a SharePoint 2013 document library where your New Document or Edit Document buttons seem to do nothing, check if you have the Google Toolbar installed.

In my case, ever though I stopped using the toolbar quite a while ago, it was still there. After disabling the toolbar, the document library buttons started behaving themselves again.

It’s possible the issue is to do with the popup blocked in the Google Toolbar, so if you have your heart set on keeping the toolbar, you may want to have a poke around those settings.

Hope that helps


app fabric, sharepoint

Fix: Faulting application name: DistributedCacheService.exe

You might start getting issues with your SharePoint farm’s Distributed Cache if you resize a VM in the Cache cluster. We recently upped the VM memory and core count for a couple of machines that were acting as SharePoint 2013 front ends. As soon as we did this the App Fabric Service would crash immediately on start up throwing errors such as:

Faulting application name: DistributedCacheService.exe, version: 1.0.4632.0, time stamp: 0x4eafeccf
Faulting module name: KERNELBASE.dll, version: 6.3.9600.17415, time stamp: 0x54505737
Exception code: 0xe0434352
Fault offset: 0x0000000000008b9c

Or the following

AppFabric Caching service crashed with exception {System.ArgumentException: An entry with the same key already exists.
at System.Collections.Generic.TreeSet`1.AddIfNotPresent(T item)
at System.Collections.Generic.SortedDictionary`2.Add(TKey key, TValue value)

I’m not going to relist the solution here, but the answer in our case was to export and slightly modify the cluster configuration as described by this life saver of a post:


Like the original poster, I’m still not quite clear on why the service crashed or why tweaking those seemingly innocuous parts of the config would suddenly bring it back to life.

I will be bearing this in mind though as it seems there is a small “tax” to be paid whenever you change certain types of virtual hardware on a machine running the App Fabric Service

.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!