Hi,
Apparently it's currently not necessary to build separate assemblies for
the Windows CE and PocketPC .NET Compact Framework platforms, but I still
think that we should provide different assemblies (or take into account
that this is necessary in the near future) for both platforms, even if they
are actually the same at this time.
I think we should start by dividing up the example and build directories,
and actually split the build directory in a build and bin directory. The
build directory would be used for storing the assemblies that are compiled
using VS.NET or the C# compiler, and the bin directory would contain the
actual distribution version (the buid directory would not have to be
included in the official distribution as it will be create automatically by
VS.NET).
So in the near future we're looking at support the following .NET Framework
versions :
- .NET Framework 1.0
- .NET Framework 1.1 (will probably be released at the end of this month,
together with the RTM of VS.NET 2003 and Windows 2003)
- .NET Compact Framework 1.0 (the runtime version is already gone RTM, only
the development environment, VS.NET 2003, isn't yet publicly available)
When we look further aheadn support for Mono will definitely become an
option.
I would suggest the following directory structure :
bin\
Net\
1.0\
1.1\
NetCf\
1.0\
WinCE\
PPC\
Mono\ (in the future)
Rotor\ (in the future)
build\
Net\
1.0\
1.1\
NetCf\
1.0\
WinCE\
PPC\
Mono\ (in the future)
Rotor\ (in the future)
docs\
Net\
1.0\
1.1\
NetCf\
1.0\
WinCE\
PPC\
Mono\ (in the future)
Rotor\ (in the future)
examples\
Net\
1.0\
1.1\
NetCf\
1.0\
WinCE\
PPC\
Mono\ (in the future)
Rotor\ (in the future)
src\
I think it's best to separate the build directory for development purposes
(the build dirctory) and the build directory for building releases of
log4net (the bin directory).
Looks a bit complex, but it provides flexibility. By looking at the
dirctory structure and the list of current and future support Framework
versions/runtimes, you'll immediately understand the necessity for an
automated build procedure. We're currently looking at using nant
(http://nant.sourceforge.net) for this purpose, but at this time it does
not provide all functionality that we need (eg. it doesn't support building
assemblies for all the runtimes we'll need to support).
In the future, we should actually try to move platform (and version)
dependent classes to separate namespaces (and directories). That would
make sure it's easier to maintain the build procedure and it would makes
things clearer for developers too. Classes that can be compiled to all
framework versions and platforms using conditional compilation directives
can remain in the core namespace of course.
We could hide the complexity of the directory structure from users by
providing a separate distribution for every runtime version we're
supporting. That would allow us to flatten the directory structure.
Please don't hestitate to provide feedback, this is all open for discussion
!!!
If there any nant developer watching this list, please don't hesitate to
correct me if I'm wrong about the level of support you're currently
providing.
Thanks,
Gert
The Information contained in this message is intended for the addressee
only and may contain confidential information. Any views or opinions
presented are solely those of the author and do not necessarily represent
those of Ardatis. Ardatis reserves the right to monitor the content of all
e-mail messages it receives.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
