You create a common language runtime (CLR) routine that references a Microsoft .NET Framework assembly. The .NET Framework assembly is not documented in Knowledge Base article 922672. Then, you install the .NET Framework 3.5 or a .NET Framework 2.0-based hotfix.
You create an assembly, and then you register the assembly in a Microsoft SQL Server database. Then, you install a different version of the assembly in the Global Assembly Cache (GAC).
When you execute the CLR routine or use the assembly from either of these scenarios in SQL Server, you receive an error message that resembles the following:
Server: Msg 6522, Level 16, State 2, Line 1 A .NET Framework error occurred during execution of user defined routine or aggregate 'getsid':
System.IO.FileLoadException: Could not load file or assembly 'System.DirectoryServices, Version=126.96.36.199, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Assembly in host store has a different signature than assembly in GAC. (Exception from HRESULT: 0x80131050)
When the CLR loads an assembly, the CLR verifies that the same assembly is in the GAC. If the same assembly is in the GAC, the CLR verifies that the Module Version IDs (MVIDs) of these assemblies match. If the MVIDs of these assemblies do not match, you receive the error message that the "Symptoms" section mentions.
When an assembly is recompiled, the MVID of the assembly changes. Therefore, if you update the .NET Framework, the .NET Framework assemblies have different MVIDs because those assemblies are recompiled. Additionally, if you update your own assembly, the assembly is recompiled. Therefore, the assembly also has a different MVID.
To work around scenario 1 in the "Symptoms" section, you must manually update the .NET Framework assemblies in SQL Server. To do this, use the ALTER ASSEMBLY statement to point to the new version of the .NET Framework assembly in the following folder:
Note Version represents the version of the .NET Framework that you installed or updated.
To work around scenario 2 in the "Symptoms" section, use the ALTER ASSEMBLY statement to update the assembly in the database.
If the problem still exists after you do this, drop the assembly from the database, and then register the new version of the assembly in the database.
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.
We do not recommend that you use .NET Framework assemblies that are not documented in Knowledge Base article 922672. Knowledge Base article 922672 lists the assemblies that are tested in the SQL Server CLR-hosted environment.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
922672 Support policy for untested .NET Framework assemblies in the SQL Server CLR-hosted environment
Description of CLR routines
CLR routines include the following objects that are implemented by using SQL Server integration with the .NET Framework CLR:
Microsoft SQL Server 2012 Enterprise, Microsoft SQL Server 2012 Standard, Microsoft SQL Server 2012 Developer, Microsoft SQL Server 2008 R2 Enterprise, Microsoft SQL Server 2008 R2 Developer, Microsoft SQL Server 2008 R2 Datacenter, Microsoft SQL Server 2008 R2 Workgroup, Microsoft SQL Server 2008 R2 Standard, Microsoft SQL Server 2008 Standard, Microsoft SQL Server 2008 Workgroup, Microsoft SQL Server 2008 Developer, Microsoft SQL Server 2008 Enterprise, Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition