Fiberglass flowers

Windows Installer on itself is a pain. WiX saves you from it, mostly wrapping the complexity into XML constructs understandable to non-gurus.

Well, not completely - you still have to know:

• why the heck shortcut didn’t appear in start menu;
• how to create a web site shortcut;
• why to create RegistryValue for a program directory you create, and that’s the simplest things. Still better then MFC…

But a very good tutorial exists, maillist is very active and it’s easy to get support.
Maybe it’s another reason to love Unix-es, where “install IS just a copy”.
Though, one has to admit that installing Windows application involves somewhat more desktop integration.

I was looking for an auto-update, so that:

• application could say “New version available, download? Restart now?“;
• would use MSI;
• download should preferably use BITS.

Simple automatic updaters like this on Codeproject won’t do, because you can’t just download necessary files: Windows Installer will revert them back. Or you would have to “disable WI’s Resiliency“, which is also a bad idea.

Solution of my choice

ClickThrough subproject of WiX promises that, but it’s still beta and crashes. Still you can easily compare two MSI files, generate a MSP patch, and a RSS feed that client can check, download and even read by eye, so simple it is - a pretty tasty feature.

There is no .NET client code. For now, there is only a separate update.exe that will find, download and install new version. Still, you cannot ask user whether to download now or not, cannot tell what’s new, when to restart, etc.
But you can painlessly add a Start menu shortcut that will update your application.

Come later, I’m going to create a C# code that will check for updates, and probably publish it.

Other solutions

You can use Updater ApplicationBlock, or more exactly, latest version now lives at CodePlex. But Enterprise Library wasn’t updated for .NET 3.5, and I believe it’s abandoned.

You can use NSIS. Though, it’s not Windows Installer MSI packager, it creates own files and scripts.

For ClickOnce application, you can use Application.Deployment.

Till now, I did understand but didn’t remember the very situation, as I wasn’t the one creating thread pools and alike: all the core things were already there.
It’s a blessing to work for start-up.
You can think about

Monitor.Wait(toRetrieve); // will throw SynchronizationLockException

Now, after a look into docs, I see that one needs to hold the monitored object lock to avoid race conditions: a thread wakes up already holding a lock for an object it needs. The thread that did Pulse() acquired that lock and safely passed it to Wait()ing one.
Just watch out for deadlocks: it’s easy to wake up with one object lock, try to acquire another and die then…

lock(toRetrieve)
{
  Monitor.Wait(toRetrieve); // will throw SynchronizationLockException
}

As Doug Lea recommends in his excellent eternal “Concurrent Programming in Java“, just make it impossible. Lock only on a single object. If you really really need two locks, make them ordered: always acquire A then B.

If you do:

lock(a){
  // :
  lock (b)
  {
    //:
  }
  // or:
  b.SomethingThatLocks();
}

//then will you never ever do

lock(b)
{
  //:
  a.SomethingThatMightLock();
}

as calling other objects’ methods while holding a lock badly affects your karma.

For more in-detail look, read “EventWaitHandle and Monitors: how to pick one?” by Joe Duffy. He goes very deep down to system details.
He also did a nice brief overview of missed pulse problem - why do you always check wait condition in a loop:

while (toRetrieve.Count == 0)
{
  lock(toRetrieve)
  {
    Monitor.Wait(toRetrieve);
  }
}

I prefer first to identify program classes, then to think some time about its design, the longer the better.

Then, to prove my internal API idea, I make up code pieces by “wishful thinking”: how I wish the code to look, for it to be the most brief and to express core system objects and functionality, for classes to be least coupled etc etc.

I write them down to code, mock up classes, and try to make the code example work in unit test harness.

During this process I see more details: what does the API miss in order to make pieces work, especially in initialization, finalization, and whatever things were missed during initial design.

Finally I get a (huh) nearly working system core covered with readable unit tests.
I believe, not whe worst approach. Now, how can it be improved?
What did I miss?

Am I the only one who ran into .NET (or GDI?) bug with Pen (or Matrix) .ScaleTransform()?
When I scale a pen to certain width, and it has an anchor, anchor draws at inverse scale.
I might be missing something, but here’s my test. Pen scales proportionally to form width, for simplicity.

Here’s how it looks:

You see, the thinner the line, the bigger is the cap. Uh-oh.

My workaround should be here after some time.
Source code for interested ones:

It turned out that a very productive idea — to use domain data scheme (sample) as a basic of requirements categorization — is already used. Moreover, idea is standardized in ISO-13250: Topic Maps.
Wow.
Though, some other, non-domain topics will appear: like nonfunctional requirements, GUI details, project specifics. But still I believe topic map is to be based on domain model.

Got a web reference to an article “Applied MVC Patterns. A pattern language” by Sergey Alpaev.
Model-View-Controller is one of the most complex and pribably the most misinterpreted patterns among GoF’s.

The article is a perfect classification, I recommend it as a must read for everyone who is confused about what is Controller for, and to those who already know it.
Wikipedia article also has some very basic analysis of the pattern.