Setting up a WIX 3.0 build environment

I recently encountered some problem with heat.exe with respect to COM registry harvesting, and wanted to step through the code in the debugger, to see what was the problem.

I had some initial trouble setting up a dev environment for WiX, have read Neil Sleightholm's post on  How To Create a WiX build machine, but it didn’t go so well for me.  The process is really simple, with the following commands:

• do a cvs checkout per instruction here:
  • cvs -d:pserver:anonymous@wix.cvs.sourceforge.net:/cvsroot/wix login
  • cvs -z3 -d:pserver:anonymous@wix.cvs.sourceforge.net:/cvsroot/wix co -P wix
• set WIX_ROOT environment variable
• cd to %WIX_ROOT%
• Run bin\wixenv.bat,
• Run NAnt

Yet, when I ran the NAnt command, I kept getting this error:

Failed to initialize the 'Microsoft .NET Framework 2.0' (net-2.0) target
framework. Property evaluation failed.
Expression: ${path::combine(sdkInstallRoot, 'bin')}
^^^^^^^^^^^^^^
Property 'sdkInstallRoot' has not been set.

Part of the problem was that it needed a post-0.86-beta1 build of NAnt, which unfortunately, is not available on the NAnt project home page. I managed to find it by googling, leading to  this download link (the version I downloaded was 0.86.3317.0, 30/01/2009).  Once I got NAnt 0.86.3317.0 in place, the wix build finished without a hitch.

Vundo disabled Norton 360

I had a full day of battle with Vundo.H Trojan last Sunday trying to get my dad’s infected computer cleaned up.  The parasite was occasionally popping this message:

“Your system is infected with dangerous virus! Note: Strongly recommend to install antispyware program to clean your system and avoid total crash of your computer!”

As well, it’s the root cause of a subsequent DoS (more later).

One of the registry keys that was infected was the  AppInit_DLLs key, which Raymond Chen once wrote about in a blog entry aptly entitled  AppInit_DLLs should be renamed Deadlock_Or_Crash_Randomly_DLLs.

Anyway,  kudos to Malwarebytes' Anti-Malware for being a very useful tool.  But for a while there, as I sat and watched explorer.exe puts back this registry value no sooner than I deleted it, I felt like I was in the late 80s, early 90s, where viruses freely infected MS-DOS in similar manners.  I finally woke up and demoted my dad to non-administrative user level, which brings me to the next point about  antivirus.

In addition to the annoying popup, Vundo also messed up the antivirus software.  My dad had Norton 360 installed on his system, with at least 30 days remaining in his update subscription.  Yet, Vundo managed to sneak through, and somehow confused it enough to DoS my attempt to access the Internet—not only port 80, but all ports were being blocked.  One note of interest: for a while there it was refusing Firefox but lets IE through, but after a while, even IE was returning the  “Web page cannot be found” message.  Anyway,  I uninstalled Norton after cleaning Vundo and was then able to surf the web again.

 

There seems to be some controversy about using antivirus software over running Windows under a  non-admin account.  Apparently, over 92% of Windows security vulnerabilities reported last year could have been prevented if users were not using admin accounts.

I know that for me, running as a non-admin user will probably never fly in a software development environment where running a build requires elevated privilege in order to do COM registrations. As for my dad, non-admin account might suffice for now, but I wonder if it will prevent him from inadvertently falling victim to  phishing scams, which some antivirus software is able to prevent.

Unable to cast COM object of type ‘X’ to interface type ‘_X’

I added a new property to my COM class and consequently bumped up its minor version by 1, did some testing with it, and then decided that I wanted to run a clean build.  Now my existing NUnit test cases that use this class are failing with the following message:

Unable to cast COM object of type MyLib.MyClass' to interface type MyLib._MyClass'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{…}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).,

The interesting thing is that everything compiled without a hitch.  Is this  .NET’s version of BadImplementsRefInCompatLib?

Looking that the COM library’s IDL info via oleview.exe , it turned out that the interop assembly was bound to version 1.3 of the COM library, whereas 1.2 was registered on my machine. I regenerated the COM interop assembly for 1.2, and the problem went away.

Bogus TBird error message on 64-bit Windows Vista

Thunderbird message:

Thunderbird is already running, but is not responding. To open a new window, you must first close the existing Thunderbird process, or restart your system.

At first, when I saw this message this morning, I thought: OMG, some Windows updates that I installed last Friday have actually gone and made TBird 2.0.0.19  incompatible with Vista 64! 

But then, as hinted from this forum post, this bogus error actually means that there’s something wrong with the user profile. In my case, the mail folder was sitting on a disk drive that was disconnected. I reconnected it and all was well as before.

