singalen: (Default)

Originally published at Fiberglass flowers. You can comment here or there.

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.

singalen: (Default)

Originally published at Fiberglass flowers. You can comment here or there.

Now I know it.

It’s Windows Installer error 1618 that I didn’t see somewhy when attempting to fix .NET bootstrapper. Either I was inattentive or it wasn’t there: “Another copy of msiexec is running”. You can’t have two Windows Installers running, at least if one of them installs .NET. Information is from this maillist post.

Why? Implementation limitations, I believe. No sane reasons for such a contract, no article mentioned this. Surely, who’s going to declare own “features” of that kind - just a gentle hints that “you should better use bootstrapper”. Another reason to long for a systems where setup is just a copy.

So go pack a MSI, then make a MSBuild bootstrapper.

Oh wait, do I have to have 2 files in my installation? And my customers can’t download one file?

Yes. Or go for WinZip Self-Extractor, or WinRar, or whatever else.

What about build scripts? For WinRar, here’s a nice sample. For WinZip sfx, there’s also a command-line interface. Do a

wzipse32 %ARC_NAME% -setup -auto -runasuser -le -i ../icon.ico -wait msiexec -c ".\setup.exe"

WinZip will do the thing, though displaying some dialogs we don’t need at all.

Oh, WinRar won’t work, because it erases temporary files upon setup.exe completion. And we need to wait for msiexec, because setup.exe exits earlier. What a pity.

singalen: (Default)

Originally published at Fiberglass flowers. You can comment here or there.

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:

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

<Target Name="Bootstrapper">
ApplicationName="blah blah blah blah"
ComponentsLocation="HomeSite" CopyComponents="false"
Culture="en" Path="$(BootstrapperPath)"/>

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.