.NET & Funky Fresh : NHProf, Silverlight

Porting NHProf from WPF to Silverlight – Day 8

Rob Eisenberg — Fri, 09 Apr 2010 20:19:00 GMT

Day eight* of the port and I was so happy not to discover any new issues. At this point I have almost all the major UI pieces in place. You can now see what you would normally during typical profiler usage. There’s still a lot of work to be done…probably much more than has been done so far. I still have a few big pieces such as query results and query plans. I also have to re-enable multi-selection of sessions and statements because the mechanism we were using in WPF isn’t going to work exactly the same for Silverlight. We’ve got to rebuild all our control templates and styles. None of those will port. I have to add context menus back in and hook up the help system too. There are a few other smaller things like that to look into. There are plenty of other issues to solve, but everything in its own time :)

*I’m not actually working full eight hour days on this project. I usually end up spending about 4-5 hours per day on average.

Porting NHProf from WPF to Silverlight – Day 7

Rob Eisenberg — Wed, 07 Apr 2010 02:21:00 GMT

Today I worked on statements. They flow pretty naturally out of the sessions functionality. I still have a lot of work ahead of me, so fortunately I only found two new issues today. I was able to rework Xaml in both cases fairly easily.

Binding in it’s Element form is not allowed. Fortunately, I was able to rework it as a markup extension.
ContentControl.ContentStringFormat is missing. I was able to use the StringFormat built into the BindingExtension instead.

Screenshot is below. Aside from the hideous styles…it’s actually starting to resemble itself.

Porting NHProf from WPF to Silverlight – Day 6

Rob Eisenberg — Mon, 05 Apr 2010 21:44:00 GMT

I started working on the most complicated part of the UI: Sessions. There are a lot of different view models and views related to this part. Fortunately, by now, I think I have found most of the issues. But I’m still encountering a few new issues here on day six. Below is the customary screenshot and issue list.

Styles don’t have Resources. We are probably going to have to re-write all of our styles and control template. So, our new solution will take this into account.
ControlTemplate cannot have triggers. See above.
ControlTemplate cannot have resources. See above.
Uri is missing PathAndQuery – I implemented this manually by combinding AbsoluteUri and QueryString with a ‘?’ in between.
MultiBinding is missing. We are going to do some major rework on that view unfortunately. I’ll try and provide more details later. Skipped it for now…
No ReaderWriterLockSlim. This was surprising. I really wasn’t sure what to do, so I used a standard lock for now.

Porting NHProf from WPF to Silverlight – Day 5

Rob Eisenberg — Fri, 02 Apr 2010 16:31:00 GMT

Well, I’m pleased to say that on Wednesday I only encountered one new* issue during the port. ListBox does not support grouping. One neat thing in WPF is that all the items controls supported grouping. One of the reports we had was a set of master/details grids where the master was a grouped ListBox. Needless to say, this entire report had to be redesigned to work around this issue. Truth be told, I never really liked the way that report was set up. As a solution I decided to use the Silverlight DataGrid with two levels of grouping. That issue aside, it was pretty quick work to port all the reports. As part of the process, I made the reports mechanism a little easier to maintain. Basically, anything that implements IReport will appear in the report list, will be added to the reports menu and will automatically have its view bound appropriately. Yay for IoC and Caliburn! Here’s a screenshot:

*Just as a reminder: When I say “new” issues I don’t want to insinuate that it is the “only” issue I encountered while working. I have encountered dozens of issues every day. But I am only recording here issues that I find that I haven’t previously encountered on this project. Trying to track every “instance” of an issue would be unmanageable.

Porting NHProf from WPF to Silverlight – Day 4

Rob Eisenberg — Thu, 01 Apr 2010 18:36:00 GMT

On Tuesday I spent a decent amount of time fleshing out the last remaining features under the Options menu. I then did some general reorganization to the project structure. Along with the port to Silverlight, I’ve been upgrading the application to use Caliburn 2.0 which is working out exceedingly well :) In fact, some of Caliburn’s features are making it very easy to work around the differences between the WPF and Silverlight platforms. After the reorganization, I decided I would start porting over the reports. As has been my pattern, below is a screenshot and the list of *new* issues I encountered. I’m really glad there weren’t as many as on Monday…

