Watching files for changes

The moral of the story is, if you want to watch a file for changes, don't just listen to the Changed event on a FileSystemWatcher.

Different applications save files in different ways. Some just overwrite the original file, in which case Changed fires. Others attempt to create a two-phase commit transaction, so either the changes get saved or your original file is preserved (in case of a power outage). However depending on how they do this, they might never raise a Changed event against the file you're looking for - they might (for example) do all the changes to a temp file, then rename it.

Watching C:\*.* with a FileWatcherTestUI.NonBufferedFileSystemWatcher and updating a file 'UpdateSql.txt':

Notepad
[2006-07-10T10:45:27.1245966+08:00] Changed: C:\UpdateSQL.txt
[2006-07-10T10:45:27.1402217+08:00] Changed: C:\UpdateSQL.txt
[2006-07-10T10:45:27.2183472+08:00] Changed: C:\UpdateSQL.txt
 
VS 2003
[2006-07-10T10:45:17.3432840+08:00] Created: C:\ve-329.tmp
[2006-07-10T10:45:17.3589091+08:00] Changed: C:\ve-329.tmp
[2006-07-10T10:45:17.3589091+08:00] Changed: C:\ve-329.tmp
[2006-07-10T10:45:17.3589091+08:00] Changed: C:\ve-329.tmp
[2006-07-10T10:45:17.3745342+08:00] Changed: C:\UpdateSQL.txt
[2006-07-10T10:45:17.4214095+08:00] Changed: C:\UpdateSQL.txt
[2006-07-10T10:45:17.4526597+08:00] Changed: C:\UpdateSQL.txt
[2006-07-10T10:45:17.4682848+08:00] Deleted: C:\ve-329.tmp
 
VS 2005
[2006-07-10T10:45:37.3277869+08:00] Created: C:\ve-32B.tmp
[2006-07-10T10:45:37.3277869+08:00] Changed: C:\ve-32B.tmp
[2006-07-10T10:45:37.3434120+08:00] Changed: C:\ve-32B.tmp
[2006-07-10T10:45:37.3902873+08:00] Changed: C:\ve-32B.tmp
[2006-07-10T10:45:37.4371626+08:00] Changed: C:\ve-32B.tmp
[2006-07-10T10:45:37.4527877+08:00] Created: C:\UpdateSQL.txt~RFf7eb451.TMP
[2006-07-10T10:45:37.4684128+08:00] Deleted: C:\UpdateSQL.txt
[2006-07-10T10:45:37.4684128+08:00] Changed: C:\UpdateSQL.txt~RFf7eb451.TMP
[2006-07-10T10:45:37.4840379+08:00] Renamed: C:\UpdateSQL.txt (from ve-32B.tmp)
[2006-07-10T10:45:37.4996630+08:00] Deleted: C:\UpdateSQL.txt~RFf7eb451.TMP

Prefer Singletons to Static classes

It's a common scenario: you have some core facade class with a load of stateless methods on it that delegate activity down to other layers. There didn't seem much point in having the overhead of instantiating the class to use the methods, so you made all the methods static. You've made a static class.

Trouble is, static classes just aren't as flexible as the alternative: a singleton. For example:

* Static classes can't implement interface contracts
* Static classes can't be passed around or used polymorphically
* Inheritance of static classes is a minefield
* You can't make static members virtual or abstract.

This might not be an issue straight up - in many cases it may never be an issue at all - but when it does you'll be kicking yourself.

Take the scenario where you decide somewhere along the line that your facade isn't the be-all-and-end-all, and that you want to swap implementations in different circumstances. You don't want your objects to know about it, so you refactor the facade into some kind of proxy-by-composition. Still you're tied to having only one implementation active at any one time.

By contrast if you'd started as a singleton, it's pretty easy to change which subclass gets setup on the singleton. Its also far easier to migrate to a dependency-injection type architecture later down the line to support multiple implementations being used in parallel (this also then decouples the objects from the facade/singleton, which is a benefit in plugin-style architectures). And it's far easier to refactor some of the functionality out of the class into a base class, and start replicating your facade functionality in other scenarios.

