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

Discussion in 'Microsoft Dot NET' started by Nick Malik, Aug 9, 2004.

  1. Nick Malik

    Nick Malik Guest

    reposting to a wider audience

    "Nick Malik" <> 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
    >
    >
    >
     
    Nick Malik, Aug 9, 2004
    #1
    1. Advertisements

  2. 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]
    -


    "Nick Malik" <> wrote in message
    news:p1LRc.118168$eM2.78543@attbi_s51...
    > reposting to a wider audience
    >
    > "Nick Malik" <> 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
    > >
    > >
    > >

    >
    >
     
    Nicholas Paldino [.NET/C# MVP], Aug 9, 2004
    #2
    1. Advertisements

  3. Nick Malik

    Nick Malik Guest

    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]" <> wrote in
    message news:%...
    > 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]
    > -
    >
    >
    > "Nick Malik" <> wrote in message
    > news:p1LRc.118168$eM2.78543@attbi_s51...
    > > reposting to a wider audience
    > >
    > > "Nick Malik" <> 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
    > > >
    > > >
    > > >

    > >
    > >

    >
    >
     
    Nick Malik, Aug 9, 2004
    #3
  4. 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]
    -




    "Nick Malik" <> 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]" <> wrote

    in
    > message news:%...
    > > 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]
    > > -
    > >
    > >
    > > "Nick Malik" <> wrote in message
    > > news:p1LRc.118168$eM2.78543@attbi_s51...
    > > > reposting to a wider audience
    > > >
    > > > "Nick Malik" <> 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
    > > > >
    > > > >
    > > > >
    > > >
    > > >

    > >
    > >

    >
    >
     
    Nicholas Paldino [.NET/C# MVP], Aug 9, 2004
    #4
  5. Nick Malik

    Nick Malik Guest

    I truly appreciate your helpfulness. Thank you.

    --- Nick

    "Nicholas Paldino [.NET/C# MVP]" <> wrote in
    message news:%...
    > 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]
    > -
    >
    >
    >
    >
    > "Nick Malik" <> 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]" <> wrote

    > in
    > > message news:%...
    > > > 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]
    > > > -
    > > >
    > > >
    > > > "Nick Malik" <> wrote in message
    > > > news:p1LRc.118168$eM2.78543@attbi_s51...
    > > > > reposting to a wider audience
    > > > >
    > > > > "Nick Malik" <> 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
    > > > > >
    > > > > >
    > > > > >
    > > > >
    > > > >
    > > >
    > > >

    > >
    > >

    >
    >
    >
     
    Nick Malik, Aug 10, 2004
    #5
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Grandma Wilkerson

    Calling methods from constructor?

    Grandma Wilkerson, Jul 17, 2003, in forum: Microsoft Dot NET
    Replies:
    2
    Views:
    532
    Jon Skeet
    Jul 17, 2003
  2. Gayanga Alagiyawanna

    Calling methods in a VB.NET dll from VB 6.0

    Gayanga Alagiyawanna, Jul 21, 2003, in forum: Microsoft Dot NET
    Replies:
    1
    Views:
    244
    Sridhar
    Jul 21, 2003
  3. QINGFENG

    Calling MC++ methods in C# application

    QINGFENG, May 20, 2004, in forum: Microsoft Dot NET
    Replies:
    3
    Views:
    135
  4. Kevin
    Replies:
    2
    Views:
    260
    Kevin
    Aug 16, 2007
  5. mazdotnet

    Professional design advice needed

    mazdotnet, Apr 30, 2008, in forum: Microsoft Dot NET
    Replies:
    1
    Views:
    140
    Mr. Arnold
    Apr 30, 2008
Loading...

Share This Page