Reflection is a great way of finding the calling method in another method. I found this post which provided a good template for what I was trying to do (build a logging class that would automatically log the method and object that created the log entry). My code ended up being:

StackTrace stackTrace = new StackTrace();
// Calling Method and Object are only one frame up.
StackFrame stackFrame = stackTrace.GetFrame(1);
MethodBase methodBase = stackFrame.GetMethod();
string method = methodBase.Name;
string obj = methodBase.DeclaringType.Name;

Neat! I the write obj and method into my log…

Installer projects in Visual Studio are for creating the Setup.exe and the MSI for installing the other projects in a solution. However, I discovered an oddity that caused havoc with our source control system. Continue reading “Visual Studio Installer Projects and SVN” →

I came across a pattern in .NET that I’d not thought of before. The scenario is, I’m reading from a file and deserializing it’s contents (a List of ‘Foo’ objects). Exceptions can be thrown at two points:

• When I’m reading the file
• When I’m deserialising the xml

Obviously, I want to make sure that the file handle is released if the deserialisation fails. However, I can’t deal with that in a single try block, as if the exception is in the file IO, then the file handle won’t exist to close in a finally block! Continue reading “Handling Errors when doing file IO” →

The .NET framework is a bit confusing until you get your head round the components of it, and the way that Microsoft name things.

.NET has a thing called the common language runtime (CLR). (This is the .NET equivalent of the Java Runtime). Different versions are essentially different VMs, and can coexist. The CLR runs code that is an Intermediate Language (IL) (aka the Common Intermediate Language (CIL)). Whatever code you write in C# or VB.NET actually only gets partially compiled into IL code. It’s a lot like Java Bytecode.

The Base Classes are the library of DLLs for the framework (and are sometimes incorrectly referred to as the framework). Think of it as Win32 for .NET. These constitute the .NET API – and have different versions too. A different version of the base classes, though, does not mean a different CLR – for example, frameworks version 2, 3 and 3.5 all use the same CLR, but present a different external API and have different language features. Indeed, the base classes of framework version 3.5 are a superset of version 3, which are a superset of 2. This means framework 2 code will run on machines with the 3.5 installed.

The languages have different versions too, and this is where things start to get confusing. The different language versions have different compilers, which emit backward compatible IL. This is to be expected since there is no new version of the CLR. In plain terms this means that all the new language features can be used with older projects. E.g. C# 3.0 code can run on the .NET 2 Framework, provided you haven’t used any of the libraries that are part of a later framework. The C# 3.0 code will be partially compiled into the same version of IL code as your C# 2.0 code, so the only problems come if you are using libraries that aren’t part of that .NET Framework.

(Note to self – must remember – C# version is independent of Framework version)

So why would you want to use C# 3.0 over C# 2.0? Well, the language adds a number of new features too – such as automatic properties, relaxed delegates, object initialisers, type inference, anonymous types, extension methods, lambdas and partial methods.

Hopefully this chart might explain things a bit. I’m pretty sure it’s right, although I’m recreating it from memory and can’t entirely remember…

	Framework Version 1.1	Framework Version 2.0	Framework Version 3	Framework Version 3.5
CLR	1.1	2.0	2.0	2.0
Library versions	1.1	2.0	3.0 (including 2.0 sp1)	3.5 (including 2.0 sp1 & 3.0 sp1)

Similar chart here:

http://www.leonmeijer.nl/archive/2007/06/11/50.aspx

…though the Microsoft guy who presented to me didn’t say anything about a CLR 3.0. I suppose there may be one which is backwardly compatibile?

More Windows forms stuff. I don’t like really complex Web forms controls ‘cos sometimes they seem a bit flakey – but I’m beginning to wonder if Windows Forms stuff is any better.

Two problems with the DateTimePicker. First, it can’t have a null value. What? You might not want to have a value in it? That’s craaazzzy! Inconceivable! What do you mean that your database tables allow null values in a DateTime column?

All you can do is set ShowCheckbox to ‘true’. This will give you a little checkbox, to turn on or off the editing of the value. You could then wrap the DateTimePicker, and return yourself null if the ‘Checked’ value is false.

Secondly, it has no BackColor property, so I couldn’t colour it pink when the field was invalid, meaning it had to have a value – therefore, the checkbox mentioned above has to be ‘Checked’. I managed to get around this by subclassing the DateTimePicker – but had some problems when you then focussed on it to try to edit it. My solution (below) was to turn off any background colour during editing…

Continue reading “DateTimePicker – no BackColor property, not nullable” →