On a more mundane point, when setting up a static facade you're doing work in the static class constructor. When this throws, it throws TypeInitializationException. With a singleton you get the choice - lazy init via static field init (still throws TypeInitializationException), or via first-property access, which will throw an exception you'll have a chance of debugging.

Go the singleton straight off (a rule I've once again re-learnt the hard way).

VB.Net finally bug (.net 1.1)

Forgot to post this a while back, but a collegue (Matt) showed me this line that I wrote:

        Finally
            If Not cursorScope Is Nothing Then cursorScope.Revert()
        End Try

He was debugging the null reference exception that was thrown when cursorScope.Revert() was called when cursorScope was Nothing.

Yes, that's right, the IF condition was being blatantly ignored, and yes, this did seem to be related to being in the finally clause.

He broke it into a multi-line If / End If to made it all work. Go figure.

Using Generics to improve code readability

Obviously Generics in .Net 2 provides the ability to write type-parameterised code, which is great for collections and the like. But it was only when I started using it a bit I realised the potential for much wider cast-elimination.

Take for example some kind of factory method (or any method that has a type as a parameter, and returns an instance of that type):

SomeType instance = (SomeType)Factory.CreateInstance(typeof(SomeType));

Using generics can cut right through:

SomeType instance = Factory.CreateInstance<SomeType>();

It's particularly noticable in VB.Net (because it has such munted cast syntax in the first place), but the result is normally a lot more legible. Unfortunately the framework is full of missed opportunities to clean up:

thing = DirectCast(Enum.Parse(GetType(SomeType), someValue), SomeType)

could become

thing = Enum.Parse(Of SomeType)(SomeValue)

That's got to be better, right?

WorkflowRuntime.Dispose() doesn't clean up properly

Unfortunately, in the current RC5 build of Windows Workflow (the one that comes with .Net 3 RC1), calling Dispose() on the WorkflowRuntime does not clean up after itself properly. Specifically:

• it doesn't unload workflows in memory
• it doesn't reset the workflow performance counters

To do all that you have to call StopRuntime() first.

Try it for yourself:

          using(WorkflowRuntime workflowRuntime = new WorkflowRuntime())
          {
              workflowRuntime.AddService(new SqlWorkflowPersistenceService(Properties.Settings.Default.WorkflowPersistenceConnectionString));

              WorkflowInstance instance = workflowRuntime.CreateWorkflow(typeof(WorkflowConsoleApplication1.Workflow1));
              instance.Start();

              //workflowRuntime.StopRuntime(); // uncomment me to get the instance to be persisted
          }

This is particularly unfortunate given all of the samples for WF (and the boilerplate code that gets created in new WF projects) just allow the runtime to be disposed when it drops out of scope. And needless to say it goes against the grain of how Dispose() works in practice: as a 'clean up gracefully' rather than just a 'free unmanaged resources' (think SqlConnections getting closed, Transactions being rolled back etc...)

https://connect.microsoft.com/wf/feedback/ViewFeedback.aspx?FeedbackID=224627

Starting Over

A project manager I used to work with had a favorite phrase he liked to bandy around:

"You can't polish a turd"

There's always a point beyond which a particular class or module should just be tossed out and re-written, rather than fixed. A point where something's gone so badly in the wrong direction that it needs to be humanely put down so we can get on with the rest of our lives. But when to start over?

Only the developers who've worked in a given area know really how horrible it is, but even then it's hard to get an objective opinion. Many developers are over-precious, defensive of their own code, and unduly negative of the work of others [1]. Then again, other developers 'at the coal face' can be blind to how screwed something is, happily chiselling away when it's time to grab the dynamite. Even the system's architects can fail to grasp just how unworkable it is from a grunt's perspective. Management just can't win.

Here's some pointers to identify 'start over' candidates:

• It's going to cost more to fix than to build from scratch
• It's going to be quicker to fix than to build from scratch
  
• There's a high defect rate in that area
• There's no test coverage in that area, so any fixes walk a regression minefield
• Even when fixed, it'll be sub-optimal compared to building from scratch
• Even when fixed, it doesn't really do what you need it to
  
• Even when fixed, it imposes significant architectural constraints on the rest of the system (eg perpetuates a coupling you're trying to get rid of, or continues with a depricated metaphor)
• Even when fixed, there's a significant maintanance cost
  
• There's no-one left on the project who understands how it works, yet it's not stable enough to just leave alone, or was left half-done
• There's no documentation
  

Any of these are warning lights, but more than a couple should warrant a long hard look.

For the sake of completeness, all of these can be applied at the project level too. This is a really tough call, but sometimes a clean break is for the best. Salvage what you can and move on. The most reusable part of a project is always the IP anyway, not the implementation. Even if you don't reuse one line of code, you'll still have learnt something.


[1] It happens to us all. Every so often I find myself panning code I wrote myself (and subsequently forgot about)

Why ReSharper is (still) the dog's bollocks

Here's a pretty good post describing why ReSharper is still the dog's bollocks.

I think ReSharper is so utterly brilliant that I'd be deeply suspicious of any C# team that wasn't using it. It's not without it's faults I'll give you, but even then it's a joy to use, and dumps all over the built-in refactoring support in VS2005-C#.

Microsoft and CodeRush just don't get refactoring. They seem to think it's some kind of point-and-click design activity, all green bendy arrows or fiddly tool tips ('making a video game out of your code'). What they don't seem to understand is that I'm typing. If I want to go all clicky-clicky I'll go back to the design pane thanks, or the Class Designer.

ReSharper is zero friction. It's the TestDriven.Net of refactoring tools. Extract Local Variable: Ctrl-Alt-V done. Override method: Alt-Insert, select, done. That thing you were about to type: Ctrl-Shift-Space (pretty much). It's so quick and easy it's not funny. People looking over your shoulder will have difficulty keeping up.

Like many XP techniques, refactoring is one that suddenly makes a lot more sense with the right tool. Using ReSharper has totally changed the way I think about my code.

Dealing with TechnicalDebt

I kind of copped out in a previous post by saying I didn't have any way of dealing with technical debt short of avoiding it in the first place. That was just plain lazy of me.

Dealing with Technical Debt cuts to the heart of the 'debt' metaphor's limitations. Debt implies regular interest payments, but that's not necessarily the case with technical debt. There's quite a continuum, from your 'high street bank' style debt: obvious, regular 'payments' impeding forward momentum; to your loan-shark style debt: maybe you'll get away without paying anything for a long time, but one night in a dark alley he'll want your kneecaps. This latter, unpredictable impact, is the more common scenario.

This then clarifies our approach towards technical debt: treat it as a risk. So, like all risks, you can:

• Mitigate - Have a fall-back position if the debt becomes an issue
• Accept - Assess that the risk is lower than the cost of fixing. You might get lucky
• Reduce - Either deal with the debt, or avoid building new functionality on debt-ridden areas
• Transfer - Make it SomeoneElsesProblem. Tricky.

Handwringing or winging about violating encapsulation doesn't tend to cut the mustard with project managers (and rightly so). Attempting to quantify implementation shortcomings in terms of project risk is far more likely to give the problem the attention it deserves.

Error Reporting - To send or not to send?

Don't think of it as 'can I be bothered to help Microsoft find their bugs' button. Think of it as a 'vote for this f#$%ing issue to be fixed' button. I find that clarifies the decision somewhat...

Broken URLs

Whyohwhyohwhy can't browsers deal with urls with line breaks being pasted into the address bar? All but the shortest urls get broken in emails, and yet the blindingly obvious solution (no it's not Shrinkster) still evades us.

Even a menu option ('Navigate to mangled url in clipboard') would do.

Avoid solution folders in VS2005 for your UserControl projects

In VS2003, whenever you had a form open in the designer, any user controls in your project[*] appeared in a 'My User Controls' tab on the toolbox.

This was essential because (for some reason unbeknownst to man) you can't drag a WinForms user control from the Solution Explorer onto a form, you have to do it from the toolbox (which sucks: the ASP.Net team managed it just fine, so what's the issue?).

