Design Q

[Michael C]

I have a windows exe project that has all data access code in a dll. Some of
the fields have values that correspond to an enum, eg

enum VideoSizeMode
{
FitToScreen = 1,
FitToScreenKeepAspect = 2,
NativeSize = 3
}

If I define VideoSizeMode in the dll then both the dll and exe can use the
enum no probs and everything work's fine. The problem is I would like to
create a usercontrol in a seperate project that will be referenced by the
exe but won't be dependant on the dll or exe, so that it could be reused in
another project say. I would like this seperate usercontrol to be able to
use the enum also. How would you guys approach this? If I define the enum in
the dll then the usercontrol cannot use it but if I define it in the
usercontrol then the dll can't use it. I can think of lots of options but no
good solutions.

Many thanks,
Michael

 

[Barry Kelly]

The problem is I would like to
create a usercontrol in a seperate project that will be referenced by the
exe but won't be dependant on the dll or exe

I can think of lots of options but no
good solutions.

Here are three solutions to your problem:

1) Create the enum in some (possibly new) .dll and make the other
..dll(s) reference it.

2) Take the pain to convert between enumeration values in all your
clients, marshalling values of one enumeration type to the other.

3) Use generics or polymorphism to make the enum dependency
parameterized based on passing in the enumeration type at construction /
type instantiation time.

Perhaps you could explain more about your problem? If the enumeration
describes elements of some semantic domain, and those enumeration
elements must be referenced in some set of DLLs D, it stands to reason
that there must be some definitive enum declaration in some DLL d in D,
which all the other DLLs reference.

In my own solutions, I create a *.Base.dll assembly which contains all
the base definitions of any commonality across all the different
projects.

-- Barry

 

[Michael C]

Here are three solutions to your problem:

1) Create the enum in some (possibly new) .dll and make the other
.dll(s) reference it.

I'm not too keen on this idea as it can cause problems if the dll is rebuilt
it forces you to rebuild everything that depends on it.

2) Take the pain to convert between enumeration values in all your
clients, marshalling values of one enumeration type to the other.

That's possible, although not ideal. Possibly the ideal solution would be if
I could just define the enum in both dlls and have dotnet automatically
handle the conversion (assuming both are completely identical).

3) Use generics or polymorphism to make the enum dependency
parameterized based on passing in the enumeration type at construction /
type instantiation time.

I'm using 1.1 at the moment but this could be the perfect solution maybe.

Perhaps you could explain more about your problem? If the enumeration
describes elements of some semantic domain, and those enumeration
elements must be referenced in some set of DLLs D, it stands to reason
that there must be some definitive enum declaration in some DLL d in D,
which all the other DLLs reference.

I have an usercontrol that is a medical chart with certain items on it that
can be selected by the user. Each item coresponds to an enum. Currently the
chart is a usercontrol in the exe but I would like to move it into a
seperate dll to be used in other projects.

In my own solutions, I create a *.Base.dll assembly which contains all
the base definitions of any commonality across all the different
projects.

I could see that being a problem as I might use my usercontrol in several
projects and the second project will likely have a lot less definitions that
are not appropriate to it.

Michael