Hi Nicko,
I have finished a port of log4net that does use the OpenNETCF library.
I have attached a description of what I have done, the files I edited
(and a bit about why). The library seems to work nicely in our
framework.
If this is of interest to the group, I'd be happy to submit the changes
for review and inclusion.
Please let me know the process for this.
Kevin
Kevin G O'Connor
Eleven Technology e: [EMAIL PROTECTED]
45 Dunster St p: 617.715.3031
Cambridge, MA 02138 m: 617.834.1291
http://www.11.com f: 810.963.2708
-----Original Message-----
From: Nicko Cadell [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 06, 2005 3:02 PM
To: Log4NET Dev
Subject: RE: Interest in OpenNETCF (1.4)
Hi Kevin,
OpenNETCF isn't something that I was aware of, thanks for your email
bringing it to our attention. It looks like the OpenNETCF library makes
up for many of the shortfalls of the base NETCF platform.
Many of the appenders in log4net which are not built for the NETCF
platform could be built using the OpenNETCF library. These can be built
into a separate assembly that links with the OpenNETCF library.
As far as I know there is none working on using the OpenNETCF library to
build log4net appenders.
Cheers,
Nicko
> -----Original Message-----
> From: Kevin O'Connor [mailto:[EMAIL PROTECTED]
> Sent: 01 November 2005 16:21
> To: [email protected]
> Cc: Shawn Becker; Sean Going
> Subject: Interest in OpenNETCF (1.4)
>
> Hello,
>
> I am currently working on a .NET compact framework system.
> We are making use of OpenNETCF Smart Device Framework (v 1.4). I was
> looking at the log4net project as a potential logging utility for this
> system. The OpenNETCF SDF provides support for several areas of the
> full .NET framework that are not part of the compact framework in the
> area of logging (the OpenNETCF.Diagnostics namespace).
>
> I did a quick search of the dev list archives and did not find a
> reference to OpenNETCF. I am curious if there is anyone working on an
> implementation of log4net using OpenNETCF SDF, and if not if there is
> any interest in having it done.
>
> Kevin
>
> Kevin G O'Connor
> Eleven Technology ?e: [EMAIL PROTECTED]
> 45 Dunster St *p: 617.715.3031
> Cambridge, MA 02138 (m: 617.834.1291
> http://www.11.com <http://www.11.com/> *f: 617.876.3704
>
>
>
>
>
log4net port to OpenNETCF Smart Device Framework 1.4
Following the pattern used for the compact framework: added 2 symbols used in
preprocessor directives, OpenNETCF and OpenNETCF_1_4. The latter is only used
in AssemblyInfo.cs for reporting the version of the OpenNETCF Smart Device
Framework in use. The former is used to conditionally compile in appropriate
code.
In general, the support added (back) to log4net is: EventLogAppender,
TraceAppender, support for the configuration facility using
OpenNETCF.Configuration, and a couple of minor things like the machine name
environment variable, Guid generation, and the use of
OpenNETCF.Diagnostics.Process.GetCurrentProcess().Id.
Files Updated
src/
AssemblyInfo.cs: reports the version of the log4net compilation in use and
blocks the [assembly: System.Security.AllowPartiallyTrustedCallers] attribute
decoration.
LogicalThreadContext.cs : same as .NETCF // .NET Compact Framework 1.0 has no
support for System.Runtime.Remoting.Messaging.CallContext
src/Appender
AnsiColorTerminalAppender.cs : same as NETCF, no error stream writing
AspNetTraceAppender.cs : same as NETCF, no ASP.NET support
ColoredConsoleAppender.cs : same as NETCF, no Win32 Console APIs
ConsoleAppender.cs : same as NETCF, no error stream writing
EventLogAppender.cs : OpenNETCF has OpenNETCF.Diagnostics.EventLO
Class is similar to the System.Diagnostics.EventLog in the full framework
with a few differences.
1. Since CE.Net and PPC have no event log we write the log to the
application root directory as an XML file
2. Every Application will have it's own log. There will not be one log
system/device wide
3. Attempted to keep as close as possible to the full framework class but
some things are missing
The implication for this class is that there is no support for event source
creation as each app logs to its own 'event log'.
The constructor of the EventLogAppender creates a new event log file.
ActivateOptions does appropriate management of any source changes. Append
writes to the event log file. Added an OnClose hander to catch the close
request on the appender. Added a protected virtual function that actually does
the close of the eventlog. TODO, perhaps add a mechanism to allow for clearing
of the event log?
LocalSyslogAppender.cs : Use the OpenNETCF.RuntimeInteropServices.MarshalEx
class to do the Identity to handle mapping.
NetSendAppender.cs : same as NETCF, no Win32 NetMessageBufferSend APIs
RemotingAppender.cs : same as NETCF, no System.Runtime.Remoting
SmtpAppender.cs : same as NETCF, no System.Web.Mail
TraceAppender.cs : use the OpenNETCF.Diagnostics.TraceEx class for the
System.Diagnostics.Trace class
src/Config
AliasDomainAttribute.cs : same as NETCF, no support for reading assembly
attributes
AliasRepositoryAttribute.cs : allow for the class to exist so the
OpenNETCF.Configuration facility may be used in the DefaultRepositorySelector,
but do not use the assembly attribute.
ConfiguratorAttribute.cs : allow for the class to exist so the
OpenNETCF.Configuration facility may be used, but do not use the assembly
attribute.
DomainAttribute.cs : same as NETCF, no support for reading assembly attributes
DOMConfiguratorAttribute.cs : same as NETCF, no support for reading assembly
attributes
Log4NetConfigurationSectionHandler.cs : use OpenNETCF.Configuration facility
PluginAttribute.cs : same as NETCF, no support for reading assembly attributes
RepositoryAttribute.cs : allow for the class to exist so the
OpenNETCF.Configuration facility may be used in the DefaultRepositorySelector,
but do not use the assembly attribute.
SecurityContextProviderAttribute.cs : same as NETCF, no support for reading
assembly attributes
XmlConfigurator.cs : Added "using System.Configuration;" and "using
OpenNETCF.Configuration;" directives, and modified some fully qualified object
references. Had to change use of ConfigurationException.BareMessage to
ConfigurationException.Message for OpenNETCF. Modified the opening of the
configuration file so the desired file access and sharing enums are used.
Ignored the credential cache as in NETCF. Used the XmlTextReader as in NETCF
as there is no XmlValidatingReader in OpenNETCF.
XmlConfiguratorAttribute.cs : No [Serializable] attribute in OpenNETCF, but we
do want the class. Added some support for the ConfigureFromUri without the
benefit of UriBuilder.
src/Core
DefaultRepositorySelector.cs : use OpenNETCF.Configuration facility. Change
call to get and initialize the RepositoryAttributes, AliasRepositoryAttributes,
ConfiguratorAttributes, and PluginAttributes so they will be initialized to
null.
Level.cs : No [Serializable] attribute in OpenNETCF as in NETCF
LocationInfo.cs : No [Serializable] attribute in OpenNETCF as in NETCF and no
stack trace info
LogException.cs : No [Serializable] attribute in OpenNETCF and no protected
constructor as in NETCF
LoggerManager.cs : use OpenNETCF.Configuration facility. No ProcessExit
handler as in NETCF.
LoggingEvents.cs : same as NETCF, no support for System.Security.Principal.
No [Serializable] attribute or ISerialization support. No thread name as in
NETCF. No current Windows user as in NETCF. No current thread principal as in
NETCF. No thread context properties as in NETCF.
src\Plugin
RemoteLoggingServerPlugin.cs : same as NETCF, no support for
System.Runtime.Remoting
src\Repository\Hierarchy
Logger.cs : Use AppDomain.CurrentDomain.FriendlyName and DynamicDirectory
rather than ApplicationBaseDirectory as in NETCF.
XmlHierarchyConfigurator.cs : Do not use CultureInfo.InvariantCulture and no
support for GetEnvironmentVariables as in NETCF
src\Util
EmptyCollection.cs : No [Serializable] attribute in OpenNETCF
EmptyDictionary.cs : No [Serializable] attribute in OpenNETCF
GlobalContextProperties.cs : No volatile keyword in OpenNETCF
LogicalThreadContextProperties.cs : same as NETCF no support for
System.Runtime.Remoting.Messaging.CallContext
LogLog.cs: Use OpenNETCF.Configuration and OpenNETCF.Diagnostics. No support
for Console.Out or Console.Error as in NETCF
OptionConverter.cs : Use OpenNETCF.EnumEx for enumeration parsing
PatternString.cs : same as NETCF, no support for general environment variables
PropertiesDictionary.cs : No [Serializable] attribute or SerializationInfo in
OpenNETCF
ReaderWriterLock.cs : same as NETCF, no support for ReaderWriterLock
ReadOnlyPropertiesDictionary.cs : No [Serializable] attribute or
SerializationInfo in OpenNETCF
SystemInfo.cs : generally same as NETCF. Added
OpenNETCF.EnvironmentEx.MachineName and OpenNETCF.GuidEx
ThreadContextStack.cs : no Stack.Clear, so we pop until empty.
WindowsSecurityContext.cs : same as NETCF, no support for WindowsIdentity
src\Util\PatternStringConverters
EnvironmentPatternConverter.cs : same as NETCF, no support for
GetEnvironmentVariables as in NETCF
IdentityPatternConverter.cs : No current thread principal as in NETCF.
ProcessIdPatternConverter.cs : use
OpenNETCF.Diagnostics.Process.GetCurrentProcess().Id
ProptertyPatternConverter.cs : No thread context properties as in NETCF.
UserNamePatternConverter.cs : No current Windows user as in NETCF
src\Util\TypeConverters
ConversionNotSupportedException.cs : No [Serializable] attribute or
SerializationInfo in OpenNETCF
