S
Sky Sigal
Please. I really really need help here deciding what to do.
I've been spending a lot of time lately building (hopefully) useful server
controls, and want to release them, some free, some not.
Except there's a hitch. A BIG one.
I'm not sure how to go about packaging them in order to keep
admin/tech-support/bug fixing time/costs down. I'm a one-man shop so this is
very very important.
I would like to share Interfaces, base classes, routines across all the
controls, in such a way that if a bug is reported in one of these shared
methods, that its easy to fix it for all controls, and release updates,
rather than have to manually update each control...which is prohibitevly
expensive, and makes the whole endeavor not worth doing.
* Approach number one: Separate assemblies for each control, one common lib
dll.
This is what I am doing at present: one common dll called Common.dll, which
contains the shared lib functions/classes.
One of these classes is CompositeControlBase (which enherits from the
frameworks BaseCompositeControl but adds a lot of oft-used features), and it
is the base class from which all my controls derive.
Pros:
+ Much faster control designing.
+ Much faster anticipated tech-support/debugging: fix it in one control, and
it fixes for all controls.
Cons:
- But its also a work in progress...and sometimes I have to add new stuff to
it/retinker...and remove stuff. There's no way I'm going to get that control
just right the first time...
- It's also a small head-ache for the end programmer, who at the start of a
new project, has to add a reference to BOTH dlls.
Extending this approach futher, will cause even more headaches:
Turns out that once I had the basic controls out of the way (Tabber, Tree,
TreeGrid, CalendarWeek, etc., I also designed some controls that either
enherit or encapsulate one or more of these base controls.
This is maybe fine for me...but it would be awful for an end programmer:
he/she would have to add references to CtrlC, then CtrlB, then CtrlA...but he
has no way of knowing which controls need what -- (he could I guess by
reading the docs that go with it, but not from the fileNames: CtrlC.dll is
not called CtrlC_CtrlA.dll or other hint...).
So this approach seems to be a disaster in the making.
* Another approach: Making a Suite/Single dll?
Ok. So dependancies, atleast in terms of controls, seems to have serious
issues.
Another approach could be lump everything into one dll as microsoft did with
System.Web.dll...
Except that I was not thinking of just 10 or 15 controls...but 40-50! That's
one stinkin' big dll for the end programmer to have to load up just to use
5/6 controls in a project...
* Another approach: Different Suites
Ok. So maybe not everything should be in one dll. How about 5 dlls of 10?
Here the problem is which goes where? BaseControls.Layout.dll,
BaseControls.Data.dll -- then what about controls that use base controls from
both? We're quickly back to loading up all dlls just to be safe...
* Another approach: Same classes in each control.
This really tickes me off for two reasons:
- Because instead of it being a 100k common lib dll and 50 controls of
10-20k, its now 50 controls
of 120k -- or one big monster of (100k + 50*20k=1100k).
- Bar the small fact that I havn't found a way to keep all the files in
synch (CSV? SVN? Link attribute in project files? Anybody have a suggestion?)
this makes it very hard to update the files when a bug is reported.
- On top of that: it doesn't work any longer in ASP.NET 2.0! In asp.net 1.1
one could have classes with the same name. So if I decided to copy/link the
files into each file, and be damned with the ease of fixing common bugs, the
compiler groaned a bit, but it was ok. A control would use the 'closest'
method (ie in same control's assembly rather than method with same name in
external assembly). But in ASP.NET 2.0 this is no longer allowed (name
conflict causes compiler to stop processing). So I would manually have to
edit each 'common' file so that its namespace/name was different and caused
no conflict...
There is no saved time from debugging: each file is now totally independant
of each other, even if the code is the same!
* CSV/ SVN:
I'm a real newbie at using code repositories: I just got SVN installed last
month, and it looks fantastic...except that I havn't yet seen how to put it
to use to deal with this problem (sharing projects). This is mostly probably
to do with the fact that i work alone and havn't seen how others are using
it. Maybe its possible? Care to share your thoughts/experiences?
It just strikes me as such a glaring basic problem that I feel that others
must have encountered what i am banging my head against the wall for and
figured out a way to work cost effectively at this.
If this doesn't seem to be such a problem to others, maybe its some
half-baked self-taught methodology that I picked up, have to get rid of? I
thought the whole point of dll's was the re-use of code? Or am I believing
the hype too much for real-world situations?
Very many thanks for listening,and really eager to hear back as many
suggestions as possible,
Sky
I've been spending a lot of time lately building (hopefully) useful server
controls, and want to release them, some free, some not.
Except there's a hitch. A BIG one.
I'm not sure how to go about packaging them in order to keep
admin/tech-support/bug fixing time/costs down. I'm a one-man shop so this is
very very important.
I would like to share Interfaces, base classes, routines across all the
controls, in such a way that if a bug is reported in one of these shared
methods, that its easy to fix it for all controls, and release updates,
rather than have to manually update each control...which is prohibitevly
expensive, and makes the whole endeavor not worth doing.
* Approach number one: Separate assemblies for each control, one common lib
dll.
This is what I am doing at present: one common dll called Common.dll, which
contains the shared lib functions/classes.
One of these classes is CompositeControlBase (which enherits from the
frameworks BaseCompositeControl but adds a lot of oft-used features), and it
is the base class from which all my controls derive.
Pros:
+ Much faster control designing.
+ Much faster anticipated tech-support/debugging: fix it in one control, and
it fixes for all controls.
Cons:
- But its also a work in progress...and sometimes I have to add new stuff to
it/retinker...and remove stuff. There's no way I'm going to get that control
just right the first time...
- It's also a small head-ache for the end programmer, who at the start of a
new project, has to add a reference to BOTH dlls.
Extending this approach futher, will cause even more headaches:
Turns out that once I had the basic controls out of the way (Tabber, Tree,
TreeGrid, CalendarWeek, etc., I also designed some controls that either
enherit or encapsulate one or more of these base controls.
This is maybe fine for me...but it would be awful for an end programmer:
he/she would have to add references to CtrlC, then CtrlB, then CtrlA...but he
has no way of knowing which controls need what -- (he could I guess by
reading the docs that go with it, but not from the fileNames: CtrlC.dll is
not called CtrlC_CtrlA.dll or other hint...).
So this approach seems to be a disaster in the making.
* Another approach: Making a Suite/Single dll?
Ok. So dependancies, atleast in terms of controls, seems to have serious
issues.
Another approach could be lump everything into one dll as microsoft did with
System.Web.dll...
Except that I was not thinking of just 10 or 15 controls...but 40-50! That's
one stinkin' big dll for the end programmer to have to load up just to use
5/6 controls in a project...
* Another approach: Different Suites
Ok. So maybe not everything should be in one dll. How about 5 dlls of 10?
Here the problem is which goes where? BaseControls.Layout.dll,
BaseControls.Data.dll -- then what about controls that use base controls from
both? We're quickly back to loading up all dlls just to be safe...
* Another approach: Same classes in each control.
This really tickes me off for two reasons:
- Because instead of it being a 100k common lib dll and 50 controls of
10-20k, its now 50 controls
of 120k -- or one big monster of (100k + 50*20k=1100k).
- Bar the small fact that I havn't found a way to keep all the files in
synch (CSV? SVN? Link attribute in project files? Anybody have a suggestion?)
this makes it very hard to update the files when a bug is reported.
- On top of that: it doesn't work any longer in ASP.NET 2.0! In asp.net 1.1
one could have classes with the same name. So if I decided to copy/link the
files into each file, and be damned with the ease of fixing common bugs, the
compiler groaned a bit, but it was ok. A control would use the 'closest'
method (ie in same control's assembly rather than method with same name in
external assembly). But in ASP.NET 2.0 this is no longer allowed (name
conflict causes compiler to stop processing). So I would manually have to
edit each 'common' file so that its namespace/name was different and caused
no conflict...
There is no saved time from debugging: each file is now totally independant
of each other, even if the code is the same!
* CSV/ SVN:
I'm a real newbie at using code repositories: I just got SVN installed last
month, and it looks fantastic...except that I havn't yet seen how to put it
to use to deal with this problem (sharing projects). This is mostly probably
to do with the fact that i work alone and havn't seen how others are using
it. Maybe its possible? Care to share your thoughts/experiences?
It just strikes me as such a glaring basic problem that I feel that others
must have encountered what i am banging my head against the wall for and
figured out a way to work cost effectively at this.
If this doesn't seem to be such a problem to others, maybe its some
half-baked self-taught methodology that I picked up, have to get rid of? I
thought the whole point of dll's was the re-use of code? Or am I believing
the hype too much for real-world situations?
Very many thanks for listening,and really eager to hear back as many
suggestions as possible,
Sky