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 wrong... 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 To: VBA Subject: [dba-VB] Multi-project solution I launched in to building a C# application where I divided the solution into projects. 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 project's 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 www.ColbyConsulting.com _______________________________________________ dba-VB mailing list dba-VB at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-vb http://www.databaseadvisors.com