References simplification

Mar 26, 2009 at 2:41 PM
I think it would be a good idea to remove all references to the log4net library as it's used only in a couple of files forcing users to distribute another dll. Logging functions could be implemented via interfaces and a sort of 'plugin' architecture.
Another good simplification in my opinion would be that of joining DevAge.Core, DevAge.Windows.Forms and SourceGrid into a single project, to make easier to distribute SourceGrid as a single dll.
Mar 28, 2009 at 9:47 PM
I agree, log4net is not used that much in SourceGrid.  It wonder how other open-source projects handle that.
As far as i know, Castle Project and NHibernate uses log4net.

As for joining DevAge.Core, DevAge.WIndows.Forms, and SourceGrid into single dll i see no benefits. Having to distribute SourceGrid not as a single dll is not a hindrance and till now i have not heard of any problems.    However, on the contrary, having all projects grouped would make versioning more difficult, since all functionality would have to be versioned as a single-whole
Mar 29, 2009 at 11:02 PM
Logging could be moved into #if DEBUG .. #endif so that log4net would not be required for release builds
Mar 30, 2009 at 7:28 AM
Basically this project is about a single component, the grid, so I see it's a little strange to have to distribute at least three dlls for a single component, while other projects do a lot of work to reduce the number of files to be distributed. Maybe a little refactoring could be useful to join the three projects into a single dll, as the other dlls are used only for base classes.

Versioning is not a problem to me as all the functionality are focused on one single component, so every change you make has ripercussions on the grid making all the dlls they are strictly tied. It makes no sense to use more than one versioning scheme (it doesn't make sense to use SourceGrid.dll v.4.20 with DevAge.Core.Dll 3.0 or whatever not built with SourceGrid.dll 4.20).
The only problem with versioning is the use of Subversion instead of another (modern) scm but this is another story and doesn't depend on the project leaders.. .:-)
Mar 30, 2009 at 8:40 PM
Edited Mar 30, 2009 at 8:41 PM
I do think that it could be useful to merge DevAge.Core and DevAge.Windows.Forms in one and SourceGrid and SourceGrid.Extensions in another. If not merging SourceGrid and extensions than moving DataGrid to main SourceGrid and leaving only Planning grid and other rarely used stuff in extensions dll.

Just out of curiosity why do you think of Subversion as not being 'modern'? I mean what does it really miss?
Mar 31, 2009 at 7:07 AM
Try git or bazaar and you'll see by yourself what 'modern' means... :-)
I used svn for some years and I really liked it, then I discovered distributed version control systems like git or bazaar and they really changed the way I work, in better.
Local repository is invaluable, pushing and pulling of changes without a central repository makes work really versatile and you'll end with a lot less conflicts than using svn.
That's just my personal opinion, based on my experience and the way I work and people at svn are smart but I think there are now far better products.
Mar 31, 2009 at 1:01 PM
oh.. if you are talking about distributed vcs than ok :) I just thought you are talking about TFS :)
Only problem with git and bazaar is decent ide integration that is missing. Also I think distributed vcs is really usfull for big projects with many developers working on it, otherwise subversion is more than enaugh.
Mar 31, 2009 at 6:51 PM
Frank, thanks for your reply, it really has some good points.
But i still wonder why do other projects work hard to reduce the number of files to be distributed? What are the pros and cons of doing either way?
Apr 1, 2009 at 9:25 AM
In my opinion the number of files should be reduced for two reasons:
- usually projects make use of a number of external (or internal) libraries. If all libraries have many dlls you'll end up with a thousand dlls in your client application
- if a project is limited to one single component (ie SourceGrid) I see no reason to have more than one dll if all the code is focused on that single component. Even upgrading to a new version is simpler, you have to just replace one single dll, and modifications are way easier. For example I use a slightly modified version of the source code and I had to recompile three projects instead of one, and check the versions of three dlls instead of one.
Apr 1, 2009 at 10:12 AM
In my opinion it would enought to merge DevAge.Core and DevAge.Windows.Forms into one as these can be used without grid just fine and threre are usefull controls.
Second would be merge SourceGrid and SourceGrid.Extensions into one or at least moving DataGrid and ArrayGrid to SourceGrid and leaving only PlanningGrid and ListEditor in extensions dll.
Apr 1, 2009 at 10:29 AM
Two dlls would be good also if there is a need for separation, otherwise a single dll that contains all the controls as a 'package' would be good too, it's just a matter of organization of namespaces,
Apr 1, 2009 at 6:55 PM
Merging projects into two dlls sound a reasonable solution. This decision might take some time to get approved and implemented. I will let you know of any progress.
Apr 3, 2009 at 4:15 PM
I think that you are right, I agree to merge all the project into one.

The first version of SourceGrid was only a single dll then I have split the code just to reuse some controls on another project. But then I have realized that SourceGrid drawing code is too specific and cannot be reused.

Basically I think that was a mistake to split the code and probably now we can merge it again.

Write me if you need help merging the project.
Just consider for now to create a new root directory, I suggest to create "\trunk\SourceGrid\". Then we can move the old code (SourceGrid4 and DevAgeSourcePack4) to a branch folder.

What do you think?