Alex Davies

A new toy - .NET Demon

Alex.Davies — Mon, 16 Jan 2012 16:17:00 GMT

I'd like to present a new tool for .NET Developers that we've been cooking up in the Red Gate .NET team. It's only a beta at the moment, but it works for most people.

.NET Demon Beta

It's a Visual Studio extension that cuts the time you spend waiting to find whether your code is right. It does this by:

Continuous testing (running your NUnit tests as you type)
Continuous compilation (so you can start running instantly because your code is already compiled)
Inline code coverage (so you know which tests are covering the code you're editing, and if they start failing)
Continuous save (so you don't have to press ctrl-S ever again)

Let me know what you think of it!

SmartAssembly Sync for JIRA

Alex.Davies — Thu, 12 May 2011 12:59:02 GMT

JIRA is a powerful bug tracking system, but it can't help you to actually collect error reports from your users. For that we've started using SmartAssembly (SA), but we quickly realised that there was no easy (or, more importantly, automatic) way to get error reports out of SA and into JIRA.

Automation is the Mother of Invention

David Simner, Ben Challenor and I got together in one of our regular Down-Tools weeks to see if we could do something to ease the pain of importing error reports into JIRA. SA had an SDK, and JIRA had a SOAP API, so we automated!

Given that we were all already users of both systems, we knew how we liked to handle bugs and error reports, and wanted to make sure we supported those processes. So, after 4 days of intensive coding and testing, SmartAssembly Sync for JIRA was born. We started using it in our own teams, and before long the rest of Red Gate were clamouring to have it set it for them as well.

The other teams really appreciated the way that duplicate bug reports are grouped together (letting them see how many people had hit specific issues). Combined with all the other information that our tool provided, and JIRA's powerful searching, prioritisation was a piece of cake.

What's going on under the hood?

What the tool actually does is fairly obvious if you know how JIRA and SA work - we just put all the pieces together. Without going into too much gory detail, here's the whole process that SmartAssembly Sync for JIRA runs through every 10 minutes on a scheduled task:

First, it makes SA download any new reports. Then it connects to your JIRA server, and downloads its configuration (which is stored as special "SA Project Link" issues in JIRA so anyone can configure it easily).

For each report it downloaded, it does the following:

a. It looks to see if the bug is already in JIRA.

b. If it isn't:

i. It opens a new JIRA issue;

ii. If the report is from some library code that is used by more than one product, it opens another JIRA issue in the JIRA project for the appropriate library, and links the two.

c. If the bug is already in JIRA:

i. It comments on the existing JIRA issue

ii. If the JIRA issue is marked as resolved or closed, and the report is from a later version, the issue is re-opened;

iii. It updates several fields in JIRA as necessary, such as the earliest version seen, latest version seen, report count, etc.;

iv. If all your systems are set up appropriately, it can send an auto-email to the customer who sent the report (assuming they gave an email address).

It then has some pretty excessive extra features. For example you can configure it so that if a report is from some shared library code, it'll open a second JIRA issue in the JIRA project for the library, and link the two.

Once you've got it working, the tool automatically categorizes reports that are probably the same bug (by the type and location of the exception) providing everything that's specific to the bug (i.e. stack trace, exception type) in the description. Then each report becomes a comment on the bug, including all the per-report information (i.e. build number, email address, etc.).

All in all, I think the tool is cool, and I know Ben and David do too. It's also some of the nicest code I've been involved in writing, which is lucky, because we've decided to open-source it :)

Making the most of your error reports

Anyone who uses SmartAssembly error reporting will benefit from this tool, as it will completely remove the need to manually import issues into JIRA, which is potentially a huge time-sink. Quite apart from the time-sink, most developers will probably find that tracking bugs in two different places also makes it easy to forget about the SmartAssembly reports, which is going to mean their software ends up lower quality, which is bad for everyone.

It'd be great if you could take SmartAssembly Sync for a spin, and let us know what you think :)

If your bug-tracking system isn't JIRA, SmartAssembly Sync is written very modularly, and it should be very easy to modify to work with any other bug-tracking system with a decent API. I'd really appreciate hearing from you if you try this, especially if you're willing to share your code!

You can find out more on the JIRA blog.

Exploring Windows Azure - is it more than just hosting?

Alex.Davies — Sun, 27 Mar 2011 14:52:00 GMT

Recently, I've been working on a side project in my spare time. It's a little facebook app to help you remember how much money you owe your friends:

Visit my app: ToTuP

Since the cloud seems so fashionable at the moment I thought I'd give Microsoft's Azure infrastructure a bit of a test, by running my app on it. Of course, I'm very keep to have the easy management and scalability that a cloudy system offers, but is it extra effort, and is that effort worth it?

I've previously tried Google's App Engine, and I assumed that Azure would be much the same, but in a lot of ways it's more like Amazon EC2, which just gives you full access to virtual machines.

While Azure shares App Engine's easy deployment with IDE integration, that's more or less where the similarity stops:

Whereas App Engine just promises that there will be some computers somewhere running your web service, Azure asks you to specify how many instances to create, and which continent they should be on
App Engine's pricing model charges you for the CPU cycles that you use, but Azure charges you for the virtual machines that you have running, even if they're idle
The important downside of App Engine, that allows it to run in this way, is that you are heavily restricted in what features of the JVM you are allowed to use. While this should be fine for new apps, it gets in the way of porting existing apps to the cloud, and I found that the MVC framework I was using made use of the disallowed features. Azure on the other hand makes no restrictions. While the IDE deploy is designed for .NET apps, I'm led to believe that you can run pretty much anything on Azure instances.

A big problem for cloud services is the developer's need to debug problems that happen in the cloud environment that weren't present in development. Azure provides a "local app fabric" to mitigate this, but I found it no more likely to find bugs than just running in local IIS. Luckily, Microsoft (probably grudginly) recognised this, and enabled remote desktop access to the virtual machines. Now I can do whatever I need actually on the cloud machine (including running ANTS Performance Profiler after making a small fix to it which you can get from Red Gate Support if you need).

So, in summary, I'm a bit disappointed that the technology isn't as cool as Google's, which means that I have to pay for virtual machines that are doing nothing most of the time. But in exchange, I have the ability to debug in my hosting environment in a way that just doesn't make sense in App Engine. A tough call, and the only reason I know I'd use Azure again is that I like C# a lot more than java :)

Automated testing in Silverlight with Statlight

Alex.Davies — Tue, 21 Sep 2010 12:24:00 GMT

I really like automated testing. Not just on any kind of religious basis, it just saves loads of time. I think it's best when the tests run automatically on or after each build.

So I was disappointed to find that there isn't a way provided with the Silverlight framework to run tests for Silverlight applications. Silverlight is different enough to normal .NET that you can't just use NUnit or similar, and run the tests on the desktop CLR. There are a couple of unit testing frameworks, but you have to invoke them from inside a browser. No running on the command line for my automated builds.

After some digging I found this little-known app called Statlight, which exactly fills the gap:

http://statlight.codeplex.com/

You pass it the location of a .xap file on the command line, and it will run any tests it finds within (MSBuild and NUnit's Silverlight flavours, among others, are supported).

The only trouble is that it has to open a dummy browser window in which to host the Silverlight runtime. The window is hidden, but you can't run the tests as a service which doesn't have permission to display user interfaces. There's no easy way of getting around this (when you want to run the tests under a domain account) so I ended up running my copy of CruiseControl.NET via the "Startup" folder in the start menu, and using automatic logon to get it up and running automatically after a reboot. Icky.

Automated Error Reporting in .NET Reflector - harnessing the most powerful test rig in existence

Alex.Davies — Thu, 17 Jun 2010 17:23:00 GMT

I know a testing system that will find more bugs than all the unit testing, integration testing, and QA you could possibly do. And the chances are you're not using it.

It's called your users.

It's a cliché that you should test so that you find your bugs rather than your users. Of course you should. But it's also a cliché that no software is ever shipped bug-free. Lost cause? No, opportunity!

I think .NET Reflector 6 is pretty stable. In fact I know exactly how stable it is, because some (surprisingly high) proportion of its users tell me every time it crashes:

If they press "Send Error Report", I get:

And then I fix it. As a rough guess, while a standard stack trace is enough to fix a problem 30% of the time, having all those local variables in the stack trace means I can fix it about 80% of the time.

How does this all happen? Did it take ages to code this swish system? Nope, it was one checkbox in SmartAssembly. It adds some clever code to your assembly to capture local variables every time an exception is thrown, and to ask your user to report it to you, with a variety of other useful information.

Of course not all bugs show up as exceptions. But if you get used to knowing that SmartAssembly will tell you when an exception happens, you begin to change your coding style. Now, as long as an exception gets thrown in any situation you don't expect, you'll fix it if it ever happens. You'll start throwing exceptions liberally, and stop having to think about whether tiny edge cases are possible, as long as they throw an exception if they happen.

You can try this out for yourself by downloading the free trial of SmartAssembly.

Why lock statements don't scale

Alex.Davies — Mon, 03 May 2010 13:32:15 GMT

We are going to have to stop using lock statements one day. Just like we had to stop using goto statements. The problem is similar, they're pretty easy to follow in small programs, but code with locks isn't composable. That means that small pieces of program that work in isolation can't necessarily be put together and work together.

Of course actors scale fine :)

Why lock statements don't scale as software gets bigger

Deadlocks.

You have a program with lots of threads picking up lots of locks. You already know that if two of your threads both try to pick up a lock that the other already has, they will deadlock. Your program will come to a grinding halt, and there will be fire and brimstone.

"Easy!" you say, "Just make sure all the threads pick up the locks in the same order." Yes, that works. But you've broken composability. Now, to add a new lock to your code, you have to consider all the other locks already in your code and check that they are taken in the right order. Algorithm buffs will have noticed this approach means it takes quadratic time to write a program. That's bad.

Why lock statements don't scale as hardware gets bigger

Memory bus contention

There's another headache, one that most programmers don't usually need to think about, but is going to bite us in a big way in a few years. Locking needs exclusive use of the entire system's memory bus while taking out the lock. That's not too bad for a single or dual-core system, but already for quad-core systems it's a pretty large overhead. Have a look at this blog about the .NET 4 ThreadPool for some numbers and a weird analogy (see the author's comment). Not too bad yet, but I'm scared my 1000 core machine of the future is going to go slower than my machine today!

I don't know the answer to this problem yet. Maybe some kind of per-core work queue system with hierarchical work stealing. Definitely hardware support.

But what I do know is that using locks specifically prevents any solution to this. We should be abstracting our code away from the details of locks as soon as possible, so we can swap in whatever solution arrives when it does.

NAct uses locks at the moment. But my advice is that you code using actors (which do scale well as software gets bigger). And when there's a better way of implementing actors that'll scale well as hardware gets bigger, only NAct needs to work out how to use it, and your program will go fast on it's own.

A better way to do concurrent programming

Alex.Davies — Sun, 18 Apr 2010 11:27:00 GMT

Programming to take advantage of multicore processors is hard. If you let multiple threads access the same memory, bad things happen. To avoid this, you use the lock keyword, but if you use that in the wrong way, your code deadlocks. It's all a nightmare.

Luckily, there's a better way - Actors. They're really easy to think about. They're really safe (if you follow a couple of simple rules).

And high-performance, type-safe actors are now available for .NET by using this open-source library:

http://code.google.com/p/n-act/

Have a look at the site for details. I'll blog with more reasons to use actors and tips and tricks to get the best parallelism from them soon.

What do you call an obfuscator that isn't an obfuscator?

Alex.Davies — Thu, 15 Apr 2010 11:22:04 GMT

SmartAssembly, formerly {smartassembly}, version 5 is now available as an Early Access Build. You can get it here:
http://www.red-gate.com/MessageBoard/viewforum.php?f=116

We're having second thoughts about the name change though. It isn't that we like the curly brackets, far from it. The trouble is that the first rule of product naming is to name a product by what it does. SmartAssembly may make an assembly smarter, but that's not something people really google for.

The trouble is, I can't think of a better name for it.

That's because SmartAssembly really does two completely separate things:

Obfuscates
Sets up your assembly for the awesome exception reports which get sent to you whenever your application crashes. You may have been (un?)lucky enough to see one in reflector if you use it.

This is what those exception reports look like when they arrive back with the developer:

Look at all those local variables! If you ask me, this is much cooler than the obfuscation.

So obviously we don't want to call it just "Red Gate Obfuscator" or something, because it doesn't do justice to the exception reporting.

What would you call it?

Why not to use StackTrace to find what method called you

Alex.Davies — Thu, 18 Feb 2010 12:52:00 GMT

Our obfuscator, SmartAssembly, does some pretty crazy reflection. It's an obfuscator, it's sort of its job to do things in the most awkward way possible.

But sometimes, you can go too far. One such time is this little gem from the strings encoding feature:

StackTrace stackTrace = new StackTrace();
StackFrame frame = stackTrace.GetFrame(1);
Type ownerType = frame.GetMethod().DeclaringType;

It's designed to find the type where the calling method is defined.

A user found that strings encoding occasionally broke on x64 systems. Very strange. After some debugging (thank god for Reflector Pro, it would be impossible to debug processed assemblies without it) I found that the ownerType I got back was wrong.

The reason is that the x64 JIT does tail call optimisation. This saves space on the stack, and speeds things up, by throwing away a method's stack frame if the last thing that it calls is the only thing returned. When this happens, the call to StackTrace faithfully tells you that the calling method is the one that called the one we really wanted.

So using StackTrace isn't safe for anything other than debugging, and it will make your code fail in unpredictable ways. Don't use it!

Reflector Pro moves into beta!

Alex.Davies — Wed, 20 Jan 2010 11:30:00 GMT

Reflector Pro's builds are getting pretty stable now. So we've decided to call this one a beta! Download it now from http://www.red-gate.com/products/reflector/downloadbeta.htm.

There are two components to this project really, and we're hoping you'll like both of them:

.NET Reflector Visual Studio add-in
.NET Reflector 6

The new Visual Studio add-in

We've written a Visual Studio add-in that will install when you run Reflector. It has two main features:

Letting you jump to Reflector from your code (this is free!)
Debugging decompiled code using the visual studio debugger (this is Reflector Pro - so will cost money)

Here's what it'll look like to jump to Reflector from VS:

Click it and Reflector fires up, showing you Math.Pow. Simple as that. Saves me a good amount of time opening Reflector and searching for things (not to mention forgetting why I wanted to see it on the way!)

The debugging feature (Reflector Pro) is what we're most excited about (ok, so it's what we hope will pay for us to eat, but it is very cool too). It can decompile a whole assembly, and generate debug symbols for it. From there, you can see the decompiled code in Visual Studio, and all VS's normal debugging features spring to life. You can step in, set breakpoints, inspect and modify variables, and even use VS2010's new IntelliTrace feature to time-travel through your debugging session.