In VS2005 the same functionality exists (with the additional feature that it can be disabled for performance reasons with the AutoToolboxPopulate option). But it doesn't work - or not for us at any rate.

Eventually it turns out (thanks Cam) that it doesn't work for projects within solution folders. How crazy is that?

"The fix probably won't make it into Service Pack 1, but I will forward your feedback to the appropriate team for consideration."
[Ben Bradley, MSFT, link above]

However the bug reports says it's fixed already:

http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=114542

...so I'm crossing fingers for SP1 (whenever that comes out).

[Update: Didn't publish this for ages, but no, SP1 doesn't fix it. Poo]

TechnicalDebt

TechnicalDebt is a term used for all the hacks (in the pejorative sense) in the codebase. It's the shortcuts, the quick-and-dirties that come back to haunt you, the cruft.

The term was coined by Ward Cunningham, and is used in agile circles, though it is essentially at odds to YAGNI. Martin Fowler explains it well.

As I see it, there are two major problems in dealing with Technical Debt:

• Inflexible project schedule. Unless you've got flexibility in your project planning (built in slack, or agile schedule) you've got no time to fix it. It is, after all, work you didn't plan for.
• Inability to articulate benefits. Sure, maybe we shouldn't have done it this way, but we have, so why change it if it means yet more time spent.