UpdateSourceTrigger=PropertyChanged is missing. There are workarounds which wire for events and manually update the bindings. I used Caliurn 2.0’s C over C binding to do this automatically :)
RelativeSource FindAncestor is missing. Fortunately, I replaced our homegrown grid with the Silverlight DataGrid and was able to eliminate the need for this in this scenario.
Hyperlink.Tag is is missing. Strange isn’t it. I reworked the code to use a HyperlinkButton.
Binding.StringFormat syntax is different. In WPF, you escape like this Text="{Binding AverageStatementsPerSession, StringFormat={}{0:0.#},FallbackValue=0}" but that causes a compile-time error in Silverlight. What is worse is that it doesn’t tell you where. It just complains that there is something wrong with a markup extensions somewhere in your Xaml. I fixed it with the following change Text="{Binding AverageStatementsPerSession, StringFormat=\{0:0.#\},FallbackValue=0}"
GridSplitter is missing ResizeBehavior and ResizeDirection. Fortunately, it seams to work pretty well without them. I have a couple of issues with this that I still need to look into though.

Porting NHProf from WPF to Silverlight - Day 3

Rob Eisenberg — Wed, 31 Mar 2010 13:58:00 GMT

On Monday I spent a good four hours working on the port. I decided to flesh out the functionality of the Main Menu. As I mentioned before, none of the menu controls available support commanding. Fortunately, Caliburn has its own mechanism which is much richer than what you get out of the box anyways. So, I began hooking this up, fleshing out the appropriate commands and implementing the various features of the application related to them. This approach actually brought me in touch with a very wide range of the application’s features. As a result, I ended up hitting a lot of issues. I calculated, that on average, I was hitting a *new* API issue (one I hadn’t seen previously on this project) every ten minutes for the entire four hour period. That was frustrating to say the least. Below is a (hideous) screenshot and a list of the issues I hit.

