"Jeff Gaines" <whitedragon@xxxxxx> wrote in message
news:xn0furzjc3ujlb000@xxxxxx
Quote:
Quote:
>>You need to think about organization of your modules before you write
>>them. An ad-hoc approach where you just slap the class where it's easier
>>(for now), and assembly partitions are arbitrary, doesn't scale.
>
> Each class/control sits in its own directory and uses my standardised
> directory/namespace/class naming for consistency. ....
Quote:
> That could work, each class has its own project so I would just need to
> add those projects to the new project, and ensure the dependencies are
> clear. I will look at that.
Note that you can have a single assembly (i.e., project) with multiple
classes, where each class is still in a separate folder (under that project
folder). There's nothing wrong with that, especially if the classes are
logically related and have lots of dependencies between them.
Quote:
> I was thinking more of a 21st century #include pragma. If I have, say, a
> ListViewEx class with a dozen or so related classes it would be good to
> #include those classes in the main class file. Then it would only be
> necessary to link to the main class file when using it in another project.
..NET doesn't define dependencies in terms of classes, but rather in terms of
assemblies. For assemblies, you can do pretty much what you described, so
long as your dependencies are not exposed in public members of your class.
In other words, if you have class A in project/assembly PA depend on class B
in assembly PB, which in turn depends on class C in assembly PC, then you
only need a reference to PB in PA, not to PC. You'll need a reference to PC
only if class B extends class C, or if you use a public member of B that
references C in its signature.
Quote:
> I could add a reference to the class file dll but would then probably need
> one instance of VS running for each class project to alter/update on the
> hoof so to speak. Probably adding the original projects is easier.
Once again, you do not need an instance of VS per project. You can have a
single solution with as many projects as you wish, and you only need one
instance of VS to work with that solution, and it will be entirely displayed
in Solution Explorer with all the child projects.