This last is particularly pernicious. It's nigh-on impossible to estimate the eventual cost at the time the debt is 'incurred', and in many cases pretty darn hard to measure the cost of the debt whilst you're paying it. Without the data, how can you possibly justify the cost of rework?

So why can't we measure the cost? Well if it's a simple quick-and-dirty that must be fixed for further progress to be made, then it's just the cost of the rework - the debt is repaid. But it's never that clean cut: the decision can have almost subliminal rippling effects on all the code that touches it, and the developers who have to deal with the compromised areas may not be aware that there was a better way available originally. So the debt possibly doesn't ever get 'repaid' as such, and the 'interest payments' such as they are are hidden within the cost of other work.

[Random link that illustrates the costs of unpaid debt]

Plus of course even if you're aware of the hit, unless you do the same activity twice - once paying the tax and once without - it's impossible to measure the true cost. If you are directly aware of the impact, that probably means the impact is severe.

More than often technical debt is actually dealt with just by members of the project team caring enough about their future sanity to just fix it. But that's not a scalable solution: it depends on key people essentially doing work out of hours just to stay on track. Even this isn't viable if the problems involve exceed the 'weekend refactor' threshold (the amount your top developer can get done in a big burst over the weekend). Over this level requires a concerted effort, or at least a staged one, which has to be planned for and so can't be fixed 'under the radar'.

I don't have any magic formula for dealing with TechnicalDebt. My strategy has always centered around avoidance rather than anything else, and being really bullish about having to fix things then and there. It's a far more scalable strategy, but I'm very aware that it's not possible on all projects. How you deal with the debt then I'm not sure. My experience has been that you don't, and that forward progress just becomes progressively more expensive. I guess you hope your project finishes before the debt becomes insurmountable.

Software Quality Characteristics

In CodeComplete, McConnell defines 15 'characteristics of software quality':

External Characteristics

• Correctness
• Usability
• Efficiency
• Reliability
• Integrity
• Adaptability
• Accuracy
• Robustness

Internal Characteristics

• Maintainability
• Flexibility
• Portability
• Reusability
• Readability
• Testability
• Understandability

It's important to work out early on in a project what your priorities are (and especially what they aren't) so that you can steer the project effectively. It's also important not to underestimate the effect of all the unspoken tacit decisions made by developers in the course of their work: the unspoken assumptions. Without clear guidelines, developers will benignly pursue their own ideas about 'the right way' to do something. You can tick off all the use cases you like, but if they favour performance or reusability, and your client's real goals are accuracy and maintainability then you're heading for trouble. It’s always the non-functionals that bit you, IMHO.

