I am attempting to build a SQL CLR project in Visual Studio 2015 and I am calling a wcf service which targets the System.Runtime.Serialization.dll. I am having problems identifying the correct version of .NET to target in order to overcome this.
The sql version is:
name value
directory C:\Windows\Microsoft.NET\Framework64\v4.0.30319\
version v4.0.30319
state CLR is initialized
I attempted to build the CLR against .NET version 4.
SQL refuses to install System.Runtime.Serialization.dll If I build against .NET version 3.5, I get
Msg 6586, Level 16, State 1, Line 8
Assembly 'System.Runtime.Serialization' could not be installed because existing policy would keep it from being used.
What version should I build against to overcome this?
SQL Server 2012 and newer uses CLR 4.0, which in turn is tied to .NET Framework versions 4.0 and above. You cannot use any .NET 2.0, 3.0, or 3.5 libraries in SQL Server 2012 or newer.
System.Runtime.Serialization is not in the Supported .NET Framework Libraries list, so you need to load it manually, and as UNSAFE. However, if that DLL is mixed mode and not pure MSIL, then it won't load since SQL Server's CLR host only works with pure MSIL libraries. I have found it best to just use HttpWebRequest and build the request XML manually and parse the response XML manually.
In the past, the ServiceModel DLL, and all of its dependencies, were pure MSIL and worked in SQL Server 2008 R2 (SQL Server 2005, 2008, and 2008 R2 are tied to CLR 2.0). But then, in CLR version 4.0, Microsoft added some dependencies to ServiceModel. One of them was the new Microsoft.VisualBasic.Activities.Compiler library (not a direct dependency, but via another, most likely Microsoft.Transactions.Bridge), which happens to contain unmanaged code (which cannot be loaded into SQL Server). Hence, everyone who had working WebService SQLCLR stuff running in 2008 R2 had it stop working upon upgrading to SQL Server 2012 or newer. Using HttpWebRequest works with an "approved" library that is guaranteed to always works across upgrades of the .NET Framework.
There are numerous questions already on here regarding these issues. I will try to find some and update this with a few of them.
Also, just FYI, the output shown in the question, which appears to be the results of executing: SELECT * FROM sys.dm_clr_properties;. Please be aware that the "version" shown, while often referred to as the Framework version, is actually just the CLR version, and those two things are not the same thing.
Related
How do I change the .NET framework of MS SQL Server 2012?
I have a SSIS package that has a script that cannot target .NET 4.0 due to using WebUtility.UrlEncode().
Will upgrading to 4.5 on the Server interfere with other stored procedures that are currently running (and targeting 4.0)?
I tried setting the target of the Script Task to 4.0 but WebUtility.UrlEncode isnt available for 4.0.
Two things at play here.
The first is the target setting for the SSIS Script Task/Component. You can change that up/down as the item requires.
That's a development setting by the way. When you deploy to the server, would need to ensure that server itself has an equivalent runtime on it.
Now, things get "weird" because for the 4.0 runtime framework, which we both have, there are developer versions within that version, from a Command Prompt if you typed
C:\Windows\Microsoft.NET\Framework\v4.0.30319\csc.exe you'd see what version there. For example, I see
Microsoft (R) Visual C# Compiler version 4.8.4084.0 for C# 5
How do I find the .NET version?
When I register the assembly System.ServiceModel.dll I get this warning message:
After that I am trying to register Microsoft.Transactions.Bridge.dll and get this warning:
What directory / folder are you trying to pull in those DLLs from? You should only need to create the ServiceModel Assembly. This will require that the Database be set to TRUSTWORTHY ON and that you create the Assembly as UNSAFE.
That being said, you would be better off finding an entirely different approach given that very limited nature of what you are building. SQLCLR is a very restricted environment and does not allow for mixed-mode Assemblies; only pure MSIL Assemblies are allowed. In .NET Framework versions 2.0, 3.0, and 3.5, the ServiceModel library was pure MSIL so importing it did work. However, starting with .NET Framework v 4.0, ServiceModel changed to be a mixed-mode DLL and hence cannot be imported into SQL Server starting with SQL Server 2012 (i.e. the first version of SQL Server to be linked to CLR v 4.0 which uses .NET Framework versions 4.0 through the current 4.7 (I think)). And there is no fix outside of re-writing the code to no longer reference ServiceModel. Please see my answer here for more details on that:
(Unfixable) Assembly exists on SQL Server 2014 but it claims it doesn't have it
I'm using vs 2013 and trying to deploy a project to the integration services catalog on ssms 2016. I'm getting the error:
"Failed to deploy project. For more information, query the operation_messages view for the operation identifier '23'. (.Net SqlClient Data Provider)"
when I'm trying to query "operation_messages" the table is empty.
The thing is that I succeed to deployed it once, just after adding more packages\connections it started to fail.
Any idea anyone?
error image
You may have a compatibility issue with Visual Studio 2013 and SQL 2016, typically it works for backwards compatibility but forward can exhibit issues. I am currently using VS 2015 for our SQL 2016 systems and my SSIS packages. I am not necessarily familiar with your exact error, but when using different versions you can see some oddball errors.
https://msdn.microsoft.com/en-us/library/bb522577.aspx
If you install the latest SSDT you will have a visual studio 2015 shell. It is recommend that you use this rather than previous versions of VS, especially as SQL2016 is still relatively new. MS may add more support for VS2013 but maybe not...
https://msdn.microsoft.com/en-us/library/mt204009.aspx
I have a DLL which uses .NET Framework v2.0. and I want to add it to SQL Server 2012 using CREATE ASSEMBLY. But SQL Server 2012 uses .NET Framework v.4.0.
Is it possible to add a .NET Framework v2.0 assembly to SQL Server 2012?
Well, it depends. The question title and question text imply two different questions.
If the question is about a .NET Framework DLL:
No. SQL Server 2012 and 2014 are statically linked to only CLR version 4.0 (meaning .NET Framework versions starting at 4.0 through at least 4.5.2 if not also 4.6 if that has been released). Hence it is not possible to load any Framework DLL that is part of CLR 2.0 (i.e. Framework versions 2.0, 3.0, and 3.5) into SQL Server 2012 or 2014.
However, everything should be backwards compatible and should work just the same if you try to load the CLR 4.0 (i.e. Framework versions 4.0, 4.5, 4.5.1, etc) version of the same Framework DLL. The only reason why this wouldn't work is if the DLL in question, or one of its dependencies, changed to become a mixed-mode DLL in one of the Framework updates that was released after the version that you have been using. The problem in that case would be that SQL Server only supports pure MSIL DLLs.
If the question is about a DLL that you created:
Again, as long as it is not a mixed-mode DLL, everything should be backwards compatible and should work just the same.
If loading the DLL errors with:
Assembly "{AssemblyName}" was built using version vX.Y.ZZZZ of the .NET Framework. SQL Server currently uses version v4.0.30319
then you can probably re-link it to 4.0. Please see my answer to "Cannot register stdole assembly in SQL Server 2012" for an example of doing this.
FYI, I wrote an article that explains the CLR / Framework versions issue in detail: Stairway to SQLCLR Level 5: Development (Using .NET within SQL Server) (free registration required).
It appears out of the box the v1 of Microsoft Sync Framework would only support synching with a CE db, using the SqlCeClientSyncProvider. I can't find anywhere in the documentation about v2 if we can now sync between two SQL Server databases. Anyone know of hand if this is now possible (without writing my own client provider)?
The following provider is the one that you should be using to sync with a SQL Server database.
Microsoft.Synchronization.Data.Server.DbServerSyncProvider
The Local Database Cache tool could get you up and running fairly quickly without having to worry about these details - you would however be sacrificing some flexibility.
You don't necessarily need Sync Framework 2.0 if you do decide that you want to get a little closer to the metal but it has now been released and is probably your best bet. Just be careful with the DLL versions that you swap into your solution after installing the SDK. Note below that the database DLLs are not versioned consistently with the rest of the framework and that the version of the Microsoft.Synchronization.Data.SqlServerCe DLL actually decreases from 3.5 to 3.0.
Installing Sync Framework - MSDN
All database provider DLLs have a
version number of 3.0 rather than 2.0
because some of the providers were
originally released before Sync
Framework 1.0.
Microsoft.Synchronization.Data.SqlServerCe.dll
was originally released as part of SQL
Server Compact and previously had a
version number of 3.5 to match the SQL
Server Compact version. The version of
this DLL is now 3.0 to match the other
database providers.