The WPF UserControl experiment 1

Goal: 
To create a WPF user control that implements basic functionality from a  non-GUI interface, and delegating the rest through abstract methods.

Attempt 1:

1. Defined a base WPF user control BaseWpfControl using XAML.
   public abstract partial class BaseWpfCustomPropertyEditor : UserControl, Interface1 { …}
2. Then, extend BaseWpfControl, like so:
   <local:BaseWpfControl x:Class="MyNameSpace.LoginEditorControl"
      xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
       xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
       xmlns:local="clr-namespace:MyNameSpace"
       Height="206" Width="595">
       <Grid Height="300" Width="418">
           <Grid Margin="10,10,-75,120">
               <Grid.ColumnDefinitions>
                   <ColumnDefinition Width="210*" />
                   <ColumnDefinition Width="118*" />
                   <ColumnDefinition Width="155*" />
               </Grid.ColumnDefinitions>
               <Label Height="33" Margin="6,-1,67,0" Name="label1" VerticalAlignment="Top">Host Name:</Label>
               <TextBox Height="23" Margin="12,25,23,0" Name="txtHostName" TextChanged="txtHostName_TextChanged" VerticalAlignment="Top" Grid.ColumnSpan="3" />
               <Label Height="29" Margin="6,47,88,0" Name="label2" VerticalAlignment="Top">User Name:</Label>
               <TextBox Height="23" Margin="12,71,23,0" Name="textBox1" VerticalAlignment="Top" Grid.ColumnSpan="3" TextChanged="textBox1_TextChanged" />
               <Label Height="25" Margin="6,102,94,0" Name="label3" VerticalAlignment="Top">Password:</Label>
               <PasswordBox Height="23" Margin="12,133,23,0" Name="passwordBox1" VerticalAlignment="Top" Grid.ColumnSpan="3" PasswordChanged="passwordBox1_PasswordChanged" />
           </Grid>
       </Grid>
   </local:BaseWpfCustomPropertyEditor>
3. Got compile-time error: "cannot be the root of a XAML file because it was defined using XAML""

Conclusion: WPF user controls were designed for composition, not inheritance.

Attempt 2:

1. Instead of using XAML, simply defined  BaseWpfControl as a class that extends System.Windows.Controls.UserControl
2. Repeat Attempt 1.2
3. Now compiles fine. But when trying to bring up LoginEditorControl, got error:
   ”Problem Loading … Could not create an instance of  type “BaseWpfControl…”
4. Double-checked, BaseWpfControl did have a default constructor
5. Removed abstract partial keyword in base class  Same problem
6. Searched the web; found this https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=292693:
   ”Hello, if you mark your base generic class as abstract, the designer does not work. I understand this might not be a supported scenario and I'd live with this, if:
   1) it would not work with non-abstract classes as well,
   2) all the XAML code would not get underlined, that is really crazy.”

Sub-Goal 1.1:

• how to make an abstract WPF base control editable in the UI designer?

Attempt 1.1.1:

1. Per http://www.urbanpotato.net/default.aspx/document/2001, annotated BaseWpfControl with
   [TypeDescriptionProvider(typeof(GeneralConcreteClassProvider))]
   [ConcreteClass(typeof(UserControl))]
2. didn’t help … same error “Could not create an instance of …”
   

Attempt 1.1.2:

1. Removed abstract keyword from BaseWpfControl .
2. Bring LoginEditorControl control back in the VS2008 Visual Designer. Got message:
   ”The document root element is not supported by the visual designer”
3. Changing base class for BaseWpfControl to ContentControl didn’t help.
4. If we changed to using XAML for BaseWpfControl, then we’d be back to problem 1.3

Attempt 1.1.3: immediate work-around

1. Remove abstract keyword from BaseWpfControl
2. commented out the line:
   public partial class LoginEditorControl : UserControl, BaseWpfControl { 
3. Replaced with:
   public partial class LoginEditorControl : UserControl {
4. Replaced XAML declaration
   <local:BaseWpfControl  x:Class="MyLib1.LoginEditorControl " xmlns:local="clr-namespace:MyLib1"
   with
   <UserControl
5. Edit the control in VS Visual Designer, then undo steps 1-4 prior to running.
   

Stopped experimenting here. If I had had more time, I would have liked to try these:

Attempt 1.1.4: better workaround – use XamlPad
Previous process was too cumbersome to undo. Use XamlPad to edit the control GUI, and then paste he result back to the VS project.

Attempt 1.1.5: How to overcome restriction of “multiple class inheritance”?
Use Events instead.