Fortunately McConnell also points out that given clear guidance, developers will actually do what they're told, which is reassuring. Setting clear goals is a pretty key management tenant, but one easily forgotten. Some of these characteristics (say performance, code-complexity) can even yeild metrics, so you can deal with the project graphically: BigVisibleCharts.

On my previous project, we used this list as the basis for our peer code reviews, out of which came the categorisation I posted previously, but to re-iterate (slightly re-worded):

• Customer Facing (most of the External Characteristics)
• Maintenance and Design (most of the Internal Characteristics)
• Defects (Just hunting for bugs)

I think it’s a good split. Each review role had a cheat sheet which consisted of the relevant characteristics (as defined above) to look for, and some check lists. This helps ensure visibility of the quality priorities into the code review, which makes them doubly hard to ignore.


PS: If you weren't sure what some of the characteristics meant, maybe you should re-read your copy of CodeComplete.

Focused Code Reviews

I was going to write something laying out the arguments for code reviews, but Hacknot beat me to it (and did a better job):

Hacknot: In Praise Of Code Review

To which I'll only add that not only is Code Review cheaper than formal testing, but it picks up whole classes of defects that can never be found by traditional testing (eg: plain unmaintainable code)

On my last project we did peer code reviews, with three random reviewers for the week, each performing a different role in the review:

• Customer Focused & Usability (do the messages make sense, does the flow work, are we accurate and not robust (or viceversa if required))
• Maintenance and Legibility (self-documenting code, documentation comments, architectural synergies)
• Bugslaying (checking for obvious foobars, and reviewing test coverage)

We found this split worked pretty well at keeping reviewers focused, without which people can tend to miss the hard-to-spot stuff. Additionally having multiple people review each unit ensures that someone's bound to pick up on any serious issues, whilst also maximizing the cross-pollination of approaches.

Also I'm all for paper reviews. It's easier to annotate on paper, plus I tend to think along the lines that if someone missed it once on-screen, maybe printing it out reduces the chance someone else will do the same thing.

When to Automate

Generally speaking there are two main reasons to automate a process:

• It's going to be done many times (so it'll save time), or
  
• It needs to be done exactly the same each time

Doing a release build falls into both those categories, so from that perspective automated server builds (ala NAnt / CruiseControl.Net) start to look like a bit of a no brainer (especially if they can do the depoyment for you).

Interestingly, the Braidy Tester points out there's another important reason to automate, one that - as a developer - we invoke all the time: Morale. Even if I'm only going to do something once, if it doesn't take me much longer to automate it, then I will, for the sake of my own sanity. I'm a developer, not a computer.

It's worth factoring in the 'hidden cost' of not automating when making leadership calls, and err on the side of automation when it's a close call. Is not automating worth the morale cost of making people do really boring work?

Fluent Interfaces vs Currying

Martin Fowler's written recently about Fluent Interfaces, which are basically class API's designed from the perspective of creating highly-legible, flowing code. I've been dallying a bit with this over the last year, eg:

    TaskUtils.CopySettingsFrom(source).To(destination);

or

    Assert(someString, new Contains("some substring"));

... having been inspired by the NMock designers. There's even some examples in the .Net class library (eg: the SqlParameterCollection's Add method returns the parameter just added).

I'd only just got round to thinking of it as Currying (and prior to that, Syntactic Sugar). Terminology explosion! Martin's example is a bit more complicated than mine, and the more complicated schemes have their disadvantages, but it's always nice to see people going the extra mile to make their code usable. It adds polish, finesse.

