I am having a lot of trouble trying to wrest from the IDE the flexibility I want so that I can build assemblies that have only one control -- or several ...

Can someone help?

Desired Result
There are two goals:
a) The base idea is to write lots of controls that share a common set of methods/functions, in order to not cut/paste a lot of repetition code.
b) Be able to write controls so that they can be compiled as one unit (ie 10 or so controls to one assembly) or publishable to the web as single control assemblies.
I've written several controls that people may like, and I would like to publish them. For my own use, I prefer working with one big "MyControls.dll" -- but for articles, it would be best that the reader has to deal with only one at a time....

In other words, I need to be able to build for both worlds...
I have tried several approaches -- none seem satisfactory:


Copy CommonCode to each assembly:
Lets say I make a common class of Helper functions that each control may use (probably will). Might even have a common ControlBase that all controls can enherit from.
If it were just one big assembly with the *.cs files of the controls actually in the assembly, the control does not grumble.
But life is generally not that nice and I end up with website structures that look much more like:

*WebSiteAsssemblyWith5orSoSpecificControls
*GeneralPackageOf20ControlsMadeInJune
*AnotherPackageWith10MoreControlsMadeInJuly
*ASingleControl
*AnotherSingleControl

What happens is that yes, the Compiler accepts it -- but it flags every single ref to the use of such common code with a warning saying -- watch out -- the same exact method exists in 5 different assemblies.... In other words, it doesn't seem to be a very happy Compiler...


Keep CommonCode in a separate Dll?
This solution is, in other words, based on the control having a dependancy...
I tried at first keeping the code in a common dll (called it Common.dll) and wire it in to each DLL, and the Compiler grumbles a bit as it multicopies the Common.dll from the bin of each Control.dll each time I rebuild the project.
This works in RunTime -- but it fails in DesignTime in the IDE, because the ControlBuilder tries to instantiate a control that doesn't have the right Common.dll build (The build num of the control the IDE is running will be looking for a Common.dll with a different build num...Got that?!?!) What I am saying is that DesignTime IDE does not accept to use controls that have dependancies -- it appears that it accepts to work with Controls that have no dependancies only.

GACL?
Sortof...I read that this could be resolved by giving Common.dll a Strong name and putting the Common.dll in the GACL...
But then we are right back to DLL hell. Plus, do website designers who have their sites hosted, have access to the GACL? Probably not, right? So not a good solution for sure.


Copy/Paste common code
Right now, I am copying common helper code from control to control. In other words, if there is a bug, I am copying to every other control. Total nightmare to track/repair.
This is making my code larger than necessary -- for dumb controls, some of the helper functions used for embedding resources, is larger than the actual control ! :-(((



Please! This issue has driven me nuts... It's got to be a common problem/solution... Just that I don't have enough experience with Compilers versus Interpreters to know how to organize my files correctly...no?

Thank you,
Sky

For those who may be looking for an answer to this -- it turns out that there is a way to have common code shared between control projects -- but not the way I was looking at first.

The alternate (only one I've found) solution is to use the very easy to miss 'Link' option when adding a file to a project.

Lets say you create a Common.dll assembly project:

MyCommon.csproj
- MyCommonCode.cs

And you want to use that in a second control:
MyControl1.csproj
- MyControl1.cs
- ...

And you want to include MyCommonControlCode.cs into it , but virtually linked, rather than copied, so that if you edit the file in either project it updates the other (debug once), you must do it this way:

a) From MyControl1.csproj project, click the Add existing file.
b) Find the file, but instead of clicking Ok, click the Arrow beside the Ok button...and you see an option to Link the file file rather than Open/Copy, which is the default... Voila. Linked file comes in with a little arrow symbol to indicate linking rather than separate copy.

For coders
What is happening in fact is that if you open the MyControl1.csproj file you will see that the file that is included looks like this instead of normal
<File RelPath="MyCommonCode.cs" Link="..\CommonCode\MyCommonControlCode.cs"
BuildAction="Compile"/>

Notice the Link attribute that it added.

Gotchas.
This may only be a bug in VS2002 -- don't know about VS2003 -- but if you drag ONE linked file to another project (eg from MyControl1 to MyControl2 project) then the link will stay correct. But if you drag a Folder that contains links (eg contains CommonCode1.cs and CommonCode2.cs) the results are unpredictable. Seems that it gets the first one or two correctly linked -- but that the rest don't. In other words, drag/drop with linking has a bug in VS2002.
I solved the problem by making a quick console script that modifies the XML of the csprojs and add links to any RelPath= that starts with "LinkedFiles\\"-- but its scary to do so....as you muck up a lot of projects fast with scripts like that... The plus side of such scripting solutions is that it has forced me to get very very organized when laying out my controls -- same dir rather than all over the place, same naming conventions throughout, etc....


Hope this helps someone else.
Sky