PC Review


Reply
Thread Tools Rate Thread

Repost: Design advice needed: loading a DLL and calling the methods in it

 
 
Nick Malik
Guest
Posts: n/a
 
      9th Aug 2004
reposting to a wider audience

"Nick Malik" <(E-Mail Removed)> wrote in message
news:WYONc.203854$XM6.119642@attbi_s53...
> My turn to ask a question
>
> I am working on a plug-in for Sharepoint that will allow a developer to

add
> workflow rules. One of the rules will inform the adapter that it should
> load a DLL that the developer writes, find a method that matches a
> particular interface, and call it.
>
> I know, in general, I should be looking at the reflection classes. Does
> anyone have any design advice for me, or good working examples that would
> serve as a foundation, so I'm not re-inventing the wheel?
>
> Should I be loading the developer's DLL in a seperate App Domain? (My
> environment: Sharepoint is an IIS application. It runs in its own
> application pool on IIS6.) My code is already running in a protected
> environment since I'm already using Sharepoint's plug-in architecture to
> host my app.
>
> Should I use attributes to find the intended DLL, or should I simply

require
> the developer to give me the name of the method to call?
>
> --
> --- Nick
>
>
>



 
Reply With Quote
 
 
 
 
Nicholas Paldino [.NET/C# MVP]
Guest
Posts: n/a
 
      9th Aug 2004
Nick,

I think a better idea would be to use an interface, since that way, you
don't have to make late bound calls every time you want to make the call.

If you can't do that, then yes, I would go with placing an attribute on
the method that you want to call. The problem with this is that you don't
have type-safety. The signature could be wrong and you would get a run-time
error when trying to call it. Generally not a good thing.

If you need the ability to unload the DLL, then you will have to use a
separate app domain. DLLs are not unloaded from an app domain until the app
domain shuts down. Otherwise, I would advise against it (also, it might not
be possible within the context if ASP.NET to create a new app domain).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (E-Mail Removed)


"Nick Malik" <(E-Mail Removed)> wrote in message
news:P1LRc.118168$eM2.78543@attbi_s51...
> reposting to a wider audience
>
> "Nick Malik" <(E-Mail Removed)> wrote in message
> news:WYONc.203854$XM6.119642@attbi_s53...
> > My turn to ask a question
> >
> > I am working on a plug-in for Sharepoint that will allow a developer to

> add
> > workflow rules. One of the rules will inform the adapter that it should
> > load a DLL that the developer writes, find a method that matches a
> > particular interface, and call it.
> >
> > I know, in general, I should be looking at the reflection classes. Does
> > anyone have any design advice for me, or good working examples that

would
> > serve as a foundation, so I'm not re-inventing the wheel?
> >
> > Should I be loading the developer's DLL in a seperate App Domain? (My
> > environment: Sharepoint is an IIS application. It runs in its own
> > application pool on IIS6.) My code is already running in a protected
> > environment since I'm already using Sharepoint's plug-in architecture to
> > host my app.
> >
> > Should I use attributes to find the intended DLL, or should I simply

> require
> > the developer to give me the name of the method to call?
> >
> > --
> > --- Nick
> >
> >
> >

>
>



 
Reply With Quote
 
 
 
 
Nick Malik
Guest
Posts: n/a
 
      9th Aug 2004
I appreciate the advice Nicholas,

I do not need the ability to unload the DLL... at least, I'm willing to live
without it. The need for this is fairly light. So, no app domains.

What I want to do is provide a way for business users to control and manage
a workflow by modifying an XML file. They can play with this in their own
environment and, when it is right, send it to the deployment team who runs a
utility or two against it to deploy to production.

The trick is this: there is no reasonable way to capture the complications
of business rules in a simple XML description of a workflow. I need to
provide .NET DLLs to the business unit that will perform their rules. The
XML needs to provide a description for each object sufficient to allow me to
find it and load it. I am certain that the business users will not modify
the settings in the XML that refer to DLLs.

I do plan to use an interface. However, I still need to load the DLL that
uses that interface based on the text in the XML.
At that point, I run right into the limits on my knowedge. I do not know if
I will be able to tell if the user referenced a DLL that exists or not, or
if they decided to try referencing a dll that they created, using the right
names but not inheriting properly.
Maybe the attributes won't help much in this case. I just don't know (yet).

I'm still heavily in the design stage on this... I plan to be working on
proof-of-concept within the week. I'll post info as I find it.

