Fiberglass flowers

Comparison of Microsoft Visual Studio unit tests (MSTest) vs NUnit, mentioning PartCover and

Another problem with MSBuild bootstrappers that can screw all your installation…

If scheduling reboot after installing .NET or other prerequisites, bootstrapper copies itself to run from TEMP on boot. Why not staying where it is - who knows. And definitely, all the other MSIs are not copied, so it won’t find them. Reproduced for me.

Now give up and go write own bootstrapper. I’m setiously considering going for InnoSetup deployment.

For now, I’m trying a crazy ting, to copy MSI to TEMP for Setup.exe to find it after reincarnation… It’s the way to use given tools.

After Microsoft didn’t include .NET 3.5 in any current release of Windows (read “Vista service pack 1″), some of us developers who believed in long-ago C# 3.0 ads, had to roll back to .NET 3.0 and C# 2.0.

Including me.

Not mentioning pain of rolling back all LINQ tasties in code and debugging our replacements (do you know why you can’t implement Where() just with yield-style function?), it means installing .NET 3.0.

It seemed to be not a problem, having a MSBuild code snippet that worked for 3.5 - just replace 3.5 with 3.0:

<ItemGroup>
<BootstrapperFile Include="Microsoft.Net.Framework.3.0">
<ProductName>.NET Framework 3.0</ProductName>
</BootstrapperFile>
<BootstrapperFile Include="Microsoft.Windows.Installer.3.1">
<ProductName>Windows Installer 3.1</ProductName>
</BootstrapperFile>

<Target Name="Bootstrapper">
<GenerateBootstrapper
ApplicationName="blah blah blah blah"
BootstrapperItems="@(BootstrapperFile)"
BootstrapperKeyFile=""
OutputPath="obj"
ComponentsLocation="HomeSite" CopyComponents="false"
SupportUrl="http://www.microsoft.com/downloads/details.aspx?familyid=10CC340B-F857-4A14-83F5-25634C3BF043"
Culture="en" Path="$(BootstrapperPath)"/>
</Target>

Won’t work.

Hell why? Who knows. Logs in temp don’t give proper diagnostics, nor system events do. WPF fails to install at some point onto every XP installations we have, including clean special test XP SP2 VMWare images downloaded from Microsoft.

Update: Here’s the answer.

Now I rolled back to dotnetfx3setup.exe redistributable. It’s 2.8M compared to 300K bootstrapper generated by MSBuild, and it’s a pain to see installer grow…And if .NET 3.0 is already installed it starts to uninstall it… and there is no key to make it just “check or install”, need to trick it via WiX.

But we have to pay it. Oh my.

All over the Web I see no evidence that any man walked this path before. For.NET 2.0 - a lot of mentions and code samples. And completely empty for .NET 3.0.

Some pages that somewhy didn’t appear at top of Google searches for WiX help.

• WiXWiki.com - pretty useful and contains some snippets you won’t find in WiX manual or tutorial. Many of rare code snippets
• WiX development releases; some broken (last two broken in VS 2008), some contain the very things you’ll need;
• Justin Rockwood’s blog entry with Votive (Visual Studio addon) preprocessor variables. The blog itself is also thing to read;
• Alex Shevcuk’s blog entry on checking pre- and postconditions in WiX. His whole cycle on WiX - I also highly recommend it;
• Separately, .NET: WixWiki pages about checking for .NET runtime and deploying it with a bootstrapper generated with MSBuild;
• Another WiX wiki on mindcapers.net, I particularily needed ICE38 error explanation;
• John Robbins’ blog entry on patching patching with WiX. You don’t want number of auto-update patches to grow quadratically?
• Last but not the least, MSI properties reference on MSDN.

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);
  }
}