Also, the Cabinet office guidelines.

Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments)

Doesn’t have a trailing slash.

Well it ain’t easy. They’re not an enumeration, so you can’t iterate over them. Instead, to get a list of the colours, you’ve got to do something like:

List<Color> colorList = new List<Color>();

Array colorsArray = Enum.GetValues(typeof(KnownColor));
KnownColor[] allKnownColors = new KnownColor[colorsArray.Length];
Array.Copy(colorsArray, allKnownColors, colorsArray.Length);

foreach (KnownColor c in allKnownColors) {
Color col = Color.FromKnownColor(c);
if(( col.IsSystemColor == false) && (col.A > 0)) {
colorList.Add(col);
}
}
That’s a lot of work for something obvious like iterating over colours!

Those boys at NASA clearly understand software testing. After all, it ain’t rocket science.

You have some input, something happens, you look at the output and adjust your input again. This is implicit in quality procedures everywhere. This is what testing is.

Over the last few days I’ve been asked to estimate how long various bits of work for a potential customer will take. I’ve tried to make good estimates, but the truth is that I have never seen a comparison of how long was estimated at the beginning of a project, and how long was actually taken.

In other words, I still only have my gut feeling, my perceptions, to guide me as to how accurate I think my estimates are, despite the fact that this is a clearly measurable metric. The control loop is still open.

At the moment I provide estimates like “I think it’ll take about 10 days, but I’m not really very sure”. Wouldn’t it be better to know “Andy normally under estimates by and average of 10%, with a standard deviation of 10%”. Then if, for example, I estimated 10 days, we’d know that it’d actually 10-12 days, but only 68% of the time, or 9-13 days 96% of the time.

Perhaps this exercise is performed at a management level already - but as the developers are being the ones asked to estimate for technical details, it’s us that need our accuracy fed back for those aspects.

Now, I realise that there’s always going to be a human aspect to providing an estimate, that projects often aren’t that clear and easy to cut up, and that often we’re working with new things that we simply aren’t sure about. There’s also a cost-benefit question as to the effort in feeding back accuracy data. But I think that there are broad trends we should be able pull out.

I guess what I’m thinking is that we should have a process for optimising our estimates. I guess that this would involve examining statistical methodology. The best we’ve got at the moment is an informal “well that look longer/less time than I thought” after we’ve completed some work - and over projects that can span years, you just lose track.

It does strike me that it should be straight-forward to collate this data, and then feed it back at the end of the project. Close the loop. Regain some control.

Long story short, .NET’s built in logging wasn’t bad, but the Log4NET project proved a lot better.

Within the .NET Framework

.NET has some classes for doing this - Debug and Trace. They work, and you can configure trace listeners and such. However, writing code to send a debug message only if the logging level is detailed enough is, well, clumsy.

Debug and Trace are pretty much equivalent, except that Debug is not compiled into ‘Release’ builds. They have methods like the following:

Debug.WriteLine ( string )
Debug.WriteLineIf ( bool condition, string )
Debug.Assert ( bool condition, string message)

In addition, Trace has things like:

Trace.TraceInformation ( string )
Trace.TraceWarning ( string )
Trace.TraceError ( string )

It’s worth noting that none of these Trace methods have an ‘if’ equivalent to ‘WriteLineIf’, and that the Debug class can’t output different ‘levels’ of debug message.

Trace also works with a TraceSwitch class. This allows you to switch levels of logging used, and can be configured through the application config. E.g., this adds a listener to output to the Console:

<configuration>
<system.diagnostics>
<trace autoflush="false" indentsize="4">
<listeners>
<add name="configConsoleListener" type="System.Diagnostics.ConsoleTraceListener" />
</listeners>
</trace>
</system.diagnostics>
</configuration>

Similarly, TraceSwitches logging levels can be set in this file. The problem with them is, though, that you have to make sure you test the logging level before you call the Trace.TraceInformation style methods. For example:

