Well… I am still working done the list of stuff people request for the profiler (NH Prof, HProf, L2S Prof & EF Prof) , and one of the things that popped into the head of the list was wanting to have programmatic access to the profiler output. We aren’t talking about just the XML reports that are available, but to be able to get the data in a way that is easy to work with.

Well, here it is:

There is a new DLL in the profiler distribution, HibernatingRhinos.Profiler.Integration, where you can find the CaptureProfilerOutput class. That class will let you start the profiler, capture whatever happens in the middle, and finally stop and return you an instance of a report, containing all the data about what actually happened.

This is perfect if you want to use the profiler as part of your integration tests library. As an aside, you can also use the new DLL to programmatically parse (by using XML Serialization) the XML reports that you generate as part of your build, so you get very easy way to build rules around that report.

One of the features that keep popping up for ÜberProf is that people want to use that in CI scenarios, usually to be able to programmatically check that they don’t have things like SELECT N+1 popping up, etc.

With build 562 of ÜberProf, this is now possible. How does this works? We now have a command line interface for ÜberProf, with the following options:

/CmdLineMode[+|-]         (short form /C)
/File:<string>            (short form /F)
/ReportFormat:{Xml|Html}  (short form /R)
/Port:<int>               (short form /P)
/Shutdown[+|-]            (short form /S)

Starting up with no options will result in the usual UI showing up, but you have a new mode available for you. Let us say that you want to output the results of your integration tests into a format that you can easily work with programmatically. Here is how it can be done:

nhprof.exe /CmdLineMode /File:Output.xml /ReportFormat:Xml <-- starts listening to applications
xunit.console.exe Northwind.IntegrationTests.dll
nhprof.exe /Shutdown <-- stop listening to applications and output the report

The example is using NH Prof, but the same holds for all the other variants.

The way it works is very simple and should be pretty easy to integrate into your CI process. The XML output can give you programmatic access to the report, while the HTML version is human readable.

One thing that you might want to be aware of, writing the report file is done in an async manner, so the shutdown command may return before writing the file is done. If you need to process the file as part of your build process, you need to wait until the first profiler instance is completed. Using PowerShell, this is done like this:

nhprof.exe /CmdLineMode /File:Output.xml /ReportFormat:Xml
xunit.console.exe Northwind.IntegrationTests.dll
nhprof.exe /Shutdown
get-Process nhprof | where {$_.WaitForExit() } <-- wait until the report export is completed

Please note that from a licensing perspective, the CI mode is the same as the normal GUI mode. On one hand, it means that you don’t need to do anything if you have the profiler already. On the other, if you want to run it on a CI machine, you would need an additional license for that.

I got up this morning and the following showed up in my tweeter search:

I would say that from the “is the profiler helping customers?”, we are in a pretty good position.

Well, here is a new thingie, L2SProf can now detect transactions.

Both standard SQL transactions:

And also distributed transactions using System.Transactions:

This is an interesting feature, because you can see how the use of different transaction strategies have a big impact on how you structure your code.

For example, with L2S, it seems like you are encouraged to read outside of a transaction. Something that I, as an NHibernate user, find quite odd.

I really want to be able to provide duration & row count for Linq to Sql. It has became a personal goal of mine.

The problem is that there is absolutely no open extensibility points within L2S that would allow it. The solution is… to  break down the wall. If you don’t have extensibility points, then I will make some.

And, you know what? I did:

The problem is that it took almost 12 hours to get it to this point, and along the way I had to build a new provider for Linq to Sql. And yes, that is not possible. Not isn’t supposed to be possible, just is not possible.

To get this to work I had to build a hack on top of a crack on top of a very angry duck.

I have been working on this for the last 12 hours, and this is about the most unsupported method that you could find to hook into things (I had to break the CLR type system to get this to work, and the things that I do with reflection are probably amoral in at least three different religions).

The problem with going with that route is that now I have to delay the public beta for L2S Prof. The good thing is that I can now provide additional information about Linq to SQL.

Well, after talking about it quite often recently, I think it is just about time to make this public.

The Linq to Sql Profiler is now on public beta, and it is even more awesome than you could imagine.

We are able to get a tremendous amount of information out of Linq to Sql, so from profiling behavior it is quite on par with NH Prof or Hibernate Profiler.

Here is a screen shot:

Please note that the UI color scheme is still under development, we would love to hear feedback about that as well.

Like NH Prof, L2S Prof is currently offered in a 30% discount for the duration of the beta period.

Looking forward for your feedback…

About two weeks ago I posted my spike results of porting NHProf to Linq to SQL, a few moments ago I posted screenshots of the code that is going to private beta.

I spent most of the last week working on the never-ending book, but that is a subject for a different post. Most of the time that I actually spent on the profiler wasn’t spent on integrating with Linq to SQL. To be frank, it took me two hours to do basic integration to Linq to SQL. That is quite impressive, considering that is from the point of view of someone who never did anything more serious with it than the hello world demo, and it was years ago. The Linq to SQL codebase is really nice.

Most of the time went into refactoring the profiler. I know that I am going to want to add additional OR/Ms (and other stuff) there, so I spent the time to make the OR/M into a concept in the profiler. That was a big change, but it was mostly mechanical. All the backend changes are done, and plugging in a new OR/M should take about two hours, I guess.

For Linq to SQL, however, the work is far from over, while we are now capable of intercepting, displaying and analyzing Linq to SQL output, the current Linq to SQL profiler, as you can see in the screen shots, is using the NHibernate Profiler skin, we need to adapt the skin to match Linq to SQL (different names, different options, etc).

That is the next major piece of work that we have left to do before we can call the idea of OR/Ms as a concept done, and release Linq to SQL as a public beta.

This is just to give you some ideas about what the new LinqToSql Profiler can do.

It can track statements and associate them to their data context, gives you properly formatted and highlighted SQL, including the parameters, in a way that you can just copy and execute in SQL Server:

The profiler can tell you when you are hitting the database too often.

All the usual reports, what methods caused what queries to be executed?

Reports about unique queries across the entire profiling session:

And overall usage reports: