A technical blog about asp.net and other geeky things. Follow me <a href="http://twitter.com/davidfowl/">http://twitter.com/davidfowl/</a>
My blog has moved to http://davidfowl.com/
We released SignalR 1.1 yesterday with a bunch of performance improvements and new features (detailed in the release notes). Among these new features, were improvements to the .NET client including the ability to set custom headers, client certificates and a custom JSON serializer. We also fixed a long standing issue people were experiencing in IE7 and IE8 with the loading bar showing up forever in the browser. However, most of this release focused on rewriting SignalR’s scaling out story from the ground up.
Yes, you read that right, Microsoft.AspNet.SignalR. It’s been a while since I last blogged as we’re super busy trying to make SignalR rock solid and 1.0 quality for you all to use. I’ve also given my first talk ever at Monkeyspace and then BUILD - both on SignalR. SignalR 1.0 alpha has been live for just over 2 weeks on NuGet, and a few seconds ago I just published alpha2. A lot has changed since 0.5.3 and there have been several people poking around trying to find out what’s changed and what’s new in the alpha. There’s also been lots of confusion about what to use, so I’m going to clear things up by enumerating the list of major changes.
Here comes another exciting release of SignalR. This release has some new features that you can take advantage of as well as a few bug fixes. Let’s go over the big changes for this release.
We made lots of breaking changes in 0.5 in order to gain more API consistency across the board. Some of the changes may not affect you if you weren’t doing anything with lower level APIs. These types of breaking changes will obviously slow down as we get closer to a 1.0 release.
This is the rebirth of my blog. I’ve been busy over the last few months with projects like JabbR, SignalR and other stuff. With the upcoming release of SignalR 0.5, I thought it’d be good to write a blog post that touches on some of the things we did.
I have neglected blogging recently because I’ve been super busy working on Razor tooling, NuGet and Beta 3 Release of the Web Stack. Now that I have some free time, I can blog about a really cool project I’ve been working on.
The Razor Debugger is a simple web based debugger for ASP.NET WebPages (it might work in MVC but hasn’t really be tested). It started off as an experiment to see if it was possible to have a simple debugging experience for developers using WebMatrix.
It’s a NuGet Package
Let’s step through a simple example on how to use the debugger with your site.
Start by opening WebMatrix and choose Site From Template. Create a new Empty Site and create a new cshtml page.
Next, we’re going to install the RazorDebugger through the admin UI. Launch the website and navigate to the _Admin url in your browser:
Type your secret password and continue to the Package Manager. List all packages from the online feed and install the RazorDebugger package:
After installing the debugger, navigate to the debugger page by going to ~/debugger.
The debugger is a section of the website that shows all of the pages on the left, and some UI on the right that we’ll describe in further details below.
To start debugging your site, put some code in the page and click on the page in the debug view.
Now that we have some code in our page we can set a break point by clicking on the gray pane beside the line numbers in source view. When a break point is set, a red circle will be placed on the line where the break point was set.
Start debugging! Click on Launch Page at the top of the page to run the page. Switch back to the debugger and see the break point being hit.
Now that we’re debugging, we can use the Step Into, Step Over, Step Out and Run buttons or the associated shortcut keys. Also, as you step, the locals, watches and stack trace UI at the bottom will change to show locals and watches respectively.
You can also change the values of locals by clicking on the value of the local and typing a new one.
Stepping into other pages
It’s possible to step into other pages if a call to RenderPage is made within the page you are debugging. I’ve updated the sample to contain 2 pages, Page.cshtml passes an anonymous type with the Name “David” to Page2.cshtml.
Now we can hit Step Into or i and step into Page2.cshtml.
The debugger also supports unhandled exceptions. The page below shows an example of a NullReferenceException. When an exception occurs the line is highlighted with a dotted border (it’s kind of hard to see) and the exception object shows up in the locals window.
This debugger is a prototype and isn’t meant to replace the debugger in visual studio by any means. It is however a pretty cool experiment and you can try it out today in your ASP.NET WebPages!
A while ago, Scott Gu blogged about a Dynamic LINQ library that was part of the C# samples in VS2008. This library let developers put together late bound LINQ queries using a special syntax. This really comes in handy when you want to build a LINQ query based on dynamic input. Consider the following example:
Before we look at the reasons for the existence of Microsoft.Data, we need some background on the WebMatrix initiative. Here are some excellent blog posts that describe the type of audience we are going after and the goals of the project: