Xenocode Postbuild: Bad UI or Intentional Deception?

I've been looking at application virtualization products recently and I just keep getting more and more. Seriously, I'm just not `getting` this new business model of `Give us thousands of dollars for the tool AND give us a cut ( tens of dollars ) for every single client you deploy your application to. Seriously, there must be some real discounts out there somewhere if they really think and ISVs will spend boat loads of money just to virtualize their package instead of spending fractions of that to hire quality setup developers to create properly behaving MSI's.

But anyways, my real annoyance came when I was playing with Xenocode Postbuild. I downloaded the eval and went to virtualize a simple winforms app. I got a dialog saying I needed to activate ( which my firewall at work said HELL NO to ) but look at the color scheme:



I loaded this screenshot as 24bit uncompressed so you could see exactly what I see. Look at that cyan looking small point text. What the hell is that? I had to flood fill it to be able to read it:



This just seems sleazy to me and reinforces my perception that something just doesn't quite smell right in the virtualization market.

How DTF is going to help me become a better .NET Developer

I've been doing .NET for a couple years now, but I mostly use it for small tools/automation development. Things like the occasional MSBuild or NAnt task here and there, a SOAP web service that encapsulates a REST web service, or perhaps a custom action that consumes a SOAP web service. The only application work I've ever done in C# was a client/server program that configured a existing system. The application used the ADO.NET 2.0 Factory model, had a framework consisting of a base UI and several application services. I did it pretty cleanly but at the end of the day it was just a bunch of look a like modules using DataGrids. Big deal

So here I am playing with DTF and I'm going back to various CAs that I've written over the years and seeing how they could be done better in C# The first story that I decided to look at is dynamically updating ListBoxes at install time.

I started with a simple statement like this:

session.Database.OpenView("INSERT INTO `ListBox` (`Property`, `Order`, `Value`, `Text`) VALUES ('TESTPROP', 1, '1', 'One') TEMPORARY").Execute();


This is problematic because if you get any of the SQL statement wrong everything will blow up. Trust me, trying to do this in VBScript really sucks big time. There is a reason Script CAs are said to be evil and it’s not just because of virus scanners.

So then I noticed that the DTF Database object has a TableCollection of TableInfo objects that each have built in SqlStatements strings. So I tweaked it up a little:

Database db = session.Database;
string sqlInsertTemp = db.Tables["ListBox"].SqlInsertString + " TEMPORARY";
View view = db.OpenView(sqlInsertTemp );
view.Execute( new Record( new object[] { "TESTPROP", 1, "1", "One" } ));
view.Close();

This is a little bit better but it doesn’t solve a more fundamental problem. I’m trying to manage a list of items, why should I have to care about how to get the data stored in MSI? It started to become obvious a bit of abstraction was needed. The result is creating and invoking a custom class that looks more like this:

ListBox listBox = new ListBox(session.Database, "TESTPROP");
foreach (Process proc in Process.GetProcesses())
{
listBox.AddToEnd(new ListBoxItem(proc.Id.ToString(), proc.ProcessName));
}

Now I'm just instantiating a ListBox class and during it's constructor setting up database and property collection association. I've also defined a ListBoxItem class that strongly types the Value and Text fields. Finally I have an AddToEnd method that takes a new listBoxItem.

This class is by no means complete or bug free. I'll probably want to do things implement capabilities like Add, Insert, Move, Remove, Sort, IEnumerable etcetera. Then I'll probably want to go on to other common stories such as making it easier/more generic to build data driven custom actions that change system state. Serializing/Deserializing CustomActionData. Building ICEs. And so on. Basically the plumbing details that many CAs have to do but really aren’t relevant to the problem trying to be solved.

Yes, I know… these are OO principals that I've learned over the years. I can sit down with a developer and read what he's doing and talk about it but frankly I've never taken the time to hone these skills because it was orthoganal to the problem of writing setup declaratively. After all, when your life is breathing MSI it's kind of hard to get worked up over things like NHibernate vs EF debates. But now that C# is my language of choice for custom actions, it's time to catch up on things I should have mastered years ago.

PS- Does anyone have any suggestions on good books to read? Please, nothing too heavy... go easy on me.

Red Vs Blue Death Match

For some reason Rob Mensching has decided once again to bring up the subject of Red vs Blue. I'm a little confused because I thought he disliked troll posts.


Anyways, he says he's `joking` so I figured I'd share a little bit of my humor also. Now what was AJ saying about taking it out to the playground?





Seriously though, Rob and I have a lot of common friends. I've spoken to them and the general feeling is that I'm being too hard on Rob (misdirecting my frustration), that Rob was out of line for his comments and that it's disappointing that we aren't getting along.

Rob has claimed on his blog that he is leaving the lines of communication open. Believe me... I've tried. However, he doesn't seem to be serious as it takes him a week to answer an email. Oh well, it took Sinan 1 1/2 years to get his apology, why should I expect one any sooner?


PS- Rob says he doesn't read my blog anymore ( actually he sent me an email to that effect a year ago ) but my statcounter tells me otherwise. Anyways, I'm just kidding here also. One day the two of us are going to be slamming some beers and this will be really funny in an alpha geek sorta way.

More Information on the .NET 3.5 Client Profile

I noticed a link over on the WiX-Users list for even more information on the .NET 3.5 Client Profile. I've not had a chance to absorb it all but I wanted to share the link ASAP.

Edit: I've absorbed a bit and I'm a little less impressed with this servicing mechanism. It seems that this is really aimed at XP SP2 with no framework. XP machines ( and all Vista machines ) with the framework can't go the client route but must instead get the full install.

Thinking back to my originial problems deploying .NET 3.5 applications, I'm not sure if this will really help us or not.

Also I noticed this little quote from the MS blog

"As is illustrated in the preceding table, the Client Profile deployment is focused on Windows XP SP2+ with No Framework components installed. This platform configuration is still the predominant platform configuration and will continue be so for the foreseeable future."

Ouch. I'm sure the SlashDot and Apple fans would love that quote.

Cancer Update

I haven't spoken about my wife's battle with cancer in a while but I just read an article about Senator Kennedy being diagnosed with a brain tumor that brought it back to my mind.

Cheryl had a seizure at about 2am one night back in October. I guess I'd blocked out how scary that day was until I read the article today. It was absolutely horrifying to wake up to her having a convulsion and then spend hours and hours in the emergency room as they did countless tests to rule out every possible reason. Believe me, some of the things they suspected were truly bizarre. It was almost like watching house only it isn't funny because it's YOUR wife on the table.

I'll never forget how relieved we were when finally one of the many doctors came to her room, picked up her hand and said `You don't have brain cancer.`