Pretty cool, no? This is the kind of leap (like Reflector was) which I dread to think how much time I could have saved if I'd had it in previous projects. Nowadays, I never have to just stare at a bug and guess what's wrong anymore: I just decompile and jump in to take a look.

What's new in .NET Reflector 6

We've spent a lot of time tweaking and improving Reflector itself as well.

There are lots of things that successfully decompile now that didn't before.
.NET 4.0 is now supported (although that doesn't include decompiling to C# 4.0 language features, all the .NET 4 assemblies can be browsed).
The Open Cache dialog now shows you all the assemblies in .NET's Global Assembly Cache (GAC).
We've tidied up some graphics (including some really nice new icons).
Lots of the little annoyances with the user interaction are solved too.

So grab grab yourself a copy. This is our last chance to make any last minute changes, so please post on the forum with any suggestions or bugs you find.

Remote Debugging with Reflector Pro - It could have been so easy!

Alex.Davies — Tue, 05 Jan 2010 17:38:00 GMT

.. but it isn't :(

Visual Studio's remote debugger is a really neat bit of kit that lets people with a lot of patience and no firewalls debug processes on a test machine using a visual studio instance on a completely separate development machine.

Obviously it would be great if you could combine this ability with Reflector Pro to decompile and debug any .NET assembly running on any machine. It is possible, but it's not automatic, much to my annoyance.

The problem is that the .NET remote debugging system loads its .pdb files from the test machine, rather than from the machine running VS. (I found this with the help of John Robbins' blog post).

Reflector Pro generates .pdb files on your development machine. VS knows where to find them, but it chooses to ignore them (in fact, worse, you can watch it looking on the test machine for them in paths that only exist on the dev machine).

The workaround is to copy the .pdb files from Reflector Pro's debug store (which are located in your user's local application data in \Red Gate\.NET Reflector 6\Cache) and put them on the test machine, next to the running assemblies. The remote debugger will find them and everything will spring to life, showing you the decompiled code on the dev machine (which you don't have to copy anywhere).

Hope that helps some people!

Debugging your interaction with other people's code - Reflector Pro is in EAP!

Alex.Davies — Tue, 22 Sep 2009 08:25:00 GMT

If you're read Bart or Clive's blog recently, you might be as excited as I am about the next version of Reflector that we're working on.

.NET Reflector is great for working out what on earth is going on in the framework or third party code you work with every day. But when you're right in the middle of debugging and your method call does something you don't expect, you just want to step into the world below and work out why.

Well now you can! An Early Access Program of Reflector Pro is available from our forums.

It's a bit rough around the edges, but we like fast release iterations, so you can expect it to improve rapidly.

Here is where you choose which assemblies to debug:

Once you've decompiled an assembly, you can press "Step into" (F11) on any line that calls into your decompiled assembly, and you'll be in the decompiled code, watching the variables change. Awesome!

Are you interested in helping test the usability of the new feature? We are looking for people with issues which Reflector debugging could help with. Email usability at red-gate.com if you'd like to help, and please don't try out the tool beforehand, so we can see your first reactions.

Just have to come clean that the debugging feature won't be available in the free edition of Reflector - but we will of course keep the free edition, and make improvements to it that we need for Reflector Pro (so everyone wins). We've been improving .NET 4 support, for example.

Decompile everywhere!

Alex.Davies — Tue, 01 Sep 2009 10:12:00 GMT

Everyone knows that .NET Reflector is magic. It makes C# or VB code where there was no code before. Quite cool, I'm sure you agree.

But when you have the source code to .NET Reflector, and products that need new features, you can really have some fun!

For Exception Hunter 2 we were really focussing on helping users to interpret the situations where an exception might be thrown. So we put in a source code view to show you your source, and where it throws exceptions:

But a lot of the time, the exceptions are thrown by library methods, and have no source code. That's where .NET Reflector comes in, of course. We've integrated Reflector's decompilation capability into Exception Hunter, so when you drill into a stack trace and arrive at a library method, you get decompiled code to help work out what's going on:

Awesome!

I can't promise anything, but at some point we might able to get some deep (line-level timing?) insight into how libraries perform as well!

Learning by doing - an experimental memory profiling tutorial

Alex.Davies — Thu, 25 Jun 2009 09:22:00 GMT

Through the development of ANTS Memory Profiler 5, we realised that the most serious barrier to customers wanting to buy memory profilers was how complex and hard-to-understand memory profiling is.

It happened that, for other reasons, I'd architected the memory profiler UI as a reusable component. Halfway though the project, I had the idea to use it to throw together a game-style tutorial mode for the memory profiler, to lead people though some common workflows in a mocked-up memory profiler UI.

Brian got wind of this, and showed me his article about how we should learn from video game designers, and lead people gradually though the new world of memory. Unfortuntately, I can't control the customer's own application to cause it to have simple kinds of memory leak to start with!

Still, I believe the principle that you learn best by doing, and I want to test it. So now the project is over, I have enough time to manually engineer some of these tutorials, and see if anyone finds them useful.

You can find them at the labs wiki. Give them a go, let me know what you think of the idea.

Why I don't care where my objects are created

Alex.Davies — Thu, 07 May 2009 09:25:00 GMT

Back when we were designing the new memory profiler last year, Andrew had realised that there was one thing that made all the exisiting memory profilers slow the profiled application to a crawl. That was remembering the place in the program (the call stack) that every object gets allocated. We've decided to take this feature out, not even including it as an option for v5.0, and here's why.

Once upon a time, there were programming languages where you had to free all the memory that you allocated. If you didn't, the memory would be lost forever, the traditional unmanaged code memory leak. So people thought of clever ways to make their code less prone to memory leaks. One of these was a principle that whichever piece of code allocated memory was also responsible to making sure it is freed when you're finished with it.

This wasn't a bad principle, and many good programs were written leak free because of it. Some programs got leaks though, so someone invented memory profilers. These were good because they would tell you where you had allocated the pieces of memory that weren't freed. You could then fix the problem because it was always the code that allocated the memory that was responsible for freeing it.

Then one day (ok, so excuse my chronology, it's been around for ages) someone invented garbage collection. Joy! We no longer had to worry about freeing memory, it was freed on its own when not referenced anymore. The old technique of copying data that needed to be passed became obselete, we could send our memory off into the distance, not knowing what adventures might be waiting for it.

But sometimes the data had misadventures. It might get referenced by something it shouldn't do, end up in the wrong cache, and the managed memory leak was born. So managed memory profilers appeared. They were good because they told you where your memory was allocated, because it's always the job of the code that allocates the memory to free... oh, wait, no it's not!

The code that allocates memory has no responsibility over what happens to the memory, and usually has nothing to do with the code that leaks it.

So I think we've made a brave step, removing this age-old feature. Because it's not actually useful.

Instead, what's useful is knowing why your object is in memory still, and that's all about what's referencing it. In particular how it's connected to GC roots. So that's what we've tried to make the memory profiler v5 good for investigating (and I think if you try it you'll agree, we succeeded). Also, it's a gazillion times faster because it doesn't have to hook into every object allocation.

The only trouble is, on rare occasions, allocation call stacks are useful. There is a (frankly horrible) system in .NET called the IDisposable pattern. It asks you to free (call Dispose() on) objects you've allocated. It's necessary because .NET is built on top of the unmanaged world, where it's important not to wait for the garbage collector before a resource is freed. I hate it, because it chains us back up to the technique of the piece of code that allocates an object having to dispose it. Maybe here allocation call stacks might be useful again. But because of finalizers, people are very rarely actually bitten when they forget to dispose things. Hopefully one day, everything will be designed so it can wait for the garbage collector before it gets freed, and the world will be a happier place.