?
=?ISO-8859-1?Q?Lasse_V=E5gs=E6ther_Karlsen?=
I have two questions. The first question is simply if what I'm about to
describe is the best way to do what I want to do. If not then I'd very
much like to know how others are solving similar issues.
What I have done is to build a class library with some general code in
it. Part of this code is a system where I can apply an attribute to a
class and this class also implements an interface. As part of this
general code I have a static constructor that will iterate over all
assemblies in the current appdomain, and then iterate over all types in
those assemblies, and any classes it finds that has that attribute
applied to them will be stored in a dictionary. Specifically, I
construct an instance of the class found, and uses data from the
attribute as a key into a dictionary.
Later on I can call upon this general code to use the found classes,
specifying the key to get back, if know, the class that will handle this
key.
One such usage I have thought up for this is to build some code that can
dump out various object types to a stream for export as part of a crash
debug log. The classes would thus have an attribute applied to them that
specifies what kind of other class types it can handle, and thus dump
out the contents of. Later on, during such a crash, I would give an
"interesting" object that I'd wish to dump to the dump system and it
would pick either a generic dump object (uses reflection, understands
basic collections, etc.), or find a specific one for that object type
from that dictionary.
Since I don't want to pollute the general class library with references
to all kinds of other assemblies (like the ability to dump various
classes I only use in my web projects, etc.), I want to split up the
knowledge about those other classes into separate class libraries, to be
referenced by various types of applications when needed.
Ok, that was "what I want to do". If the above thing has a cleaner
solution, then I'm all ears.
Now, the second question is that since, in my application projects, I
don't specifically use anything from those "knowledge assemblies", they
were only referenced by the original project, they aren't loaded when
the program starts. Thus, by the time that static constructor starts
scanning the app domain, it won't find any of those classes.
The solution is of course simple enough, I can "use" something from
those assemblies, at the very least just by doing this:
Type dummy = typeof(SomeClassInThoseOtherAssemblies);
during application load. Is there any other, automagic, way to get those
assemblies to load by themselves, so that just the reference is enough?
I'm guessing that what I'm asking for is some kind of project setting or
assembly attribute I can apply that will automagically load the assembly
when the program starts, even though I haven't specifically named any
type in it, but that I'm just going to discover them through reflection.
Hope anyone took the time to read this can think of a helpful answer, or
even just a pointer to something to google for or look at. Anything is
welcome.
describe is the best way to do what I want to do. If not then I'd very
much like to know how others are solving similar issues.
What I have done is to build a class library with some general code in
it. Part of this code is a system where I can apply an attribute to a
class and this class also implements an interface. As part of this
general code I have a static constructor that will iterate over all
assemblies in the current appdomain, and then iterate over all types in
those assemblies, and any classes it finds that has that attribute
applied to them will be stored in a dictionary. Specifically, I
construct an instance of the class found, and uses data from the
attribute as a key into a dictionary.
Later on I can call upon this general code to use the found classes,
specifying the key to get back, if know, the class that will handle this
key.
One such usage I have thought up for this is to build some code that can
dump out various object types to a stream for export as part of a crash
debug log. The classes would thus have an attribute applied to them that
specifies what kind of other class types it can handle, and thus dump
out the contents of. Later on, during such a crash, I would give an
"interesting" object that I'd wish to dump to the dump system and it
would pick either a generic dump object (uses reflection, understands
basic collections, etc.), or find a specific one for that object type
from that dictionary.
Since I don't want to pollute the general class library with references
to all kinds of other assemblies (like the ability to dump various
classes I only use in my web projects, etc.), I want to split up the
knowledge about those other classes into separate class libraries, to be
referenced by various types of applications when needed.
Ok, that was "what I want to do". If the above thing has a cleaner
solution, then I'm all ears.
Now, the second question is that since, in my application projects, I
don't specifically use anything from those "knowledge assemblies", they
were only referenced by the original project, they aren't loaded when
the program starts. Thus, by the time that static constructor starts
scanning the app domain, it won't find any of those classes.
The solution is of course simple enough, I can "use" something from
those assemblies, at the very least just by doing this:
Type dummy = typeof(SomeClassInThoseOtherAssemblies);
during application load. Is there any other, automagic, way to get those
assemblies to load by themselves, so that just the reference is enough?
I'm guessing that what I'm asking for is some kind of project setting or
assembly attribute I can apply that will automagically load the assembly
when the program starts, even though I haven't specifically named any
type in it, but that I'm just going to discover them through reflection.
Hope anyone took the time to read this can think of a helpful answer, or
even just a pointer to something to google for or look at. Anything is
welcome.