SQL Server 2008 June CTP Declarative Management Bug
There is a bug in the SQL Server 2008 June CTP that causes Declarative Management to be inoperable. The fix is very simple. Launch a command line and run the following command:
C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\sn.exe -Vr Microsoft.SqlServer.DmfSqlClrWrapper,89845DCD8080CC91
After running the command you will need to restart the SQL Server service.
The Declarative Management DLL, which runs inside the SQLCLR, did not get signed as part of the build process. Running the above command will disable strong name verification for this assembly. Client-side checking of policies: "Test Policy" and "Run Now" will function as expected without the fix. Policy automation (enforce, check on change, and check on schedule), though, will require applying the above fix.
Thanks Dan!
You can find the updated online readme for SQL Server 2008 June CTP here: http://go.microsoft.com/fwlink/?LinkId=88963
The readme documents the workaround you mention with details like the actual error you see when the failure occurs.
Hi Dan,
Thanks for your post.
I've run the command "sn.exe ...".
I've the same error when I want to create a table that doesn't match my policy :
Msg 10314, Level 16, State 11, Procedure sp_syspolicy_execute_policy, Line 25
An error occurred in the Microsoft .NET Framework while trying to load assembly id 65536. The server may be running out of resources, or the assembly may not be trusted with PERMISSION_SET = EXTERNAL_ACCESS or UNSAFE. Run the query again, or check documentation to see how to solve the assembly trust issues. For more information about this error:
System.IO.FileLoadException: Impossible de charger le fichier ou l'assembly 'Microsoft.SqlServer.DmfSqlClrWrapper, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' ou une de ses dpendances. échec de la validation de nom fort. (Exception de HRESULT : 0x8013141A) > System.Security.SecurityException: échec de la validation de nom fort. (Exception de HRESULT : 0x8013141A)
System.Security.SecurityException:
System.IO.FileLoadException:
at System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection)
at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
at System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
at System.Reflection.Assembly.Load(String assemblyString)
The statement has been terminated.
Regards,
Chris,
France.
Hi Chris,
Thanks for trying the workaround. I'm not sure if you already did but you'll need to restart your SQL Server service for the strong name verification changes to take effect.
Hope that helps,
Anand
Hello,
I've already restarted many times the MSSQL service....
Chris.
Hi Chris,
Try rerunning the sn command exactly as documented. Make sure it returns success. Then restart the SQL service and give it another go. Yours is the first report we've had of this not working.
Cheers,
Dan
If you're running the 64-bit version of SQL Server 2008 June CTP ("Katmai") then you'll need to use the 64-bit version of the sn.exe tool.
Strong name verification skipping entries are basically stored in the registry under: HKLM\Software\Microsoft\StrongName\Verification. On a 64-bit OS for backward compatibility you have two separate 32-bit and 64-bit registry hives. 32-bit applications (in this case 32-bit sn.exe) will read/write the 32-bit hive. 64-bit apps will read/write to the 64-bit hive. After running the steps outlined in the readme if you look under the two respective registry hives you’ll find the strong name verification skipping entry under the 32-bit hive for Microsoft.SqlServer.DmfSqlClrWrapper,89845DCD8080CC91 and you will NOT find a similar entry under the 64-bit hive.
If you're on 64-bit have two options:
1. Download the 64-bit .NET framework SDK and hence the 64-bit sn.exe and carry out the instructions from the readme, only this time using the 64-bit sn.exe. You can download the 64-bit .NET Framework SDK from here: http://www.microsoft.com/downloads/details.aspx?FamilyID=1aef6fce-6e06-4b66-afe4-9aad3c835d3d&DisplayLang=en
2. If you’re feeling brave and don’t want to download the 64-bit .NET framework SDK create the exact same strong name verification skipping entry under the 64-bit registry hive and recycle your SQL Server service.
So for 32-bit sn.exe on 64-bit OS, the registry key is created as:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\StrongName\Verification\Microsoft.SqlServer.DmfSqlClrWrapper,89845DCD8080CC91
For 64-bit sn.exe on 64-bit OS, the registry key is created as:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\StrongName\Verification\Microsoft.SqlServer.DmfSqlClrWrapper,89845DCD8080CC91
Obviously, option #1 is the recommended approach.
Hi everybody,
I'm sorry about beeing the first to experience this bug ..
I hope I've not missed something to test Management Framework ... I've just follow the tutorial.
Anand : I'm using a 32 bits version of vista / sql 2008
Dan : I've run the sn command again, restarted SS, and try to create a table that doesn't match the policy :
C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin>sn.exe -Vr Microsoft.SqlServer.DmfSqlClrWrapper,89845DCD8080CC91
Microsoft (R) .NET Framework Strong Name Utility Version 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
Verification entry added for assembly 'Microsoft.SqlServer.DmfSqlClrWrapper,89845DCD8080CC91'
C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin>
After :
USE
Finance ; GO
CREATE
TABLE NewTable (
Col1 int) ; GO
and the result :
Msg 10314, Level 16, State 11, Procedure sp_syspolicy_execute_policy, Line 25
An error occurred in the Microsoft .NET Framework while trying to load assembly id 65536. The server may be running out of resources, or the assembly may not be trusted with PERMISSION_SET = EXTERNAL_ACCESS or UNSAFE. Run the query again, or check documentation to see how to solve the assembly trust issues. For more information about this error:
System.IO.FileLoadException: Impossible de charger le fichier ou l'assembly 'Microsoft.SqlServer.DmfSqlClrWrapper, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' ou une de ses dpendances. échec de la validation de nom fort. (Exception de HRESULT : 0x8013141A) > System.Security.SecurityException: échec de la validation de nom fort. (Exception de HRESULT : 0x8013141A)
System.Security.SecurityException:
System.IO.FileLoadException:
at System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection)
at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
at System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
at System.Reflection.Assembly.Load(String assemblyString)
The statement has been terminated.
Maybe I've just configured someting wrong ....
Regards,
Christophe
Index Multimedia
France
I've had the same problem in the July CTP as well.
I issued the command and after restarting the Instance it worked.
Regards,
Salvatore
