Build Logica

1. Copying all into loader/bin/ - won't make things faster, but certainly much less simple, what can really help is adding check in PluginPostBuild.cmd: foreach dll in plugin TargetDir, if dll exists in loader/bin - do nothing, otherwise copy dll to loader/bin/<plugin-name>/.

Having plugins in a separate directories is absolute a must, otherwise

• it will be a big recycle bin which will grow in the future like current version, please don't do it
• disabling plugin won't be that simple, dependencies will be uncler (loader will contain gdal.dll, org.dll, Nhibernate.dll, delft_flow_openmi.dll, OpenMI.Oatc.Sdk.dll and many other things. Plus some model dlls may actually use different version of FORTRAN - they must be in a separate folders, this is a requirement.
• using different version of the libraries in different plugins won't be possible (e.g. upgrade from old file format to a new one - load old version of DataAccess).

When current structure appeared - KISS, YAGNI, etc. principles were used as well , but also

... "Everything should be made as simple as possible, but not simpler". Kent Beck defines four traits of simplicity: passes all tests, reveals intentions, no duplication, and smallest codebase. In other words, "simple" software should do what it is supposed to do, but no more, and it should do it with the least amount of code possible, while still being easy to understand...

If we put all in one directory - we will violate "... while still being easy to understand." principle.

Note that all dlls in <plugin>/lib/ are supposed to be used only by one plugin, in this case they should be copied only once to the target loader/bin/<plugin> directory. Otherwise they can be moved to the top-level lib/ and then from there they should be also copied only once. So I won't expect any speed-ups there. Digg more .

2. improve PostSharp: sounds like a good option, I added copy action since there were conflicts between PostSharp and VS, maybe it is already fixed.

Also we should probably remove PostSharp interception of fields - this probably also makes compilation slower, plus run-time as well.

3. Geen extra acties binnen build loader - also sounds fine, except 1 time copy of all dlls from top-level lib. Loader bin/Debug currently contains only DelftShell and (1) libraries shared by any other component like DelftShell, DelftTools or any plugin and everything there is loaded during system start-up.

Any other copy/delete actions there must be gone.

4. DelftShell/lib - can be removed, it won't change anything. lib is there from old version where it contained many things, now they're move to plugins. DelftShell is just another component, like any plugin project (README.txt):

<component>................... plugin, framework, top-level gui, etc.
   +---data/
   +---doc/
   +---lib/
   +---modules/
         +----Project1/
         +----Project2/
         +----Project3/
   +---tests/
         +----Project1.Tests/
         +----Project2.Tests/
         +----Project3.IntegrationTests/

5. yep, dependencies should be reduced, we should analyze dependencies and decouple things a little (not too much). For example DelftTools.DataObjects depends on GeoAPI.dll which doesn't change much, but also on NTS and NTS.Extensions - that's not necessary, if we will use GeometryFactory - this dependency can be removed. There are probably other examples as well. Actions:

• analyze top-level libraries and check dependencies between them, check what can be decoupled.
• decouple all plug-ins from each-other (use IoC, DI instead)
• introduce Windsor.Castle to resolve dependencies at run-time

Current order of project builds is (from NDepend):

DelftTools.Utils
DelftTools.Units
DelftTools.Core
DelftTools.Gui
DelftTools.Gui.Swf.Controls
DelftTools.DataObjects.Functions
GeoAPI
GeoAPI.Extensions
NetTopologySuite
DelftTools.DataObjects
DelftShell.Core
DelftShell.Gui
DelftShell.Loader
DelftShell.Plugins.CommonTools
DelftShell.Plugins.Data.NHibernate
DelftModelApi.Net
DelftModelServer
NetTopologySuite.Extensions
DelftShell.Plugins.DelftModels.FlowModel
DelftShell.Plugins.NetCDF
SharpMap
SharpMap.Extensions
SharpMap.UI
DelftShell.Plugins.SharpMapGis
DelftShell.Plugins.NetworkEditor
DelftShell.Plugins.DeveloperTools
DelftShell.Plugins.ImportExport
DelftShell.Plugins.UdUnits
DelftShell.Plugins.ProjectExplorer

Now I'm doing a small test building DelftTools.DataObjects.Functions.Test and getting the output below (takes 4sec which is good enouth?), some things there maybe can be reduced, e.g. gui why does it run sgen.exe???:

