SQL Server 2005 and Limitations to Assembly Loading

I've recently started reading "A First Look at SQL Server 2005 for Developers" in my spare time (yea, I'm not getting very far since I don't have much spare time) and I came across something rather limiting I think.  It says that you must be logged into SQL Server using an integrated security login, as opposed to a sql server account, in order to create a .NET assembly in SQL Server 2005.  The rationale given was that this was necessary in order to check if the user should have access to the file system location where the .NET assembly is to loaded from.  That does make sense, but it seems that implies that shared web hosts won't be able to easily allow us to use .NET assemblies on their SQL Servers -- am I missing something here?  Of course I'm not convinced that I would actually want a shared SQL Server on a shared web host allowing .NET use anyhow, since I don't want my data access slowed down by someone else playing with .NET stored proc, but I hadn't realized this limitation would exist either.

1 Comment

  • Actually, after reading further, it will be possible for hosters to enable this, although its a different issue about whether or not they should or will. The solution is that you can assign a Windows credentials to a Sql login -- so a hoster would need to create a Windows user account with permissions limited correctly to that user's directories and then assign those credentials to the matching Sql login. That's certainly doable, but I still have to believe that most shared hosters will not offer this functionality -- but we'll see. And I'm also still not convinced there's enough reason to allow it when you consider that opening up this door could potentially open up some security holes or hurt performance (maybe not though).

Comments have been disabled for this content.