TraceSwitch sw = new TraceSwitch("General", "Whole App");
sw.Level = TraceLevel.Error;
if (sw.TraceError )
Trace.WriteLine("Error1");

Trace.TraceError("Error2");
Trace.TraceWarning("Warning2");
Trace.TraceInformation("Info2");

Produces:

Error1
TraceTest.vshost.exe Error: 0 : Error2
TraceTest.vshost.exe Warning: 0 : Warning2
TraceTest.vshost.exe Information: 0 : Info2

In other words, Trace.TraceXXX methods don’t obey a global logging level.

The final component in the .NET logging are TraceListeners. These listen to Trace or Debug messages, and log them somewhere. Examples that are built in include the Console, a text file, an XML file, and the Windows Event Log. You can have many TraceListeners, but I didn’t see a way of having different listeners recording different levels of information (e.g. Errors to the event log, but all messages to an XML file).

I wanted to log to the Windows Event Log. Specifically, I wanted to create Warning and Error messages in the event log, but it turns out that the .NET EventLogTraceListener only ever creates items as ‘Information’ messages (i.e. messages with the wrong icon). That kind of sucked.

Log4NET Logging Framework

So I looked at Log4NET. This is an Apache project, which was originally to build a Java Logging API. Java now has a Logging API, which works in a suspiciously similar way. Anyway, .NET also lacked good logging, so they ported the project to .NET.

Log4NET still has a number of nice features - it’s much more configurable, supports having different levels of logging, and has more ways of outputting your logged messages (including the RollingFileAppender, which is a nice touch). To use it isn’t very hard, although the documentation doesn’t make this terribly clear.

In Log4Net you can define many loggers. These loggers are named, usually the fully specified name of the class that they apply to (e.g. Ford.Vehicles.Cars.FocusSport), though that is not necessarily the case.

They exist in a kind of hierarchy. There is a Root logger, which applies to the whole application, and then loggers inherit from their ‘parent’. For instance, if a log was specified for “Ford.Vehicles”, then “Ford.Vehicles.Cars” would inherit it’s logging settings - although it could override them. This is why the fully specified class name is normally used - conveniently, it forms this hierarchy.

Anyway, in your application you create a logger. When you use this to log messages, the logger passes the message to any appenders attached to it. They control recording the message to whatever output they were designed for. Sometimes you may have formatters to control what the output looks like.

Enough of that, how does this work?

Okay, the quickstart.

1) Add the Log4NET.dll into your project as a reference. (You’ll have to deploy this DLL when you install your final application).

2) In your ‘main’ class, add the following tag just above the namespace:

[assembly: log4net.Config.XmlConfigurator(Watch = true)]

This tells the logging framework to ‘watch’ the config file. It will then pick up any changes to logging levels, etc., as they happen (rather than having to restart).

3) In the class you want to put logging in, create a logger object:

log4net.ILog log = log4net.LogManager.GetLogger(
System.Reflection.MethodBase.GetCurrentMethod().DeclaringType );

This line uses reflection to get the full class name of the class it is in automatically, which is nice - it makes it a cut and paste operation.

4) Make your logging calls in your code:

log.Fatal("There has been an exception");

5) In your App.config files add a new Configuration Section:

<configSections >
<section name="log4net" type="System.Configuration.IgnoreSectionHandler" />
</configSections>

6) Finally, configure your appenders, loggers, etc.. See http://logging.apache.org/log4net/ for more details, but my example is:

<log4net>
<!-- Define some output appenders -->
<appender name="EventLogAppender" type="log4net.Appender.EventLogAppender">
<threshold value="Warn" />
<ApplicationName value="Invoice Email Notifier" />
<LogName value="Deltascheme Notification Mailer Service" />
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%date [%thread] %-5level %logger - %message%newline” />
</layout>
</appender>

</log4net>

This defines a Root logger (which logs everything), and adds two appenders to it. One appender only records Warning, Error or Fatal messages, which it puts into the Windows Event Log. The other appender writes to a log file called ‘debug.txt’. This log file is limited to 1Mb in size, after which old records are pushed off the end of the file (which is a nice feature). It also has a filter, and will only record messages that are Information or Warning messages.

