Blog Image

Software Development

About the blog

The blog was created in an attempt to keep those valued points which are discovered in daily development and give something back to the community.

FileSystemWatcher

C# Posted on 2011-06-21 22:01

A FileSystemWatcher is very handy for
monitoring a file and e.g. reading it when it’s changed.

However, in some scenarios, more than
one Changed event with the same contents is raised for the same text
file. E.g. NotePad raises the event twice when saving a file, TextPad
3 times etc. etc.

This is annoying, because we don’t
really know how many times the event will be raised, and we can’t
safely react until the last time it’s raised – it may throw e.g. an
Access Denied because the editor isn’t done.

One solution is to use a timer which is
reset every time the event is raised for a specific file. When the
timer runs out, then the file can be accessed. For small files on a
fast machine or connection, it should be fairly safe to set the timer
to 1 sec, but it’ll depend on the size of the file, the load on the
machine, the bandwidth of the connection etc.

Small XML configuration files on a fast
machine with local harddrive storage could probably go as low as
100ms, but a 1 sec timer is safer and the rest of the application
won’t know when the file was available anyway. It just looks to the
app like the user pushed Save 1 sec later. (This could be a problem
when monitoring files in time-critical apps, but then this solution
really shouldn’t be used in such scenarios.)

The ”one timer per file” makes the
solution a lot less attractive the more files are monitored.



Readonly vs const

C# Posted on 2011-06-14 14:00

In short: const is set at compile time, readonly is set at runtime.

There’s a very important difference
between referencing consts and readonlys declared in a
different assembly: the const value is copied at compile time, while readonly is referenced at runtime.

Usually this difference won’t mean a
lot, but if you’re recompiling a referenced
assembly which has an updated const, then all referencing
assemblies will continue using ”the old const value” unless you
recompile them too. This could be the difference between being able
to drop-in a new assembly to fix a bug without re-deploying a full
system and not being able to …

A readonly will reference the value from the referenced assembly and therefore dropping-in only that assembly will be effective.

There are, however, drawbacks to using readonly, e.g. TestCase attributes (NUnit tests) can’t use them – only const is allowed. Attributes are set at compile time and not evaluated.



AssemblyCompany – default value

C# Posted on 2011-05-29 13:51

The default value for AssemblyCompany in AssemblyInfo.cs for a new project can be changed in the registry in the value “RegisteredOrganisation” in one of the following keys depending on OS:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion

HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion

The default value is “Microsoft” when the operating system is pre-installed.



Directory.Delete on Windows 7 is not blocking

C# Posted on 2011-05-28 19:10

Having recently upgraded/outdated a development laptop from old faithful Windows XP (32-bit) to Windows 7 (64-bit), we came across a problem which seemed odd at first.

Some unit-tests in a customer project failed intermittently at very unexpected points – it seemed like something went quite wrong with creating and deleting directories, but it wasn’t consistent or even predictable.

Additional symptoms were UnauthorizedAccessException and IOException – The directory is not empty. Both encountered when deleting a newly created empty directory (i.e. created by the same thread which was deleting it).

Digging deeper it looked like sometimes the System.IO.Directory.Delete actually failed silently and Directory.Create succedeed but the directory wasn’t there. It seemed unlikely for this to be caused by either .NET or even the OS acting up – it would seem much more likely that there would be some problem with the unit-tests which was hidden earlier either because the old laptop with XP was slower or the like.

However, after having debugged for a while, the problem could be reproduced quite consistently by running this simple snippet (from an NUnit test):

string dir = @”C:\PROJ\OBJECT.NET\UnitTest\Server\LOGS\Week21″;

for (int i = 0; i < 5000; i++)

{

Directory.CreateDirectory(dir);

Assert.IsTrue(Directory.Exists(dir));

Directory.Delete(dir, true);

Assert.IsFalse(Directory.Exists(dir));

}

[The snippet was run in DevStudio 2008 (9.0.21022.8 RTM), with NUnit (2.5.3.9345) and TestDriven.NET Professional (2.22.2468 / 3.0.2749) using .NET 3.5 SP1 and compile-target Any CPU on Windows 7 (x64)]

Directory.Delete(dir, true) will return before the directory is actually deleted 20-30 times out of 5000 – not a lot, but more than enough to annoy. The delay from the Delete returns and until the Directory actually disappears (Exists = false) can be up to 35-40ms – again, not a lot.

This could be a problem in a lot of both development and production scenarios – not just in a unit-testing environment, where a directory is created before and deleted again after each unit-test is run.

The actual behaviour may be related to Restore Points and versioning or something else, because if the drive in the snippet is changed to a different non-system drive (without Versioning and Restore Points ?) (like a D-drive), then it succeeds – every time.

The point here being that apparently it’s unsafe to assume that Directory.Delete is blocking when running under Windows 7.


The fix in many scenarios is to just hang around after Directory.Delete and wait for Directory.Exists to return false.

However, this isn’t quite enough if a directory tree more than 1 level deep is being deleted. More about this later.



Generic List – Stack Extension methods

C# Posted on 2010-06-03 12:32

Recently while developing a RecentFiles list for a customer application, it became apparent that neither generic List, Stack or Queue offered the desired functionality.

The desired functionality was a hybrid of List and Stack allowing Push onto the RecentFiles (latest at the top of the list) combined with the ability to remove entries anywhere in the RecentFiles (entries which already exist in the RecentFiles should be moved to the top).

Extension methods came up as a possible solution for adding the Stack method Push to List while keeping the List functionality.

The code:


internal static class StackList
{


public static void Push<T>(this List<T> list, T value)
{
list.Insert(0, value);
}

public static T Pop<T>(this List<T> list)
{
T result list[0];

list.RemoveAt(0);

return result;
}

public static T Top<T>(this List<T> list)
{
T result = list[0];

return result;
}

}

The code includes additional Pop and Top methods which seemed nice to have. As List<T> includes an integer indexer, Top isn’t really that necessary – and actually requires more text to use than it’s implementation list[0].

Unittesting the code is straight forward as the functionality is clearly defined. There are no functional dependencies, which would need to be decoupled and mocked etc.



Events and Anonymous Delegates

C# Posted on 2010-04-09 14:47

Some time ago I got started using anonymous delegates extensively for unittesting event-raising, but not tidying up after the subscription annoyed me.

If a class subscribes to an event on an object it’ll prevent the subscribee from being garbage collected. This is a particular problem with anonymous delegates, because normally you won’t think of removing the subscription, and how to do it may not initially seem obvious. However the subscription can be removed by specifically creating the instance of the subscriber delegate before the actual subscription and keeping it for the un-subscription:

var anonymousDelegate = new SomeDelegate(
delegate (…params…) { … implementation … }
);

SomeObject.SomeEvent += anonymousDelegate;
SomeObject.SomeMethodWhichRaisesSomeEvent();
SomeObject.SomeEvent -= anonymousDelegate;