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]" <mv*@spam.guard.caspershouse.com> wrote in
message news:%2****************@TK2MSFTNGP11.phx.gbl...
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]
- mv*@spam.guard.caspershouse.com
"Nick Malik" <ni*******@hotmail.nospam.com> wrote in message
news:P1LRc.118168$eM2.78543@attbi_s51... reposting to a wider audience
"Nick Malik" <ni*******@hotmail.nospam.com> 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
