Good article, Ben. You touch upon a problem I've encountered over the last 4 years at work. I'm on a team that's slowly working on replacing incredibly old Excel and MS Access apps with a Windows equivalent. Some of these require duplicating reports. We've always chosen SSRS as the technology to replace them with. When we do this, for reasons I've never understood my colleagues like to include the Microsoft.SqlServer.Types.dll into the deployment package. (I've asked why they do this, but they never answer me. No matter, going on.) The problems with this approach are as follows. (a) We're stuck at God only knows what outdated version of the Microsoft.SqlServer.Types.dll they copy one from project to another. (I don't know where they started copying that DLL from, as that's before I joined the team almost 6 years ago.) (b) Since we use ClickOnce deployment, including Microsoft.SqlServer.Types.dll. This is a problem because Microsoft.SqlServer.Types.dll must be installed using elevated privileges. (It must be installed in the GAC, which requires administrative privileges.) None of the users installing any of the apps we install using ClickOnce, are administrators on their machines. Thus, the users always encounter an error during installation and they always blame me. I learned 4 years ago that the issue was including Microsoft.SqlServer.Types.dll into the deployment. So, I'd remove it so ClickOnce could work. Then my colleagues would just put it back in again. Although I've told them repeatedly of the installation problems this causes, they ignore me and continue to put Microsoft.SqlServer.Types.dll back into the ClickOnce deployment. This results in a vicious cycle, but I'll stop here describing.
About 4 years ago I decided to investigate what Microsoft.SqlServer.Types.dll does. I learned that it was to help C# work with the SQL Server's spatial types, such as SQLGeography and so on. C# doesn't include this data type, so Microsoft.SqlServer.Types.dll provides the bridge between the two. At that time, I thought, why are we including a DLL to work with a data type that isn't used in our databases? I took this to be a justification for removing Microsoft.SqlServer.Types.dll in the first place.
However, more recently I thought perhaps Microsoft did it this way, just in case, the local RDL report used a SQL Server spatial data type. I can understand this logic, so that makes sense of the situation. If I'm correct about this, then I really wish Microsoft had some sort of flag that the developer could set, saying "This report using SQL Server Spatial Data Types" or clear it otherwise. As far as I know, there isn't such a flag.
Sorry, long explanation. But at least you see the dilemma I'm in. This brings me to ask you a few questions. Early in your article, you said you used the NuGet package Microsoft.ReportingServices.ReportViewerControl.WebForms, instead of the WinForms version. Why do you do this? Is it to avoid the problem I've encountered? I've seen both packages on NuGet. I thought that if I did use either NuGet package, I'd use the WinForms version, because we're working with Windows apps, not Web apps. However, I don't use either NuGet package because for some reason, which again my colleagues will not tell me, they abhor using NuGet and want to include DLLs directly in their applications. Would using the Microsoft.ReportingServices.ReportViewerControl.WebForms NuGet package solve my problem of being able use SSRS reporting locally without having to install the Microsoft.SqlServer.Types.dll in the GAC?