A sharp tool[1] like ReSharper, or VS2005 (C# only) can really make this kind of stuff a breeze - you just type

    someobject.Add(thing).Substract(thing)

...and ReSharper will prompt you to create the appropriate Add and Subtract methods, with it's best guess as to the parameters you want. The result - clearer, more usable API's - is one of the reasons why the TDD guys have been advocating this approach all the time....


[1] As in Chapter 12, 'The Mythical Man Month', Frederick P. Brookes

VSS 2005 doesn't allow 'Leave this file' for writable files during Get Latest

Which is a bit of a pain really:

Unable to keep writable version of file in VSS 2005?

I tried the hack / workaround and it didn't work for me, so I've 'worked around' the problem by uninstalling VSS 2005 and going back to v6 (NB: need to re-run SourceSafe\Win32\SSInt.exe to re-register VSS6 for integrated source-control with VS / VB).

VSS 2005 was only mildly useful in that it allowed me to use an external diff tool (BeyondCompare, WinMerge) to view my changes, rather than the built-in one, but even then that meant I could only diff against the latest version (no dialog to allow you to put the previous numbered version syntax: eg File.cs;16), so I won't miss it much.

Non transitive equality in VB.Net

One of the good bits of advice that floats around is to avoid overriding Equals() unless you know what you're doing[1]. The requirements for equality (reflexive, symmetric and transitive) are easily broken if you're not concentrating.

It's a pity no-one told the VB team[2]...

Public Sub TestStringEquality()
Dim someString As String
Assert.IsTrue(someString Is Nothing, "Of course someString is Nothing")
Assert.IsTrue(someString = String.Empty, "But it's also empty...")
Assert.IsTrue(String.Empty Is Nothing, "...so doesn't that mean that String.Empty = Nothing ?")
' last test fails
End Sub

[1] And that's without getting into the whole GetHashCode() trauma: When (not) to override Equals?, The Rules for GetHashCode
[2] This is tongue-in-cheek - the Is operator isn't really equality, I know. It's 'samey'.

Doh! VB.Net and C# have different order-of-execution for field initializers...

He stared at the code for some time. The field was Nothing, when there was clearly a field initializer present. What the ...?

It turns out that C# and VB.Net differ in the order in which field initializers and constructors fire in an inheritance tree, whereas me being somewhat C# orientated had assumed the C# way was the .Net / CLR way (those kind of assumptions always get you in the end).

So in C# (as you know) all fields are initialized before any instance constructors run, working from most derived to base class, then the constructors fire from the base out:

Out: Initializing static field initializer in BaseClass
Out: Initializing static field initializer in DerivedClass
Out: Initializing field initializer in DerivedClass
Out: Initializing field initializer in BaseClass
Out: Initializing field in constructor in BaseClass
Out: Initializing field in constructor in DerivedClass

However in VB.Net all the base class field initializers and constructors run before the derived class gets a look in:

Out: Initializing shared field initializer in BaseClass
Out: Initializing shared field initializer in DerivedClass
Out: Initializing field initializer in BaseClass
Out: Initializing field in constructor in BaseClass
Out: Initializing field initializer in DerivedClass
Out: Initializing field in constructor in DerivedClass

This is probably due to the slightly looser rules VB has about what can go in a field initializer (eg dates). I'm guessing they probably fudge the IL so all those field initializers end up rolled into the constructor), but aaaaaaaaaarrrggghh... .

(I wonder what happens with cross-language inheritance....)

Of course none of this would be a problem if people[*] avoided the 'calling virtual methods from a constructor' trap, but at least in C# you can use the field initializers to (partly) ameliorate the problem. In VB, no.

ConstructorsShouldNotCallBaseClassVirtualMethods
Brad Abrams : New Design Guideline: Virtual Members

* by people, obviously I mean whomever originally wrote the class I was struggling with

Wierd stuff about VB.Net (from a C# perspective)

I knew that VB.Net was different, but it's funny how many extra things you find when you have to work on it day in day out:

Language

• Wierd syntax (of course :-)
• No documentation comments, or support for tool-tip documentation at break time (hover over String: C# "System.String represents text etc..." VB: "String" :-(
• Can have dates as constants
• WithEvents
• Exposes static methods on instance members, but only by casted type (so no real advantage from a polymorphic perspective)
• Shadow by name, not by signature
• With keyword (kinda handy at times)

Syntax hording / Legacy syntax

The VB.Net team seem to be dragging a lot of compatability cruft with them.
eg. 7 different ways of declaring arrays, depending on where you feel like placing the brackets and the array length (watch out for the UBound / out-by-one syntax):

Dim someArray1() As String ' -> Nothing
Dim someArray2(1) As String ' -> Array[2] of Nothing
Dim someArray3() As String = New String(1) {} ' -> Array[2] of Nothing
Dim someArray4() As String = New String() {"One"} ' -> Array[1] as specified

Dim someArray5 As String() ' -> Nothing
' Dim someArray6 As String(1) ' -> Actually not allowed
Dim someArray7 As String() = New String(1) {} ' -> Array[2] of Nothing
Dim someArray8 As String() = New String() {"One"} ' -> Array[1] as specified

Also...

• Assigning return values to the property / method name rather than using Return, which as a consiquence requires...
• Default return value of 'Nothing'

And they seem to be making more as they go along:

• Me.New() vs MyClass.New()
  

IDE

• Funny (slightly disfunctional) pulldowns
• No pre/post build events
• No 'close all windows but this' (how wierd is that?)
• Simplistic flat namespace model (everything in a namespace named by the assembly, hard to change this model)
• Debugger 'rolls up' class heirachy if not dealing with most derived type - can make it impossible to see some fields / properties on base class that are later shadowed
• 'This' debugger window actually is a 'Me' window. However what's displayed in all the debugger windows does change from language to language (see above), so what's with not changing the window name...

Runtime

• Different order of field initialization (base first)
  
• Strange non-transitive equality with empty strings

Good article from McConnel 'Stuck in a VB.Net ghetto'

Using Log4Net's FileAppender in a web garden

Whilst you might not think you're running a web garden (that is: running your website in two or more processes simultaneously on the same machine), it's worth checking in case your server SOE catches you by surprise (hint: this happened to me):



Obviously in this scenario it's not just log4net you've got to watch out for, but anything you're saving on the local filesystem is a candidate for cross-process resource contention. In log4net's case, the RollingFileAppender can block itself (in the other process).

There's a couple of ways round this. You can configure the FileAppender to minimize the amount of time it locks the file (the MinimalLock attribute), but for diagnostic simplicity I prefer to configure each web application instance to log to a different file. Something like this:

 <appender name="File" type="log4net.Appender.RollingFileAppender">
  <file type="log4net.Util.PatternString" value="C:\temp\MyApp_[%processid].log" />
  <datePattern value="yyyyMMdd"/><!--roll the file daily-->
  <rollingStyle value="Date"/>
  <appendToFile value="true"/>
    
  <layout type="log4net.Layout.PatternLayout">
   <conversionPattern value="%date{ABSOLUTE} [%thread] %-5level %logger.%method() - %message [%identity]%newline" />
  </layout>
 </appender>

This way if anything screwy happens in one of the instances (it didn't start alltogether?) it's easier to isolate.

PS: Blogger is so not the right engine to be doing this XML stuff in...

The VS forms designer sucks

When you drag a control onto a form, what's the first thing you do?

You rename it (to something sensible rather than TextBox1), and clear or set the .Text property from the default. Both of which involve fiddling about in the property grid finding the right entries, which is slow and tedious. Why?

Presumably Microsoft think I spend all my time resizing and repositioning the controls, rather than tweaking their properties. Well, sorry... but no, most of the time it's just drag and drop, possibly adjusting the width to fit after I set the text.

There must be a better way... (thinks: probably some kind of VS add-in that prompts for the control's caption, and bases it's name on that with some kind of standard prefix...)

How does VS.Net's Call Stack window infer the language the assembly was written in?

From the .pdb file it seems, sadly. Take that away, and it blanks out.

So I still don't know of any reliable way of determining what language an assembly was written in purely from the assembly / manifest. Of course it shouldn't matter - but it's nice to know...

VB.Net vs C#

(As if the debate hadn't been done to death already, right?)

I'm not a big fan of VB. Frankly the syntax sends beads of sweat down the small of my back, and attempting to find the right method using those pull-down thingies gives me fits. However even I'd have to admit, there's no real 'big ticket' items that you could wave about to say 'VB is shit' (or 'C# is shit' if you're that way inclined).

Instead what we're into here is market differentiation. This is normally known as price descrimination, but in this case it's more like developer differentiation (note how I avoided saying something like 'intelligence descrimination' ;-). Because ultimately we're advocating the same thing - .Net - and buying another house for BillG with our licences.

Whilst we sit divided, bickering over the relative merits of curly braces vs End Sub, what we should be discussing is the more important issues like:

• when Microsoft will properly support test-driven development in it's toolset?
• whether J2EE has caught up / overtaken .Net yet (how come all the good stuff - think log4net, NMock, NHybernate etc... is all java ports)?
  
• is there yet a sensible framework for developing on Linux?

It's like a debate over white vs black iPods. Us .Net developers really need to get out more...

How to abort VS solution build when project build fails

On bigger projects one of the most irritating bits about Visual Studio .Net is it's 'carry on regardless' approach to multiple project compilation. A project fails, so instead of halting so you can fix it, you get a zillion build errors in all the other projects that reference it. This just slows down the build-fix cycle, not least because the 'root cause' error is drowned out in noise (the Task List window is useless in this regard, one has to find the first instance of the word 'Error' in the build output, and work from there).

There's a simple macro fix for this, terminate the build after the first error, however every time I move machine I forget where to find it (it strangely eludes my google-fu). So here it is:

http://www.ftponline.com/vsm/2003_10/online/hottips/sabbadin/

Private Sub BuildEvents_OnBuildProjConfigDone( _
  ByVal Project As String, _
  ByVal ProjectConfig As String, _
  ByVal Platform As String, _
  ByVal SolutionConfig As String, _
  ByVal Success As Boolean) Handles _
  BuildEvents.OnBuildProjConfigDone

  If Success = False Then
     DTE.ExecuteCommand("Build.Cancel", "")
     Dim win As Window = DTE.Windows.Item(EnvDTE.Constants.vsWindowKindOutput)
     Dim OW As OutputWindow = CType(win.Object, OutputWindow)
     OW.OutputWindowPanes.Item( _
        "Build").OutputString( _
        "ERROR IN " & Project & _
        " Build Stopped" & _
        System.Environment.NewLine)
  End If
End Sub

Why this isn't in the IDE from the get go amazes me. Did no-one at Microsoft ever write a multi-project solution in VS.Net?

Incidentally why is there no upward limit on the errors reported even within a project? One project I worked on had one massive code-gen'd file. When this broke, there could be upwards of 10,000's of build errors generated, which totally locked up the IDE for 5 minutes at a time. It wasn't responsive enough to manually Cancel Build, so you'd have to sit it out. I emailed the VS team lead (literally years ago) and his response was something like 'what a good idea'. So where's the fix?

Homily #1: Late binding is for code-gen only

Today's message: don't use late binding in any code that you (rather than the machine) wrote.

Why would you? No intellisense, no compiler safety net, diminished performance (in some cases). Even when you're sure you've got the right member, did you spell it right (and did you get the casing right, where applicable)?

It's not like it's hard to do either, eg:

• Generate a strongly-typed dataset, and load the data into that instead, or
• Use one of any number of code-gen tools to build objects from your data
• For 'magic values' held in a database (or otherwise), use code-gen to import them into your code as constants / enumerations, and use them from there

It's the OnceAndOnlyOnce principal again: any time you build a 'wrapper' object like this you're centralizing the knowlege and maintanance of the binding contract in one place, and whilst you're not isolating the application from it (typically you'd expose members with names matching the data columns), any breakages are caught by the compiler.