_
------ Build started: Project: DelftTools.Utils, Configuration: Debug Any CPU ------
DelftTools.Utils -> D:\src\DelftTools\apps\DelftTools\modules\DelftTools.Utils\bin\Debug\DelftTools.Utils.dll
------ Build started: Project: DelftTools.Units, Configuration: Debug Any CPU ------
DelftTools.Units -> D:\src\DelftTools\apps\DelftTools\modules\DelftTools.Units\bin\Debug\DelftTools.Units.dll
------ Build started: Project: GeoAPI, Configuration: Debug Any CPU ------
GeoAPI -> D:\src\DelftTools\apps\DelftShellPlugins\SharpMapGis\modules\GeoAPI\bin\Debug\GeoAPI.dll
------ Build started: Project: DelftTools.DataObjects.Functions, Configuration: Debug Any CPU ------
DelftTools.DataObjects.Functions -> D:\src\DelftTools\apps\DelftTools\modules\DelftTools.DataObjects.Function\bin\Debug\DelftTools.DataObjects.Functions.dll
------ Build started: Project: GeoAPI.Extensions, Configuration: Debug Any CPU ------
GeoAPI.Extensions -> D:\src\DelftTools\apps\DelftShellPlugins\SharpMapGis\modules\GeoAPI.Extensions\bin\Debug\GeoAPI.Extensions.dll
------ Build started: Project: NetTopologySuite, Configuration: Debug Any CPU ------
NetTopologySuite -> D:\src\DelftTools\apps\DelftShellPlugins\SharpMapGis\modules\NetTopologySuite\bin\Debug\NetTopologySuite.dll
------ Build started: Project: DelftTools.Core, Configuration: Debug Any CPU ------
DelftTools.Core -> D:\src\DelftTools\apps\DelftTools\modules\DelftTools.Core\bin\Debug\DelftTools.Core.dll
------ Build started: Project: DelftTools.DataObjects, Configuration: Debug Any CPU ------
DelftTools.DataObjects -> D:\src\DelftTools\apps\DelftTools\modules\DelftTools.DataObjects\bin\Debug\DelftTools.DataObjects.dll
------ Build started: Project: DelftTools.Gui, Configuration: Debug Any CPU ------
C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\sgen.exe /assembly:\src\DelftTools\apps\DelftTools\modules\DelftTools.Gui\obj\Debug\DelftTools.Gui.dll /proxytypes /reference:\src\DelftTools\apps\DelftTools\modules\DelftTools.Core\bin\Debug\DelftTools.Core.dll /reference:\src\DelftTools\apps\DelftTools\modules\DelftTools.DataObjects\bin\Debug\DelftTools.DataObjects.dll /reference:\src\DelftTools\apps\DelftTools\modules\DelftTools.Utils\bin\Debug\DelftTools.Utils.dll /reference:..\..\..\..\lib\log4net.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.configuration.dll /reference:"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll" /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Data.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll /compiler:/keyfile:DelftTools.snk
DelftTools.Gui -> D:\src\DelftTools\apps\DelftTools\modules\DelftTools.Gui\bin\Debug\DelftTools.Gui.dll
------ Build started: Project: DelftTools.Gui.Swf.Controls, Configuration: Debug Any CPU ------
DelftTools.Gui.Swf.Controls -> D:\src\DelftTools\apps\DelftTools\modules\DelftTools.Gui.Swf.Controls\bin\Debug\DelftTools.Gui.Swf.Controls.dll
------ Build started: Project: NetTopologySuite.Extensions, Configuration: Debug Any CPU ------
NetTopologySuite.Extensions -> D:\src\DelftTools\apps\DelftShellPlugins\SharpMapGis\modules\NetTopologySuite.Extensions\bin\Debug\NetTopologySuite.Extensions.dll
------ Build started: Project: SharpMap, Configuration: Debug Any CPU ------
SharpMap -> D:\src\DelftTools\apps\DelftShellPlugins\SharpMapGis\modules\SharpMap\bin\Debug\SharpMap.dll
------ Build started: Project: SharpMap.Extensions, Configuration: Debug Any CPU ------
SharpMap.Extensions -> D:\src\DelftTools\apps\DelftShellPlugins\SharpMapGis\modules\SharpMap.Extensions\bin\Debug\SharpMap.Extensions.dll
------ Build started: Project: SharpMap.UI, Configuration: Debug Any CPU ------
SharpMap.UI -> D:\src\DelftTools\apps\DelftShellPlugins\SharpMapGis\modules\SharpMap.UI\bin\Debug\SharpMap.UI.dll
------ Build started: Project: DelftTools.TestUtils, Configuration: Debug Any CPU ------
DelftTools.TestUtils -> D:\src\DelftTools\apps\DelftTools\tests\DelftTools.TestUtils\bin\Debug\DelftTools.TestUtils.dll
------ Build started: Project: DelftTools.DataObjects.Functions.Tests, Configuration: Debug Any CPU ------
DelftTools.DataObjects.Functions.Tests -> D:\src\DelftTools\apps\DelftTools\tests\DelftTools.DataObjects.Functions.Tests\bin\Debug\DelftTools.DataObjects.Functions.Tests.dll
========== Build: 16 succeeded or up-to-date, 0 failed, 0 skipped ==========
_