Style.Triggers are not supported. Ultimately this means we are going to have to refactor a lot of styles. Temporary fix to get things running was to comment out the triggers ;(
DataTrigger not supported either. We’ll probably end up refactoring to VSM. Unfortunately, many of our DataTriggers are in Styles…Fixing this is going to be interesting.
Custom Markup Extensions are still not supported in SL4, even after they completely re-wrote their Xaml parser from the ground up to support greater extensibility. My particular scenario was easy to work around by creating a custom IValueConverter. Another reasonable solution might be to create custom attached properties.
Lack of Command Support on Menu controls – This is not a problem with SL4 (except that it doesn’t have any menu controls), but is an issue with the current 3rd party controls. As I mentioned above, Caliburn made this easy enough to work around.
OpenFileDialog is missing CheckFileExists, Title, FileName and RestoreDirectory – We can work around all of this. The major consequence is that the user’s experience with the OpenFileDialog will be degraded.
Missing Timeline.DesiredFrameRate – Apparently you can’t control animation frame rate in Silverlight. I don’t think this will be a major issue.
The following simple storyboard scenario does not work. There’s seams to be a problem setting Storyboards with StaticResource. I used a bit of code-behind to start the animation. There’s probably a better way. Anyone have an idea?

SaveFileDialog missing Title and FileName – Again, this can be worked around. Mostly it involves a degraded user experience.
Process.Start is missing – There was talk of getting something like this into SL4. It would have been nice. We need it to open default apps for certain file types on the OS. We’ll either do without this or push it to our backend (which is not Silverlight).
Enum.GetValues is missing! I found this nice workaround: http://www.dolittle.com/blogs/einar/archive/2008/01/13/missing-enum-getvalues-when-doing-silverlight-for-instance.aspx
File.WriteAllText is internal. It would have been nice to have this, but we can work around it using Streams, etc.
Missing SystemParameters.PrimaryScreenHeight and SystemParameters.PrimaryScreenWidth. We’ll just have to do without…
Missing Serializable and BinaryFormatter. This is a real pain. Many people have asked for this since SL2, but the SL team hasn’t shown any interest in providing this. We are going to have re-write our user settings mechanism.
Missing Button.IsDefault and Button.IsCancel. This can be worked around. It means adding custom keyboard wire-ups for modal dialogs. Yuck.
No Label control – Now that we have ElementName binding why don’t we have a decent label control with Target and ActivatorKey? In the mean time I am using a TextBox. We’ll probably have to fix this with a custom control.
Bindings on DPs don’t default to TwoWay where appropriate. This is mostly an annoyance.
No ValueConversionAttribute to decorate value converters with. Not a big issue. But you need to remove it before you can compile.
Missing Visibility.Hidden. Again, not a big issue. But, you will need to rework code that uses this to use Opacity and IsHitTestVisible.
Missing DependencyPropertyKey. – We had a custom control that required this. We will have to re-write this control.
Missing FrameworkPropertyMetadata. – Same as above.
DependencyProperty is missing OverrideMetadata – Same as above.
TextBox is missing MinLines and MaxLines – We’ll manage without this by hardcoding height in pixels (yuck!)

Porting NHProf from WPF to Silverlight - Day 2

Rob Eisenberg — Mon, 29 Mar 2010 21:04:00 GMT

Friday I only had a few hours to work on the port. I thought I might look into what it would take to add the main menu. It’s an important part of the shell that I completely skipped in my first pass. Unfortunately, there aren’t really any free or open source menu controls that I could find which fit the bill exactly. I wanted to use VectorLight’s Menu, but I couldn’t get it to work in SL4. So, I ended up using the free DevExpress menu control. Unfortunately, I’m probably going to have to rip that out eventually because it doesn’t support shortcut keys. Neither of these controls support SL4’s ICommand interface. Thankfully, Caliburn has a better way to handle commands, so that didn’t set me back. When VectorLight’s control is fixed, I’ll probably end up switching to that, but I wanted to get something up and running in the mean time. I also started porting a few other parts of the shell, such as the header and chrome. This brought me to the second major shortcoming in Silverlight: No DynamicResource. I spent a good deal of time trying to figure out a workaround for that. I came up with something that I think will work for our purposes, but definitely isn’t generalizable. Lack of this functionality is a real problem in Silverlight. Below is a screen shot of the shell after day two. It’s not pretty and won’t be for a while, but I wanted to include it for historical purposes. After that you will find a list of a few other compatibility issues I encountered while working on the above two areas.

Issues from Day 2

The Control.MouseDoubleClick event is missing. Eventually, I will have to implement it manually, probably with an attached property.
TextBlock.Foreground and TextBlock.FontFamily are missing. It’s quite convenient to use these attached properties in WPF, but they simply don’t exist in Silverlight. Their absence causes a good deal of additional markup and sometimes “hacks” to get certain controls in certain parts of the visual tree to look right.
No *Connection, *Reader, etc. This is pretty obvious. But, I wanted to include it for completeness. I didn’t expect to deal with this, but it turns out the profiler’s front and backend are not as isolated as I thought they were. We’ll have to do some re-architecture in order to fix this.
There is no MainMenu control as I mentioned above. Currently, there’s a lack of good free or open source options for SL4. I’m expecting this to be improved upon shortly. Regardless, none of the controls available have an API that is compatible with WPF (especially if you used databinding or commands with your menu). So, if you are porting anything with menus, you are going to have to redo the whole thing.
Drawing Brush is missing. For that matter, drawings are missing…I’m not sure what we will replace this with just yet. Fortunately, it’s only used in one place in our application.
x:Array is missing. We originally uses this to store the alternating background color array for all our grids as a resource. But, since ItemControl doesn’t support that in Silverlight, we won’t be using this in the end.
No DynamicResource support, as mentioned above. For the profiler we have to load different color schemes based on which version you are using. I ended up creating an attached property to place on resource dictionaries, which allowed me to merge the dynamic color scheme in at the appropriate time during initialization. It seams to work so far. But, it’s not a generalizable solution, because you can’t change the “dynamic resources” on the fly. My solution only helps solve the issue of resource discoverability in complex scenarios, which is a common use for DynamicResource in WPF.

Porting NHProf from WPF to Silverlight – Day 1

Rob Eisenberg — Thu, 25 Mar 2010 20:33:00 GMT

This is a true story. It’s a story about porting a non-trivial WPF application, NHProf, to Silverlight 4. The story begins today with my first actual work on the porting process. Microsoft has been preaching how easy it is to move between these platforms. Are they telling the truth? I’ll (try to) let you be the judge. I’ve been a bit lax in my blogging lately, but I’m going to try and give a semi-regular account of my progress on this port along with the challenges I meet along the way. Perhaps I’ll be able to offer some meaningful workarounds that others can use; perhaps not. Maybe, dear reader, you can recommend some solutions to me.

Today I spent about 6 hours on the Silverlight version of NHProf. I basically did a File->New Project and began moving small pieces of the application shell over to Silverlight. The new application is not much to see at this point…most of the UI is missing entirely.

Below is a summary of the platform inconsistencies I came across in the first six hours of work:

Xmlns – Silverlight 4 allows assemblies to define custom Uri-based Xml namespaces. Unfortunately, Microsoft has done a rather poor job of using this feature themselves. The first issue I came up against today was related to this. It’s not a big problem, but rather an annoyance. The reason is that some controls are in different assmelbies/namespaces in Silverlight than in WPF. Take DockPanel, for example. It’s a core Panel in WPF, but not in Silverlight. Microsoft hasn’t patched up the namespaces for this, so if you port code using DockPanel, you have to go add custom xmlns everythwere. Yuck. This is true of everything in the Silverlight Toolkit. It would be really nice if they took everything in the SDK and everything in the Toolkit and just put them in the default namespace. Unfortunately, this one issue is probably going to prevent a direct reuse of any of our views.
TabControl – If you have seen the NHProf UI, It’s fairly obvious that we rely heavily on the TabControl. Unfortunately, the Silverlight TabControl is completely broken for data binding. Furthermore, it doesn’t have all the necessary template properties either. Basically, it’s completely different from the WPF version and completely unusable if you are using an MVVM architecture. My work around has been to use a horizontal ListBox for the “tabs” and a ContentControl for the “SelectedItem,” then rely on styling to make it look like a tab control. You can see this in the screenshot above (minus the styling of coarse).
ToolTip vs. ToolTipService – In WPF, every control has a ToolTip property; not so in Silverlight. You have to use an attached property called ToolTipService.ToolTip instead. Again, not a big problem, but it forces me to change every view.
Grid.IsSharedSizeScope and ColumnDefinition.SharedSizeGroup – Missing. There’s no way I know of to do a shared size scope layout in Silverlight. We used this quite a bit in the WPF version. Most of our “data grids” are actually list boxes with shared size scope layout. It was just simpler and more light weight. To solve this, I’m actually using the Sivlerlight DataGrid control. You can see it in the screen shot above displaying the Session Statistics. Ultimately, I think this will be an improvement to the UI. It just seams a bit heavy-weight considering that all of our grids are readonly. Suggestions?
ItemsControl.AlternationCount – Missing. This was primarily used in the style to generate alternating row colors. Since most of our ItemsControls/ListBoxes are going to be switched to DataGrid, this probably won’t be a big deal in the end. Still, I’d be interested in knowing what the proper way to do alternating row styles in Silverlight is.
TextTrimming="CharacterEllipsis" – Missing. We just have to go with WordEllipsis or roll our own ;(
DynamicResource – Missing. I’ve temporarily removed all the styles for the views I have ported. I’m really not sure what the ramifications of the missing DynamicResource will be in the end.
HeaderedContentControl Template uses a StackPanel – The HeaderedItemsControl’s template is built wrong…Period. It uses a StackPanel for layout and that prevents styling the control to expand properly. It should use a DockPanel. As I mentioned above, DockPanel is not in the core, which is probably why the HeaderedItemsControl is broken. Now, if they would just move the DockPanel….
ContextMenu – Missing. Silverlight offers mouse right-click support, but no ContextMenu out of the box. We are going to have to build this one from scratch.
DispatcherTimer(DispatcherPriority.Normal) – There’s no notion of DispatcherPriority in silverlight! So usage of the Dispatcher and DispatcherTimer can be quite different. Unfortunately, I won’t know the full effect of this until we start pushing lots of data through this thing…I don’t think it will be a problem. But, when it comes to SL vs. WPF, I’ve learned not to take anything for granted.
RegexOptions.Compiled – Missing. We’ll just have to do without that.
String.StartsWith - Missing overload for culture. Created an extension method as workaround.
StringBuilder - Missing overload to insert a character. Created an extension method as workaround.
DateTimeFormatInfo - Missing GetAllDateTimePatterns. Created an extension method as workaround. Faked the implementation…

Hmm. That’s a bit disconcerting for a mere six hours in. What’s interesting to note are the the differences in core APIs. I expected the graphics stack to have some inconsistencies, but I didn’t expect to hit BCL differences so quickly. I also expected to get a lot more of the shell done today. Looking at the screenshot above….I’m a bit embarrassed at the lack of progress. So far, porting WPF to Silverlight is slow going.