My service connects to a SharePoint 2007 service every so often, queries a List, sends a few emails, and logs some information. The main additional assemblies it uses are Microsoft.SharePoint and Log4NET for the SharePoint and Logging parts respectively.

I tried adding CAS like so:

[assembly: FileIOPermission(SecurityAction.RequestOptional,Unrestricted=true)]

I knew I’d need other permissions, and that I definitely wanted this one; my plan was that as RequestOptional would cause all other permissions not requested by RequestOptional or RequestMinimum to be denied, I would get permissions errors. I’d then work my way through my code, adding the minimum set of permissions I required.

What I got was the security exception “That assembly does not allow partially trusted callers”. This wasn’t the failed permission that I’d expected, but that one of the assemblies couldn’t be called as from a partially trusted assembly (which my assembly was, as soon as I started added CAS).

I was surprised. I didn’t think that the SharePoint or Log4NET dlls would complain about being called from a partially trusted context. At the suggestion of Dominick Baier on Google groups, I used the Lutz Reflector to look inside the assemblies, and checked for the [AllowPartiallyTrustedCallers] attribute.

Both the Log4NET and SharePoint DLLs had this attribute. So they weren’t causing the exception. Then I tried the System.ServiceProcess dll, which contains the ServiceBase class I was subclassing. Tada! It didn’t allow partially trusted callers. Thus, when my code was run, naturally, it made calls of it’s parent class. That parent class existed in an assembly that I couldn’t access from a partially trusted context.

I guess that makes sense - I mean, quite when would you want something to interact with your services from a partially trusted position? They’re a bit, well, important for that.

Guess I won’t be applying CAS that way. Probably don’t have to, then. If my code can only be called from a Full Trust context, why would an attacker have to abuse my code? Their app would be fully trusted too - it could abuse the machine directly.

mainMem.useNamedFile = "FALSE"

I make no claims about it’s safety - but it did seem to stop the disk thrashing. That normally happened a bit - even when I had plenty of memory free.

C:\sc config beep start= disabled

Be sure to leave a space between the equals (=) sign and the word

Unicode defines a ‘code page’. I think of this as a ‘character space’, although this isn’t quite right. Anyway, the point is, Unicode is the set of things which, ultimately, will be displayed.

The encodings are ways of having a bunch of bytes reference one of the points in the code page. They do have different properties. UTF-16 and UTF-8 are the most widely used, and I’d suggest always using UTF-8 unless you’ve got a reason to do otherwise.

UTF-16

This encoding uses 16 bits per character for characters within the Basic Multilingual Plane(BMP). For characters in other planes, it uses a second 16 bit word (called a surrogate pair), but as we don’t use characters outside the BMP (it’s rare we go outside basic Latin) we don’t normally see this. Incidentally, it’s this encoding that makes developers often think that Unicode means 2 bytes per character; that’s not necessarily the case.

UTF-16 Big Endian, Little Endian

Big Endian and Little Endian define the bit order of these 2 words in the encoding. Apparently, this is for performance reasons on different processors.

“Is UTF-16 Big or Little Endian if you don’t specify it?”

Both. The UTF-16 (and UCS-2) encoding scheme allows either endian representation to be used, but mandates that the byte order should be explicitly indicated by prepending a Byte Order Mark before the first serialized character. This BOM is the encoded version of the Zero-Width No-Break Space (ZWNBSP) character, codepoint U+FEFF, chosen because it should never legitimately appear at the beginning of any character data. This results in the byte sequence FE FF (in hexadecimal) for big-endian architectures, or FF FE for little-endian. The BOM at the beginning of a UTF-16 or UCS-2 encoded data is considered to be a signature separate from the text itself; it is for the benefit of the decoder. Technically, with the UTF-16 scheme the BOM prefix is optional, but omitting it is not recommended as UTF-16LE or UTF-16BE should be used instead. If the BOM is missing, baring any indication of byte order from higher-level protocols, big endian is to be used or assumed. The BOM is not optional in the UCS-2 scheme.

