1

I found a post from seven or so years ago that the Entity Framework could not be used in a CLR stored procedure. Has this been rectified in the past seven or so years? Is an update available that will allow the Entity Framework to work in a CLR stored procedure?

Abhijeet
  • 13,562
  • 26
  • 94
  • 175
SlipEternal
  • 222
  • 2
  • 12
  • I do believe that is still the case. Not to be funny or anything - but why would you ever want to do that? – Niels Berglund Jan 16 '18 at 16:16
  • The rest of the system uses the Entity Framework. I occasionally find CLR stored procedures to be convenient. But, for system maintainability, I would want to utilize the same data layer in any .NET code I write that is used throughout the rest of the system. Why would I not want to use the Entity Framework in a CLR stored procedure? – SlipEternal Jan 16 '18 at 16:29
  • I guess I am asking, is there a vulnerability I would be opening up if the Entity Framework were allowed to be accessed by a CLR stored procedure? – SlipEternal Jan 16 '18 at 16:43

1 Answers1

1

The normal reason you don't do this is that if you did, you would have to install all of .NET Framework assemblies that EF depends on into the database as unsafe assemblies, and you would have to update them every time the .NET Framework on the server was updated. As of EF 6.2 that list is :

smdiagnostics.dll
system.runtime.serialization.dll
system.dynamic.dll
microsoft.csharp.dll

This is in addition to installing updated versions of 

entityframework.dll  
entityframework.sqlserver.dll

Which would come along with updated versions of your custom CLR dll.

And then you would have to start testing EF in SQL CLR to determine if it a) works and b) plays nicely in SQLCLR's unique hosting environment.

David Browne - Microsoft
  • 80,331
  • 6
  • 39
  • 67