At last, we have a cool UI for this feature.

It starts here:

And then moves to this window:

Yes, I know, it is not earth shattering UI, for sure, but it is one hell of a cool way to inspect even deeper into what NHibernate is doing.

About three months ago, I started looking around for licensing components for the NHibernate Profiler. I didn't care to write the feature myself, and I thought that for a small investment of money, I could get a ready made and useful component.

I looked around and finally ended up on XHEO's site. I heard about XHEO before, the feature set looked decent and the documentation was good. I downloaded the trail and gave it a go. Everything seemed good, so on the 26th Nov, I purchased the professional version. Shortly after that, I released the private beta of NH Prof.

Almost immediately I got comments from users saying that the software will not work on their machines. The common theme? All of them were running 64 bits platform. I narrowed the issue down to the licensing component. After I contacted support, I was told that yes, that is the case, and 64 bits is not supported. It is even mentioned in the documentation, so I really have no cause for complaint.

Now, mentioning such a limitation in a footnote hidden deep in the documentation is not what I would call being open about your limitations, but we will let it go.

They had a workaround which I wasn't really comfortable with, but it worked, so I just used that. It would cause problems down the road (it basically running in WOW64 mode, and I suspected it would cause issues relating to binding to 64 bits drivers with the Open Query Results features). The only real way of fixing this was to by purchasing Ultimate Edition With Source.

At that point, I also started getting more requests regarding licensing. That is when I encountered this beauty:

Yes, I need professional or better, but I have professional. I guess someone put an > instead of >=.

Anyway, I was already in favor of buying the version that would let me run on x64 natively, so I decided to go ahead with this. A major part of my decision to go ahead and buy the source version was that I kept getting errors like this one:

System.Windows.Markup.XamlParseException: Failed object initialization (ISupportInitialize.EndInit). The type initializer for '<Module>' threw an exception.  Error at object 'HibernatingRhinos.NHibernate.Profiler.Client.MainWindow' in markup file 'HibernatingRhinos.NHibernate.Profiler.Client;component/mainwindow.xaml'. ---> System.TypeInitializationException: The type initializer for '<Module>' threw an exception. ---> System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
  --- End of inner exception stack trace ---
  at Licensing.LicenseManager.AssertValidLicense()
  at HibernatingRhinos.NHibernate.Profiler.Client.MainWindow.OnWindowInitialized(Object sender, EventArgs e)
  at System.Windows.FrameworkElement.RaiseInitialized(EventPrivateKey key, EventArgs e)
  at System.Windows.FrameworkElement.OnInitialized(EventArgs e)
  at System.Windows.FrameworkElement.TryFireInitialized()
  at System.Windows.FrameworkElement.EndInit()
  at System.Windows.Markup.BamlRecordReader.ElementEndInit(Object

This is part of NH Prof's production error reporting, so I know why the software crashed and can fix this. If you follow closely, Licensing.LicenseManager.AssertValidLicense, will call into XHEO's licensing component, and in some cases, completely crash the system.

I figured that with the source version, I could fix that.

That was the point where I was told that if I wanted the source version, I also needed to deploy obfuscated assemblies. And that this would jump the price by almost 1,000$. I didn't mind deploying obfuscated assemblies that much, but I did mind the extra 1,000$. Nevertheless, I decided that it was probably worth it to not have to worry about licensing.

That is when the real problems started. According to the license agreement between me and XHEO (which was signed by both parties, this is not your standard EULA), I cannot use the source without obfuscating it. That make sense, from their perspective. Except... the obfuscator that they sell doesn't work.

Here are just a few of the errors that I got.

Complete system melt down:

Just simple errors:

Or producing software that cannot run.

I had spent quite some time with XHEO's support, trying to resolve the issue.

First, I have to say that in general I have found them to be completely unresponsive, often letting multiple business days go by without so much as acknowledging that a message was received, much less that they are working on it. This post is a copy of an email that I sent to them, and a good example of the kind of interaction that I had with them at that point.

After several days going back and forth with their support, they have been unable to make the software work on my machine, rendering my entire purchase useless.

That is when I dug into the signed contract that we had, and verified that I remembered correctly. There are two sections which are particularly important:

What this basically says, is that if they don't deliver a product that works, they should either provide one that works, or refund the money.

At that point, I was sick and tired of the whole thing and sent them an email, telling them that they have failed to provide me with a working copy, and that I would like to get a refund. As per our signed contract.

This is the reply that I got:

At that point, I have to remind you. I still wasn't able to get the software to run without errors.

I replied, and got no response. Replied again, several days letter, and got basically the same thing, replied to that again. Was ignored.

Finally, I sat down and wrote this email. I think you can tell how frustrated I am with the whole thing.

That got me talking with someone else. Who wasn't very helpful.

I cannot believe this.

To summarize:

• I am out a lot of money.
• I have a product that doesn't work and support that is extremely non responsive and not really helpful when it is responding.
• I have a company that thinks that "It works on my machine" means that it can ignore a crashing bug and total uselessness of their product for a paying customer.
• I have a company that is ignoring a signed contract and refuse to honor it.
• I have a huge amount of time invested into making this work, and not into actually producing good features for NH Prof.
• I have a delayed launch for my software.

I just can't understand how they think that behaving in this manner to their client.

After this experience, I would strongly recommend to all and sundry to avoid them.

Patrick Smacchia (NDepend) has a good post about this topic. I have an issue with his assertion that "Static Structure is the Key":

The idea I would like to defend now is that when it comes to understand and maintain a program, one need to focus mostly on the static dependencies, the ones found in the source code. Knowing dynamic dependencies (who calls who at runtime) can make sense for example to profile performance or to fix some particular bugs. But most of the time invested to understand a program is generally spent in browsing static dependencies.

The problem is that this doesn't really hold for applications that were written with a container in place. Let us take Rhino Service Bus as an example of that. If you try to follow the static dependencies in the code, you will not be able to understand much. There aren't many.

If we will look at things like error handling, administration tasks or time outs, all of them are key parts of the way certain aspects of RSB behave, we will see that there is never a static reference to them. Instead, they are pulled in as a set of generic components that know how to integrate into the bus.

A significant part of the actual behavior in RSB is dynamically configured by RhinoServiceBusFacility, and even here, I felt that this class was getting too many responsibilities, so we broke that apart to more dynamically composed parts. The configuration syntax, for example, is driven by the facility and by the BusConfigurationAware components (of which we currently have three).

Focusing on the static dependencies in RSB wouldn't be very useful, not a lot is happening there.