November 2004 - Posts

So in our class we teach about how SQL Server acts as a host for the CLR inside SQL Server 2005 and how SQL is responsible for loading of assemblies etc.

However, not until a couple of days ago did I realize the full implications of this (shame on me). It started with a question on one of the newsgroups; is it possible to do late binding against a SQLCLR assembly from inside SQL Server? As the content of an assembly catalogued in SQL Server is stored in a table, my idea was to retrieve it from the table as a byte array and then use the Assembly.Load(byte[]) method. It worked and I was able to load the assembly from within a SQLCLR proc, and execute methods etc.

After a day or two one of the PM's in the SQLCLR team posted back and said that my solution was indeed working, but that they will eventually disallow loading an assembly from a byte array(inside of SQL Server), and why did I not use the normal Assembly.Load(fullAssemblyName) method, instead of this clumsy hack?

Sure enough, as long as the assembly is catalogued in SQL Server, you can call Assembly.Load(fullAssemblyName) from inside SQL to load the assembly; really, really cool!! One caveat; you need to define the full four part name of the assembly: name, version, culture and public key token.

We have a new SQL Server blogger. I had the pleasure of having Christian Wade as a student a couple of weeks ago at a SQL Server 2005 class.It is great to see that he has now started a blog. His RSS feed is here.