The UTF-16BE and UTF-16LE encoding schemes (and correspondingly UCS-2BE and UCS-2LE) are similar to the UTF-16 (or UCS-2) encoding scheme. However rather than using a BOM prepended to the data, the byte order used is implicit in the name of the encoding scheme (LE for little-endian, BE for big-endian). Since a BOM is specifically not to be prepended in these schemes, if an encoded ZWNBSP character is found at the beginning of any data encoded by these schemes is not to be considered to be a BOM, but instead is considered part of the text itself. In practice most software will ignore these “accidental” BOMs.

UCS-2

Predecessor to UTF-16, it is identical except that it doesn’t have surrogate pairs. Therefore, it can only encode characters in the BMP.

UTF-8

A variable-length character encoding for Unicode. While it can represent any Unicode character, the main benefit is that the binary codes for UTF-8 and ASCII are the same (requiring little or no change for software that handles ASCII but preserves other values). For these reasons, it is steadily becoming the preferred encoding for email, web pages, and other places where characters are stored or streamed. It uses 1 to 4 bytes per character.

UTF-32 or UCS-4

A full 4-byte encoding for Unicode. It has the advantage that it is simple, as it isn’t variable length per character. However, it is very inefficient, as characters outside the BMP are rarely used. For us, what with all the Latin characters that we use, it would add 3 unnecessary bytes per character. UCS-4 is a similar encoding with a slightly larger code page - but the extra space is reserved. Therefore, we can assume that UCS-4 and UTF-32 are the same.

UTF-7

UTF-7 (7-bit Unicode Transformation Format) is a variable-length character encoding that was proposed for representing Unicode-encoded text using a stream of ASCII characters, for example for use in Internet e-mail messages.

The basic Internet e-mail standard SMTP specifies that the transmission format is US-ASCII and does not allow byte values above the ASCII range. MIME provides a way to specify the character set allowing for use of other character sets including UTF-8 and UTF-16. However the underlying transmission infrastructure is still not guaranteed to be 8-bit clean and therefore content transfer encodings (e.g. base64) have to be used with them.

CESU-8

CESU-8 is a variant of UTF-8.It is similar to Java’s Modified UTF-8 but does not have the special encoding of the NUL character (U+0000). Like Modified UTF-8, it can be decoded into one UTF-16 word at a time. Because it doesn’t have special treatment of NUL, the resulting string will not be safe for NUL-terminated string handling if the original string contained NUL characters.

In practice, CESU-8 is often used to communicate with the Oracle database software, which in modern configurations apparently uses UTF-16 as an internal character representation. Oracle’s “UTF-8″ (actually CESU-8) codec rejects proper UTF-8 sequences for characters from outside the Basic Multilingual Plane, but happily accepts and generates technically invalid UTF-8 sequences for code points in the surrogate range (U+D800 .. U+DFFF), as specified in CESU-8.

Other Definitions:

BOM - Byte Order Mark

The character at code point U+FEFF (”zero-width no-break space”), when that character is used to denote the endianness of a string of UCS/Unicode characters encoded in UTF-16 or UTF-32 and/or as a marker to indicate that text is encoded in UTF-8, UTF-16 or UTF-32.

In most encodings the BOM is a sequence which is unlikely to be seen in more conventional encodings or other Unicode encodings (usually looking like a sequence of obscure control codes). If a BOM is misinterpreted as an actual character within the text then it will generally be invisible due to the fact it is a zero-width no-break space. The “zero-width no-break space” semantics of the U+FEFF character has been deprecated in Unicode 3.2, allowing it to be used solely with the semantic of BOM.

BMP - Basic Multilingual Plane

The Unicode code space for characters is divided into 17 planes, each with 65,536 code points, although currently only a few planes are used:

• Plane 0 (0000