Trying to Dunamically Load Assembly via Reflection 
Author Message
 Trying to Dunamically Load Assembly via Reflection

I have a flexible object creation method which first tries to create the
supplied ProgID as a COM object. If that fails, then the method tries to
create the supplied ProgID as a .NET object. The reason I do this is because
the application is extensible, allowing the customer to 'plug in' their own
modules, as long as a specific interface is supplied.

Here's the syntax which I use to create the object. I know this is correct
because it does work. With one strange qualification:

Ass = Reflection.Assembly.LoadFrom(LibName)
AssName = Ass.GetName
ClassType = Ass.GetType(ClassName, True)
Obj = Ass.CreateInstance(ClassType.FullName)

My application is hosted by an ASPX (ASP.NET) page. A call to the ASPX
triggers the creation of an IHttpHandler object to service the request. This
IHttpHandler creates any sub-objects necessary to service the request. I had
assumed that the IHttpHandler runs with its default directory set to the
root of the Web Application (virtual directory). Consequently, I have
created a bin folder off of the root and all of my .NET dll's are installed
to bin. Certainly this works well for all objects instantiated via 'New'.
Since they are in the same folder as the IHttpHandler, this is a no-brainer,
since they are all part of the same Assembly.

However, I encountered difficulty the first time I attempted to create an
object using the statements above. Object creation failed on the first
statement, with a {System.IO.FileNotFoundException}. File not found?

By doing a little experimentation in the de{*filter*}, I found out that the
default directory under which the code was running was WINNT\System32. Huh?
Anyway, not to buck the trend I copied all of my DLL's into System32 and the
code worked! Can someone explain this to me? Although I got the code to
work, I don't fancy installing our application components, nor instructing
the customers to install theirs, into System32. I'd have thought, that
running as a Web Application, all dll's should be installed into the bin
folder off of the root folder mapped to the IIS virtual directory. Is this
not the case?

Thanks for your help.

- Joe Geretz -



Mon, 27 Dec 2004 00:50:46 GMT  
 Trying to Dunamically Load Assembly via Reflection
I can alleviate the problem a bit by doing this when my main object starts
up:

ChDrive(m_ASPPack.ServerVariable("APPL_PHYSICAL_PATH"))
ChDir(m_ASPPack.ServerVariable("APPL_PHYSICAL_PATH"))

However, I still need to indentify my Assembly location as
"bin\FileName.dll". I thought that subfolder bin\ would be in the default
.NET search path for loading an Assembly. Maybe not, since I'm doing the
load manually? (I guess in that case, I can write my own search into the
routine.)

- Joe Geretz -


Quote:
> I have a flexible object creation method which first tries to create the
> supplied ProgID as a COM object. If that fails, then the method tries to
> create the supplied ProgID as a .NET object. The reason I do this is
because
> the application is extensible, allowing the customer to 'plug in' their
own
> modules, as long as a specific interface is supplied.

> Here's the syntax which I use to create the object. I know this is correct
> because it does work. With one strange qualification:

> Ass = Reflection.Assembly.LoadFrom(LibName)
> AssName = Ass.GetName
> ClassType = Ass.GetType(ClassName, True)
> Obj = Ass.CreateInstance(ClassType.FullName)

> My application is hosted by an ASPX (ASP.NET) page. A call to the ASPX
> triggers the creation of an IHttpHandler object to service the request.
This
> IHttpHandler creates any sub-objects necessary to service the request. I
had
> assumed that the IHttpHandler runs with its default directory set to the
> root of the Web Application (virtual directory). Consequently, I have
> created a bin folder off of the root and all of my .NET dll's are
installed
> to bin. Certainly this works well for all objects instantiated via 'New'.
> Since they are in the same folder as the IHttpHandler, this is a
no-brainer,
> since they are all part of the same Assembly.

> However, I encountered difficulty the first time I attempted to create an
> object using the statements above. Object creation failed on the first
> statement, with a {System.IO.FileNotFoundException}. File not found?

> By doing a little experimentation in the de{*filter*}, I found out that the
> default directory under which the code was running was WINNT\System32.
Huh?
> Anyway, not to buck the trend I copied all of my DLL's into System32 and
the
> code worked! Can someone explain this to me? Although I got the code to
> work, I don't fancy installing our application components, nor instructing
> the customers to install theirs, into System32. I'd have thought, that
> running as a Web Application, all dll's should be installed into the bin
> folder off of the root folder mapped to the IIS virtual directory. Is this
> not the case?

> Thanks for your help.

> - Joe Geretz -



Mon, 27 Dec 2004 01:39:20 GMT  
 Trying to Dunamically Load Assembly via Reflection
The LoadFrom function takes the physical name of your assembly. So probably
that is why.
Why not you consider to pass assembly name by using Load function. That
should work.

Calvin


Quote:
> I have a flexible object creation method which first tries to create the
> supplied ProgID as a COM object. If that fails, then the method tries to
> create the supplied ProgID as a .NET object. The reason I do this is
because
> the application is extensible, allowing the customer to 'plug in' their
own
> modules, as long as a specific interface is supplied.

> Here's the syntax which I use to create the object. I know this is correct
> because it does work. With one strange qualification:

> Ass = Reflection.Assembly.LoadFrom(LibName)
> AssName = Ass.GetName
> ClassType = Ass.GetType(ClassName, True)
> Obj = Ass.CreateInstance(ClassType.FullName)

> My application is hosted by an ASPX (ASP.NET) page. A call to the ASPX
> triggers the creation of an IHttpHandler object to service the request.
This
> IHttpHandler creates any sub-objects necessary to service the request. I
had
> assumed that the IHttpHandler runs with its default directory set to the
> root of the Web Application (virtual directory). Consequently, I have
> created a bin folder off of the root and all of my .NET dll's are
installed
> to bin. Certainly this works well for all objects instantiated via 'New'.
> Since they are in the same folder as the IHttpHandler, this is a
no-brainer,
> since they are all part of the same Assembly.

> However, I encountered difficulty the first time I attempted to create an
> object using the statements above. Object creation failed on the first
> statement, with a {System.IO.FileNotFoundException}. File not found?

> By doing a little experimentation in the de{*filter*}, I found out that the
> default directory under which the code was running was WINNT\System32.
Huh?
> Anyway, not to buck the trend I copied all of my DLL's into System32 and
the
> code worked! Can someone explain this to me? Although I got the code to
> work, I don't fancy installing our application components, nor instructing
> the customers to install theirs, into System32. I'd have thought, that
> running as a Web Application, all dll's should be installed into the bin
> folder off of the root folder mapped to the IIS virtual directory. Is this
> not the case?

> Thanks for your help.

> - Joe Geretz -



Mon, 27 Dec 2004 05:46:44 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Reflection assembly version recognition...

2. Missing assembly when using reflection to call component method

3. Reflection.Assembly.LoadFrom

4. Reflection.Assembly

5. Getting the object name via reflection

6. Dynamic loading forms using reflection

7. Using Reflection to load Composite Control

8. Permissions failure when trying to create a file using a .NET assembly called from VB6

9. Load Assembly /CreateInstance

10. Load Assembly

11. One or more of the types in the assembly unable to load

12. How do I load and run assemblies dynamically

 

 
Powered by phpBB® Forum Software