Anyways, 7 months have passed since that night and I'm currently tearing up as I write this. Cheryl has chemotherapy (yet again) tomorrow and only one more treatment scheduled a couple weeks later.

After that it's a matter of wait and see. Only we don't plan on doing much waiting as we are currently busy planning a few summer getaways.

LINK: Annoying software: a rogues' gallery

I just came across this article on ZDNet. When I read the title I just knew that most of the complaints would be about the installs. Sure enough, as I clicked through through the first 6 annoying applications the complaints were aimed squarely at installs that treat customers computers like it's ISV owned equipment.

It's a really good read and it's a good reminder why auto update patterns, unwanted bundled software, annoying reboots and ordering customers to widen the attack surface of their system just to use these applications is NOT Setup Goodness.

Unfortunately we are going to see even more of this garbage going forward as it's sadly bound to be getting easier for ISVs to hoist crap like Yahoo! Toolbar on users machines.

Data Driven Managed Custom Actions made easy with DTF

One of the shortcomings of Windows Installer is no built in ability to perform math functions. Fortunately this is made easy in C# thanks to the AxLibrary project from Ron Ayoub found on The Code Project. Now with DTF's ability to easily and reliably write Manged Custom Actions creating a simple math evaluation pattern is easy. Consider this database snippet in WiX:

(Note: I originally wrote the table using InstallShield but decided to re implement it in WiX since it's easier to read without visualization. But it sure is more difficult to author. In InstallShield it only took a few clicks and fill in the form typing in the schema wizard. )

The goal is to query the Math table and process math statements with conditions that evaluate to true. Using C#, DTF and AXLibrary it's as simple as this block of code:

The result is a log file like this:

Wow, is that easy or what? I'd love it if someone would write the same functionality in C++ and show what it would look like. BTW, even though DTF comes from WiX, this CA was actually executed via InstallShield. After all, it is just a Type 1 exported stdcall function.