How to fix DataReader.GetFieldType(n) returned null in WebForms project
I had a .NET Web Forms project I was working on, and when running the site locally, I would attempt to navigate to one of the pages, and I kept getting an exception: DataReader.GetFieldType(n) returned null. There weren't any other details or any additional insights to be gained from the stack trace, as it ended literally right at the function I was calling where the exception was being thrown rather than giving any further info as to what system or library calls were being made inside that function. After doing some research and experimentation, there were a few key things I needed to do in order to fix this error.
Introduction
I had a .NET Web Forms project I was working on, and when running the site locally, I would attempt to navigate to one of the pages, and I kept getting an exception: DataReader.GetFieldType(n) returned null. There weren’t any other details or any additional insights to be gained from the stack trace, as it ended literally right at the function I was calling where the exception was being thrown rather than giving any further info as to what system or library calls were being made inside that function. After doing some research and experimentation, there were a few key things I needed to do in order to fix this error.
Microsoft.SqlServer.Types
First and foremost in my searches was that the Microsoft.SqlServer.Types NuGet package should be installed as a reference to the project where you’re seeing getting the exception. I verified that it was installed in my project both by checking the references to see it was actually referenced in my project, and by using the NuGet package manager to see that it was actually installed for my project. I figured that maybe that the version was outdated or corrupted. I started by reinstalling the current version. When that didn’t work, I tried several different versions, but still no luck. I restored the NuGet package to the original version (14.0.0.0) and did some more digging to see what I might be missing.
Code Addition for Microsoft.SqlServer.Types package
When installing the Microsoft.SqlServer.Types NuGet package, a notification comes up indicating code changes that need to be made in order for this package to be effective (as seen below).
My project is an ASP.NET Web Project, so a line of code must be added to the global.asax file.
After checking the the global.asax.cs file for the project I was working on, I saw that this line of code had indeed been added to this file. If you’re running into this problem and also have an ASP.NET app (double-check to find out exactly the type of project you’re using), be sure that you’re including this line of code. Nevertheless, I was still was getting the DataReader.GetField(26) returned null exception, so I went back to see what else I was missing.
Installing SQLSysCLRTypes
After doing some more research, I found a software package that needed to be installed on Sql Server in addition to having the above NuGet package — SQLSysCLRTypes. You’ll need to install the this package for Sql Server to work with Microsoft.SqlServer.Types. Even if you have the above NuGet package installed and your project properly set up but don’t have this package installed, you’ll still run into the DataReader.GetField(n) returned null error. This package can be downloaded here. After installing this package and verifying that it was indeed installed, I still was getting the same error, so I did some more research.
Adding reference to Web.config
I had found several people who mentioned that adding a reference to the Microsoft.SqlServer.Types NuGet package in their Web.config file fixed the problem. So I did just that and added the following under the assemblyBinding element in Web.Config:
</dependentAssembly>
<assemblyIdentity name="Microsoft.SqlServer.Types" publicKeyToken="89845dcd8080cc91" culture="neutral" />
<bindingRedirect oldVersion="10.0.0.0" newVersion="14.0.0.0" />
</dependentAssembly>This is what actually fixed the problem. Adding this dependent assembly designation in Web.config after ensuring all the other steps above were done fixed the exception I kept seeing, and I was able to continue with my work.
Conclusion
With additional experimentation I verified that each of the other steps above the Web.config addition I had made are also needed or else I would get that exception again. Adding the dependentAssembly reference in Web.config was mentioned far less than the other items, maybe because it was less common of a thing, but it was what I was missing and the step that ultimately resolved this exception. My hope is that this post will help others get set up faster rather than spending a lot of time fighting with this error like I did.