Microsoft System Clr Types For Sql Server 2012

Setting Up CLR Types in SQL Server 2012

You want to use spatial types in SQL Server 2012, or you ran into a missing type error when someone sent you a database script with geography columns. Either way, you need the Microsoft System CLR Types For Sql Server 2012 package installed on the machine where SQL Server is running. It is not a SQL Server feature you toggle on. It is a separate Microsoft download, and if you miss the step, your CREATE TABLE statements fail with a type not found error and you spend twenty minutes wondering what is wrong. The official download link from Microsoft is Microsoft System CLR Types for SQL Server 2012. It hosts both the 32-bit and 64-bit installers. You need the version that matches your SQL Server installation architecture. Most servers running 2012 are 64-bit, but if you are on a older workstation or a virtual machine that was set up with the wrong defaults, grabbing the wrong MSI will silently do nothing useful. I once spent about an hour debugging a deployment where the production server had the 32-bit CLR types installed alongside a 64-bit instance of SQL Server. The installer completed without errors, which is the misleading part. The types simply never registered in the database engine. I confirmed it by querying sys.types and seeing the SqlGeometry and SqlGeography types were completely absent. After switching to the correct x64 package, the installation worked on the first try. Always check the SQL Server instance architecture before downloading.

How the installation actually works

Run the MSI as an administrator. That is not optional. The installer registers assemblies into the SQL Server engine itself, and it needs elevated privileges to write to the GAC and update the registry keys under HKLM\SOFTWARE\Microsoft\Microsoft SQL Server. If you run it as a standard user, the installer gives you a permission denied error and leaves the system in a partially configured state that is harder to clean up than starting over. After installation completes, you need to enable CLR integration on the SQL Server instance if it is not already enabled. Run this: sp_configure 'clr enabled', 1
RECONFIGURE

This one command opens the door for any CLR assembly to load into SQL Server. Do not skip it. Without it, even correctly installed types will throw a clr assembly not loaded error when you try to use them. I have seen DBAs skip this step repeatedly because they assumed enabling CLR meant something more complex than a single configure call. Once CLR is enabled, verify the types are present by running a simple query against the sys.types view. You should see entries for SqlGeometry and SqlGeography along with their native counterparts geometry and geography. If they are missing after a successful install, the issue is almost always an architecture mismatch between the CLR types package and the SQL Server instance.

What these types actually do

SQL Server 2012 supports geography and geometry data types natively in its engine, but the underlying implementation depends on the CLR assembly that the Microsoft System Clr Types For Sql Server 2012 package provides. The geography type handles ellipsoidal calculations, which means it is suited for GPS coordinates and real-world distance computations. The geometry type uses planar math, which is faster but only accurate for flat coordinate systems. Here is something most guides do not mention clearly: these CLR types are not just for spatial data. They are also used by the SQL Server Integration Services project templates and certain custom stored procedures that depend on Microsoft.SqlServer.Types namespace. If you are building SSIS packages that manipulate spatial data and then deploying them to a server, those packages will fail to execute if the CLR types are missing, even if the SQL Server engine itself has the geography type available. The runtime and the engine are two different things. Another counter-intuitive point is that installing the CLR types package does not automatically upgrade existing spatial functionality. If you move a database from SQL Server 2008 R2 to 2012 and the target server does not have the 2012 CLR types installed, queries that reference spatial types may return incorrect results or fail outright. The database files themselves are compatible, but the runtime layer that interprets them is not. Always install the CLR types on the target server before attaching or restoring databases that use spatial columns.

A practical edge case that bites people

I had a situation where a developer handed me a database restore script that included geography column definitions and spatial index creation. The restore completed without errors, but every query that touched the spatial columns returned a type incompatibility error. The SQL Server instance was 2012, the database was 2012 compatibility level, and everything looked correct on paper. The problem was that the CLR types package had been installed on the machine but not on the specific instance. I have multiple SQL Server instances on the same server, and the installer registers to the default instance unless you specify otherwise. I ran the installer again with the instance name parameter and the problem resolved immediately. The workaround for anyone in a similar spot is to run the installer from the command line with the INSTANCENAME flag, like this: SQLSysClrTypes.msi /passive INSTANCENAME=MSSQLSERVER

Replace MSSQLSERVER with your actual instance name. You can find your instance name by running SELECT @@SERVICENAME from within SQL Server Management Studio.

Limitations you should know about

The biggest limitation is that the Microsoft System Clr Types For Sql Server 2012 package is a legacy dependency. It was required because spatial types were shipped as a CLR assembly at that point in time. Starting with SQL Server 2014, Microsoft baked the spatial types directly into the database engine, so the separate download became unnecessary. If you are working on a new project and can target SQL Server 2014 or later, skip this package entirely and save yourself the troubleshooting effort. Another practical limitation is that this package only supports .NET Framework versions up to 4.5. If your application stack requires .NET Framework 4.8 or .NET Core, you cannot use these CLR types directly. You would need to maintain a compatibility layer or upgrade the SQL Server instance. This is not a hypothetical problem. I encountered it when a team tried to migrate a legacy reporting application to a newer .NET environment and found that the spatial queries depended on the 2012 CLR assembly. The migration required rewriting the spatial logic using native SQL geometry methods instead of .NET-based calculations, which added roughly two weeks of development time to the project. There is also a security consideration. Enabling CLR integration with sp_configure opens the door for any assembly with unsafe permission to execute arbitrary code within the SQL Server process. If you are on a shared or cloud-hosted instance, make sure your DBA has reviewed the security implications. The CLR types package itself is safe, but enabling CLR is a broader permission that affects everything, not just spatial data.

Quick verification checklist

Run sp_configure 'clr enabled' and confirm the value is 1. Check that the SQL Server instance architecture matches the CLR types package you installed. Query sys.types to confirm geometry and geography entries exist. Test with a simple geography point creation to make sure the engine can actually instantiate the type. This usually takes about five minutes total and saves you from chasing errors hours later.