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
> > >
> > >
> > >
> >
> >
>
>
Similar Threads