Assemblies Dependencies

Here some big part is Designer-generated code, plus NTS should be excluded

Build times on my pc:

Without PostSharp 2:45

With PostSharp 1.0 via MSBuild 8 minutes
With PostSharp 1.5 via MSBuild 7 minutes

With PostSharp 1.0 via PostbuildEvent 7 minutes (current situation)
With PostSharp 1.5 via PostbuildEvent not working

Times may vary as compile is repeated. Also memory usage increases.

Concerning PostSharp interception of fields: You could skip auto-generated backing-fields. Other fields
should be intercepted since they can have a public property counterpart. eg:

    public class Person
    {
        private string name;

        public string Name
        {
            get { return name; }   
            set { name = value;}
        }

        private ChangeToBassie()
        {
            name = "bassie"
        }
    }

Changing the private field name will result in a change in Name and should cause a propertychanged. Thus if we skip all private fields we should use public properties internally in the class as well

Plugin
------

DelftShell.Plugins.NetworkEditor

call "$(SolutionDir)\bin\PluginPostBuild.cmd" "$(SolutionDir)" "$(TargetDir)" $(ProjectName)

call "$(SolutionDir)\bin\PluginPostBuild.cmd" $(ProjectName) $(ConfigurationName) SharpMap
call "$(SolutionDir)\bin\PluginPostBuild.cmd" $(ProjectName) $(ConfigurationName) SharpMap.UI
call "$(SolutionDir)\bin\PluginPostBuild.cmd" $(ProjectName) $(ConfigurationName) SharpMap.Extensions
call "$(SolutionDir)\bin\PluginPostBuild.cmd" $(ProjectName) $(ConfigurationName) NetTopologySuite
call "$(SolutionDir)\bin\PluginPostBuild.cmd" $(ProjectName) $(ConfigurationName) NetTopologySuite.Extensions

SharpMap.Extentions.Tests
--------------------------

call "$(SolutionDir)\bin\CopyNativeLibraries.cmd" $(ProjectName) $(ConfigurationName) SharpMap.Extensions

call "$(SolutionDir)\bin\CopyNativeLibraries.cmd" $(ProjectName) $(ConfigurationName) SharpMap.Extensions SharpMap
call "$(SolutionDir)\bin\CopyNativeLibraries.cmd" $(ProjectName) $(ConfigurationName) DelftShell.Plugins.FlowModel DelftShell.Plugins.FlowModel

• to loader: copy plugin + their native libs (deploy)
• to loader: copy unique dependent projects + their native libs of plugin (deploy)
• to test project: copy native libraries of dependent projects to test output directory

====================================================================

call "$(SolutionDir)\bin\PluginPostBuild.cmd" "$(SolutionDir)apps\DelftShell\modules\DelftShell.Loader\bin\plugins\$(ProjectName)\" "$(TargetDir)"

Plugin111/
modules/
Plugin111/
bin/
Debug/
Release/
lib/
tests/

How to work with development
------------------

• Build Loader to avoid build of test projects
• Configuration to build with/without? test project
• NEVER reference one Test project from another

Reduce dependencies
------------------

• DelftTools.Gui.SwfControls - move interfaces to DelftTools.Gui and use them in dependent projects
• introduce Windsor Castle (KEEP IT SIMPLE, NOT EVERYWHERE)

See part II of the document  (in the attachments) from Microsoft how they manage large solutions.

More notes from worklog:

Q: How to copy plugin library automatically to target dir (Loader/bin/plugins for now) together with their native libraries
A: Incliude the following in your project file:

<Import Project="..\..\..\..\build\DelftShell.targets" />

<PropertyGroup>
<IsPluginComponent>true</IsPluginComponent>
<PluginName>NetworkEditor</PluginName>
</PropertyGroup>

Note: it works also for a different projects of the plugin. Native libraries are copied automatically from:

<component>/
modules/
Project1/
Project2/
lib/
Project1/ ------------- if such a dir is found - content will be copied to the plugins/<PluginName>
Project2/

Q: How to enable PostSharp:

<PropertyGroup>
<UsePostSharp>true</UsePostSharp>
</PropertyGroup>

