Monday, March 26, 2012

Load assemblies - CLRIntegration

All -
I have two assemblies (lets say AsmA and AsmB) loaded into SQL Server
(Create Assembly)
Both these assemblies have EXTERNAL_ACCESS permissions.
When the code inside AsmA is executed (within SQLServer context), it tries
to load a type in AsmB "dynamically"
(using CreateInstanceAndUnwrap) and it fails saying "Unable to locate AsmB".
This is the exact error
"Could not load file or assembly 'xxxxx' or one of its dependencies. The
system cannot find the file specified. at System.Reflection.Assembly.nLoad
"
Where does SQLServer put these 2 assemblies when they are created?
Are they stored in the same location?
If yes then LoadAssembly should ve succeeded.
Is it permitted to load a assembly dynamically (I am not getting a
HostProtected Exception so i presume it is permitted ) And remember i am
loading the assembly which is *already* created in SQLServer.
Please provide a solution for this.
Regardz
Grafix.> Where does SQLServer put these 2 assemblies when they are created?
> Are they stored in the same location?
> If yes then LoadAssembly should ve succeeded.
> Is it permitted to load a assembly dynamically (I am not getting a
> HostProtected Exception so i presume it is permitted ) And remember i am
> loading the assembly which is *already* created in SQLServer.
>
You are allowed to call Assembly.Load(). However the assemblies have to
be owned by the same owner, i.e. they are in the same appdomain. From
what you write, it sounds like the assemblies are in different app
domains, and remoting is not allowed inside SQLCLR.
Niels|||> You are allowed to call Assembly.Load().
Thats surprising. As a simple test, wihtin Clr context, i tried to do a
Assembly.Load and got a HostProtection exception. May be i have to change
ething to UNSAFE from EXTERNAL_ACCESS then.

> From what you write, it sounds like the assemblies are in different app
> domains, and remoting is not allowed inside SQLCLR.
The assemblies belong to the same owner [dbo].
AsmB infact has a compile time reference to AsmA.
But AsmA doesnt know the types in AsmB and does a dynamic create on it.
[Popularly known by the term "Plugin components"]
[No remoting and other complications.]
While creating thetype of AsmB using
"AppDomain.CurrentDomain.CreateInstanceAndUnwrap" it fails.
The stack trace shows CreateInstacneAndUnwrap calls Assembly.Load internally
and that says "FileNotFound".
One possible reason i could imagin is that since AsmB is "not already
loaded" into SQLServer's addressspace - the first time Assembly.Load is
called it searches for the assmbly in current folder(windows\system32 where
sqlserver runs from) and doesnt find it there and cries.
How can we make SQLServer know that when i say CreateInstanceAndUnwrap -
look into ur own database where u have stored the assembly than search
externally?
Any thoughts/
Regardz
Grafix.
"Niels Berglund" wrote:

> You are allowed to call Assembly.Load(). However the assemblies have to
> be owned by the same owner, i.e. they are in the same appdomain. From
> what you write, it sounds like the assemblies are in different app
> domains, and remoting is not allowed inside SQLCLR.
> Niels
>|||Grafix wrote:
> Thats surprising. As a simple test, wihtin Clr context, i tried to do a
> Assembly.Load and got a HostProtection exception. May be i have to change
> ething to UNSAFE from EXTERNAL_ACCESS then.
Hmm, I can do that without any problems. Just tested.

>
> The assemblies belong to the same owner [dbo].
> AsmB infact has a compile time reference to AsmA.
> But AsmA doesnt know the types in AsmB and does a dynamic create on it.
> [Popularly known by the term "Plugin components"]
> [No remoting and other complications.]
> While creating thetype of AsmB using
> "AppDomain.CurrentDomain.CreateInstanceAndUnwrap" it fails.
> The stack trace shows CreateInstacneAndUnwrap calls Assembly.Load internal
ly
> and that says "FileNotFound".
You need to supply the fully qualified assembly name, something like so:
select dbo.LoadAsm('asm2, version=0.0.0.0, culture=neutral,
publickeytoken=null, processorarchitecture=msil')

No comments:

Post a Comment