Thanks for the advice.

--- Nick

"Nicholas Paldino [.NET/C# MVP]" <(E-Mail Removed)> wrote in
message news:%(E-Mail Removed)...
> Nick,
>
> I think a better idea would be to use an interface, since that way,

you
> don't have to make late bound calls every time you want to make the call.
>
> If you can't do that, then yes, I would go with placing an attribute

on
> the method that you want to call. The problem with this is that you don't
> have type-safety. The signature could be wrong and you would get a

run-time
> error when trying to call it. Generally not a good thing.
>
> If you need the ability to unload the DLL, then you will have to use a
> separate app domain. DLLs are not unloaded from an app domain until the

app
> domain shuts down. Otherwise, I would advise against it (also, it might

not
> be possible within the context if ASP.NET to create a new app domain).
>
> Hope this helps.
>
>
> --
> - Nicholas Paldino [.NET/C# MVP]
> - (E-Mail Removed)
>
>
> "Nick Malik" <(E-Mail Removed)> wrote in message
> news:P1LRc.118168$eM2.78543@attbi_s51...
> > reposting to a wider audience
> >
> > "Nick Malik" <(E-Mail Removed)> wrote in message
> > news:WYONc.203854$XM6.119642@attbi_s53...
> > > My turn to ask a question
> > >
> > > I am working on a plug-in for Sharepoint that will allow a developer

to
> > add
> > > workflow rules. One of the rules will inform the adapter that it

should
> > > load a DLL that the developer writes, find a method that matches a
> > > particular interface, and call it.
> > >
> > > I know, in general, I should be looking at the reflection classes.

Does
> > > anyone have any design advice for me, or good working examples that

> would
> > > serve as a foundation, so I'm not re-inventing the wheel?
> > >
> > > Should I be loading the developer's DLL in a seperate App Domain? (My
> > > environment: Sharepoint is an IIS application. It runs in its own
> > > application pool on IIS6.) My code is already running in a protected
> > > environment since I'm already using Sharepoint's plug-in architecture

to
> > > host my app.
> > >
> > > Should I use attributes to find the intended DLL, or should I simply

> > require
> > > the developer to give me the name of the method to call?
> > >
> > > --
> > > --- Nick
> > >
> > >
> > >

> >
> >

>
>



 
Reply With Quote
 