===== PostSharp projects:

DelftShell\modules\DelftShell.Gui\DelftShell.Gui.csproj

DelftTools\modules\DelftTools.Core\DelftTools.Core.csproj
DelftTools\modules\DelftTools.DataObjects\DelftTools.DataObjects.csproj
DelftTools\modules\DelftTools.DataObjects.Function\DelftTools.DataObjects.Functions.csproj
DelftTools\modules\DelftTools.Gui.Swf.Controls\DelftTools.Gui.Swf.Controls.csproj
DelftTools\tests\DelftTools.Tests\DelftTools.Tests.csproj
DelftTools\modules\DelftTools.Utils\DelftTools.Utils.csproj

DelftShellPlugins\DataAccess\modules\DelftShell.Plugins.Data.NHibernate\DelftShell.Plugins.Data.NHibernate.csproj
DelftShellPlugins\DelftModels\modules\DelftShell.Plugins.DelftModels.FlowModel\DelftShell.Plugins.DelftModels.FlowModel.csproj
DelftShellPlugins\Habitat\modules\DelftShell.Plugins.Habitat\DelftShell.Plugins.Habitat.csproj
DelftShellPlugins\Habitat\modules\DelftShell.Plugins.Importers.Habitat\DelftShell.Plugins.Importers.Habitat.csproj
DelftShellPlugins\MWell\modules\DelftShell.Plugins.MWell\DelftShell.Plugins.MWell.csproj
DelftShellPlugins\SharpMapGis\modules\DelftShell.Plugins.NetworkEditor\DelftShell.Plugins.NetworkEditor.csproj
DelftShellPlugins\OpenMI\modules\DelftShell.Plugins.OpenMI\DelftShell.Plugins.OpenMI.csproj
DelftShellPlugins\ProjectExplorer\modules\DelftShell.Plugins.ProjectExplorer\DelftShell.Plugins.ProjectExplorer.csproj
DelftShellPlugins\Series\modules\DelftShell.Plugins.Series\DelftShell.Plugins.Series.csproj
DelftShellPlugins\SharpMapGis\modules\DelftShell.Plugins.SharpMapGis\DelftShell.Plugins.SharpMapGis.csproj
DelftShellPlugins\Toolbox\modules\DelftShell.Plugins.Toolbox\DelftShell.Plugins.Toolbox.csproj
DelftShellPlugins\Verkenner\modules\DelftShell.Plugins.Verkenner\DelftShell.Plugins.Verkenner.csproj
DelftShellPlugins\Habitat\modules\Habitat\Habitat.csproj
DelftShellPlugins\SharpMapGis\modules\NetTopologySuite.Extensions\NetTopologySuite.Extensions.csproj
DelftShellPlugins\SharpMapGis\modules\SharpMap\SharpMap.csproj
DelftShellPlugins\SharpMapGis\modules\SharpMap.Extensions\SharpMap.Extensions.csproj
DelftShellPlugins\SharpMapGis\modules\SharpMap.UI\SharpMap.UI.csproj
DelftShellPlugins\SharpMapGis\tests\SharpMapTestUtils\SharpMapTestUtils.csproj
DelftShellPlugins\TestPlugin1\modules\TestPlugin1\TestPlugin1.csproj

Q: Reduce number of PostSharp assemblies, move entities to a separate projects? There are far to many
A: ????

Q: Are plugin folders removed correctly from the plugins/ folder if user selects Clean on plugin project
A: yes, they are, see DelftShell.targets, currently the whole plugin folder is removed from plugins/

Q: When I add a new plugin, how loader will know that it should be build when I press F5
A: make Loader depend on plugin (no references!)

================================================================

TODO:

disable output in DelftShell.targets (too many echos)
refactor cp.exe in all dependent test projects or reduce number of these projects (e.g. copy native libs only to tests/Project1.Tests/bin/Debug/)
draw dependencies and build times
move Xtra components to Swf.Controls? and make it plugin?
merge DelftTools.Tests.AOP into DelftTools.Utils.Tests
MapTestUtils are placed in a separate project so that we won't reference SharpMap everywhere, DelftTools doesn't know anything about SharpMap
comments:
just remove it: ==> //form.ShowDialog();
WindowsFormsTestHelper.ShowModal(form);

WindowsFormsTestHelper.ShowModal(form); => WindowsFormsTestHelper.Show(form);, It is modal locally and non-modal on a build server
ShowModel implementation is a bit strange - refactor it
remove references to NHibernate from third-party projects, use <ProjectName>.NHibernate.dll instead