[dba-VB] Multi-project solution

Shamil Salakhetdinov shamil at smsconsulting.spb.ru
Sat Jun 12 01:43:11 CDT 2010

Hi John --

You can just keep your "solution's wide" settings defined on lowest level
class library. Or one level up from lowest level class library:

- bottom level class lib: MyUtilities.ClassLib.dll
- one level up from the bottom class lib: MyAppsSettings.ClassLib.dll

Is it just me or is this project 
thing a lot of extra effort for what you get?  
It needs a bit more extra efforts when you're using multi-project solutions
but it gives a lot more flexibility...

And I have found I do often use "copy & paste ugly development approach"
when I'm starting developing "MyAppSettings.ClassLib.dll" for the next
multi-project solution - you'll probably try to make this level classlib
very generic - I have found it doesn't worth to do that - you may find I was

And I have developed more than 50(?) multi-project solutions by now with up
to 10 or more projects within a solution...

I must also say I rarely use built-in settings handling approach - I do use
my own XML settings files (often several such settings files for a
solution), and I do handle them by using LINQ for XML - near to zero efforts
to load and save settings files, but some more efforts for settings
properties (getters/setters) wrapping code (up to several hours of work for
a large sets of settings files) - and a lot more of flexibility comparing to
standard settings handling approach...

Thank you.

- Shamil

P.S. Once set/saved computer level standard settings are saved somewhere on
the target system - I'm still to find where I must say - I'm "all years" to
know where they are saved...

-----Original Message-----
From: dba-vb-bounces at databaseadvisors.com
[mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Saturday, June 12, 2010 12:24 AM
Subject: [dba-VB] Multi-project solution

I launched in to building a C# application where I divided the solution into

It certainly seems to make sense, a solution can have multiple solutions,
and each solution becomes 
an arm in a tree structure inside of the solution.

OTOH each project has an entire set of properties all it's own.  They are
not inherited from parent 
(solution) properties.  I don't claim to be any guru but it sure seems that
many of the properties 
in the project really should apply to the entire solution.  For example each
project has a 
properties.Settings.  However there is no Solution.properties object at all
AFAICT, never mind a 
Solution.Properties.Settings.  Thus (for example) I have a server name, a
bunch of paths on the 
server etc.  All of those things have to be declared over and over in each
Properties.Setting or... have to be declared in one specific project and
then that project 
referenced in every other project.

Is it just me or is this project thing a lot of extra effort for what you
get?  What specifically DO 
you get?

John W. Colby
dba-VB mailing list
dba-VB at databaseadvisors.com

More information about the dba-VB mailing list