Nicholas Paldino [.NET/C# MVP]
Guest
Posts: n/a
 
      9th Aug 2004
Nick,

Ahh, it's more clear now. This is what you want to do.

In your XML, you will want to place two pieces of information, the full
name of the type that implements the interface, and the full name of the
assembly it is in.

You can get the full name of the type through the FullName property on
the Type class, and the Assembly from the FullName property as well (you can
get the assembly that the type is in through the Assembly property on the
Type).

Once you have these, you can pass the assembly name to the static Load
method on the Assembly class. This will load the assembly into memory.
Once you have the Assembly instance, you can call CreateInstance on it,
passing the full type name, and casting the return value to the interface
that you know is defined on it. From there, you call your methods.

I've attached a sample program which shows you how to do it. Compile
and run it as a console app, and it should show you what I mean.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (E-Mail Removed)




"Nick Malik" <(E-Mail Removed)> wrote in message
news:ujMRc.274386$Oq2.5582@attbi_s52...
> I appreciate the advice Nicholas,
>
> I do not need the ability to unload the DLL... at least, I'm willing to

live
> without it. The need for this is fairly light. So, no app domains.
>
> What I want to do is provide a way for business users to control and

manage
> a workflow by modifying an XML file. They can play with this in their own
> environment and, when it is right, send it to the deployment team who runs

a
> utility or two against it to deploy to production.
>
> The trick is this: there is no reasonable way to capture the complications
> of business rules in a simple XML description of a workflow. I need to
> provide .NET DLLs to the business unit that will perform their rules. The
> XML needs to provide a description for each object sufficient to allow me

to
> find it and load it. I am certain that the business users will not modify
> the settings in the XML that refer to DLLs.
>
> I do plan to use an interface. However, I still need to load the DLL that
> uses that interface based on the text in the XML.
> At that point, I run right into the limits on my knowedge. I do not know

if
> I will be able to tell if the user referenced a DLL that exists or not, or
> if they decided to try referencing a dll that they created, using the

right
> names but not inheriting properly.
> Maybe the attributes won't help much in this case. I just don't know

(yet).
>
> I'm still heavily in the design stage on this... I plan to be working on
> proof-of-concept within the week. I'll post info as I find it.
>
> Thanks for the advice.
>
> --- Nick
>
> "Nicholas Paldino [.NET/C# MVP]" <(E-Mail Removed)> wrote

in
> message news:%(E-Mail Removed)...
> > Nick,
> >
> > I think a better idea would be to use an interface, since that way,

> you
> > don't have to make late bound calls every time you want to make the

call.
> >
> > If you can't do that, then yes, I would go with placing an attribute

> on
> > the method that you want to call. The problem with this is that you

don't
> > have type-safety. The signature could be wrong and you would get a

> run-time
> > error when trying to call it. Generally not a good thing.
> >
> > If you need the ability to unload the DLL, then you will have to use

a
> > separate app domain. DLLs are not unloaded from an app domain until the

> app
> > domain shuts down. Otherwise, I would advise against it (also, it might

> not
> > be possible within the context if ASP.NET to create a new app domain).
> >
> > Hope this helps.
> >
> >
> > --
> > - Nicholas Paldino [.NET/C# MVP]
> > - (E-Mail Removed)
> >
> >
> > "Nick Malik" <(E-Mail Removed)> wrote in message
> > news:P1LRc.118168$eM2.78543@attbi_s51...
> > > reposting to a wider audience
> > >
> > > "Nick Malik" <(E-Mail Removed)> wrote in message
> > > news:WYONc.203854$XM6.119642@attbi_s53...
> > > > My turn to ask a question
> > > >
> > > > I am working on a plug-in for Sharepoint that will allow a developer

> to
> > > add
> > > > workflow rules. One of the rules will inform the adapter that it

> should
> > > > load a DLL that the developer writes, find a method that matches a
> > > > particular interface, and call it.
> > > >
> > > > I know, in general, I should be looking at the reflection classes.

> Does
> > > > anyone have any design advice for me, or good working examples that

> > would
> > > > serve as a foundation, so I'm not re-inventing the wheel?
> > > >
> > > > Should I be loading the developer's DLL in a seperate App Domain?

(My
> > > > environment: Sharepoint is an IIS application. It runs in its own
> > > > application pool on IIS6.) My code is already running in a

protected
> > > > environment since I'm already using Sharepoint's plug-in

architecture
> to
> > > > host my app.
> > > >
> > > > Should I use attributes to find the intended DLL, or should I simply
> > > require
> > > > the developer to give me the name of the method to call?
> > > >
> > > > --
> > > > --- Nick
> > > >
> > > >
> > > >
> > >
> > >

> >
> >

>
>





 
Reply With Quote
 
Nick Malik
Guest
Posts: n/a
 
      10th Aug 2004
I truly appreciate your helpfulness. Thank you.

--- Nick

"Nicholas Paldino [.NET/C# MVP]" <(E-Mail Removed)> wrote in
message news:%(E-Mail Removed)...
> Nick,
>
> Ahh, it's more clear now. This is what you want to do.
>
> In your XML, you will want to place two pieces of information, the

full
> name of the type that implements the interface, and the full name of the
> assembly it is in.
>
> You can get the full name of the type through the FullName property on
> the Type class, and the Assembly from the FullName property as well (you

can
> get the assembly that the type is in through the Assembly property on the
> Type).
>
> Once you have these, you can pass the assembly name to the static Load
> method on the Assembly class. This will load the assembly into memory.
> Once you have the Assembly instance, you can call CreateInstance on it,
> passing the full type name, and casting the return value to the interface
> that you know is defined on it. From there, you call your methods.
>
> I've attached a sample program which shows you how to do it. Compile
> and run it as a console app, and it should show you what I mean.
>
> Hope this helps.
>
>
> --
> - Nicholas Paldino [.NET/C# MVP]
> - (E-Mail Removed)
>
>
>
>
> "Nick Malik" <(E-Mail Removed)> wrote in message
> news:ujMRc.274386$Oq2.5582@attbi_s52...
> > I appreciate the advice Nicholas,
> >
> > I do not need the ability to unload the DLL... at least, I'm willing to

> live
> > without it. The need for this is fairly light. So, no app domains.
> >
> > What I want to do is provide a way for business users to control and

> manage
> > a workflow by modifying an XML file. They can play with this in their

own
> > environment and, when it is right, send it to the deployment team who

runs
> a
> > utility or two against it to deploy to production.
> >
> > The trick is this: there is no reasonable way to capture the

complications
> > of business rules in a simple XML description of a workflow. I need to
> > provide .NET DLLs to the business unit that will perform their rules.

The
> > XML needs to provide a description for each object sufficient to allow

me
> to
> > find it and load it. I am certain that the business users will not

modify
> > the settings in the XML that refer to DLLs.
> >
> > I do plan to use an interface. However, I still need to load the DLL

that
> > uses that interface based on the text in the XML.
> > At that point, I run right into the limits on my knowedge. I do not

know
> if
> > I will be able to tell if the user referenced a DLL that exists or not,

or
> > if they decided to try referencing a dll that they created, using the

> right
> > names but not inheriting properly.
> > Maybe the attributes won't help much in this case. I just don't know

> (yet).
> >
> > I'm still heavily in the design stage on this... I plan to be working on
> > proof-of-concept within the week. I'll post info as I find it.
> >
> > Thanks for the advice.
> >
> > --- Nick
> >
> > "Nicholas Paldino [.NET/C# MVP]" <(E-Mail Removed)> wrote

> in
> > message news:%(E-Mail Removed)...
> > > Nick,
> > >
> > > I think a better idea would be to use an interface, since that

way,
> > you
> > > don't have to make late bound calls every time you want to make the

> call.
> > >
> > > If you can't do that, then yes, I would go with placing an

attribute
> > on
> > > the method that you want to call. The problem with this is that you

> don't
> > > have type-safety. The signature could be wrong and you would get a

> > run-time
> > > error when trying to call it. Generally not a good thing.
> > >
> > > If you need the ability to unload the DLL, then you will have to

use
> a
> > > separate app domain. DLLs are not unloaded from an app domain until

the
> > app
> > > domain shuts down. Otherwise, I would advise against it (also, it

might
> > not
> > > be possible within the context if ASP.NET to create a new app domain).
> > >
> > > Hope this helps.
> > >
> > >
> > > --
> > > - Nicholas Paldino [.NET/C# MVP]
> > > - (E-Mail Removed)
> > >
> > >
> > > "Nick Malik" <(E-Mail Removed)> wrote in message
> > > news:P1LRc.118168$eM2.78543@attbi_s51...
> > > > reposting to a wider audience
> > > >
> > > > "Nick Malik" <(E-Mail Removed)> wrote in message
> > > > news:WYONc.203854$XM6.119642@attbi_s53...
> > > > > My turn to ask a question
> > > > >
> > > > > I am working on a plug-in for Sharepoint that will allow a

developer
> > to
> > > > add
> > > > > workflow rules. One of the rules will inform the adapter that it

> > should
> > > > > load a DLL that the developer writes, find a method that matches a
> > > > > particular interface, and call it.
> > > > >
> > > > > I know, in general, I should be looking at the reflection classes.

> > Does
> > > > > anyone have any design advice for me, or good working examples

that
> > > would
> > > > > serve as a foundation, so I'm not re-inventing the wheel?
> > > > >
> > > > > Should I be loading the developer's DLL in a seperate App Domain?

> (My
> > > > > environment: Sharepoint is an IIS application. It runs in its own
> > > > > application pool on IIS6.) My code is already running in a

> protected
> > > > > environment since I'm already using Sharepoint's plug-in

> architecture
> > to
> > > > > host my app.
> > > > >
> > > > > Should I use attributes to find the intended DLL, or should I

simply
> > > > require
> > > > > the developer to give me the name of the method to call?
> > > > >
> > > > > --
> > > > > --- Nick
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >

> >
> >

>
>
>



 
Reply With Quote
 
 
 
Reply

Thread Tools
Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
plse send troubleshooting methods about windows xp and windowsserver2003 about configuring user rights and security methods to implement touser lakshmikanthkkp456@gmail.com DIY PC 1 11th Apr 2008 09:58 AM
Calling non-static methods from within static methods. koredump Microsoft C# .NET 3 19th Jul 2007 01:33 PM
Calling methods in the Master Page advice Spondishy Microsoft ASP .NET 1 24th Aug 2006 11:49 PM
Design advice needed: loading a DLL and calling the methods in it Nick Malik Microsoft C# .NET 5 10th Aug 2004 02:46 PM
Re: Loading assemblies and calling methods. Suzanne Cook [MS] Microsoft Dot NET 0 5th Aug 2003 11:43 PM


Features
 

Advertising
 

Newsgroups
 


All times are GMT +1. The time now is 10:44 PM.