The next episode of Becoming a Jedi is now live and covers code cleanup. Specifically I look at quick fixes, context actions, safe delete, and reformat code. You can find it here:
Streaming: Becoming a Jedi – Part 2: Code Cleanup (requires Silverlight 1.0 or higher)*
Download: Becoming a Jedi – Part 2: Code Cleanup (via Live SkyDrive)
Enjoy!
…a ReSharper Jedi, that is. I am making no claims about my own ReSharper Jedi abilities. JP and Oren are known ReSharper Jedi Masters. I feel more like Luke Skywalker when he first landed on Dagobah in comparison. Back to the point of this post…
Many developers don’t see the value of JetBrains’ ReSharper until they’ve seen it in action. So I’m putting together this screencast series to show off my favourite ReSharper features. My goal is to keep each screencast to 5 to 10 minutes and focus on a related set of capabilities. In the first episode, I look at ReSharper’s Code Browsing – CTRL-N, CTRL-B, CTRL-ALT-B, ALT-F7, and related.
Streaming: Becoming a Jedi – Part 1: Code Browsing (requires Silverlight 1.0 or higher)*
Download: Becoming a Jedi – Part 1: Code Browsing (via Live SkyDrive)
Before someone makes a snarky comment about my coding speed, I’m intentionally taking the time to explain the features. That and I’m not as adept as some at coding and talking at the same time. Hopefully I’ll improve with practice as this screencast series progresses. Any constructive feedback on the content or presentation style is appreciated. Enjoy!
* I am encoding the series using Silverlight 1.0 for two reasons:
This morning I was getting ready to record a screencast about ReSharper 4 EAP. To make it easier for people to follow along, I launched Roy Osherove’s excellent utility, Keyboard Jedi. Rather than the expected result, this friendly dialog box greeted me:
![image_thumb[2]](/wp-content/uploads/WindowsLiveWriter/KeyboardJedionVistax64_98A8/image_thumb%5B2%5D_4.png)
My main development machine is running Vista x64. I’ve used KeyJedi frequently on my Vista x86 laptop and never had a problem. So I immediately suspected a 64-bit compatibility issue. KeyJedi is a .NET 2.0 application, which means that it will execute on the 64-bit CLR if available. (The 64-bit CLR was introduced with .NET 2.0. You don’t have to do anything special. If you install .NET 2.0 or higher on 64-bit Windows, the 64-bit CLR is installed automatically.) The 64-bit CLR uses a 64-bit JIT compiler, which produces x64 (or IA64)* machine code. This is why things like Paint.NET’s Gaussian Blur, which involves a lot of 64-bit arithmetic, run faster on 64-bit Windows. The MSIL is identical, but on 64-bit platforms, the JIT produces 64-bit optimized code. For example, a 64-bit ADD can be done in a single instruction on 64-bit hardware, but requires multiple instructions on 32-bit. (N.B. If you’re running 32-bit Windows on 64-bit hardware, there is no way to access the 64-bit capabilities of the chip as the OS thinks it’s running on a 32-bit chip.)
* x64 is the 64-bit enhanced, x86-compatible instruction set introduced by AMD. IA64 is used by Intel’s Itanium processors and is incompatible with x86. So you have to recompile the world to use IA64. Once Intel realized that not everyone on the planet was willing to recompile their programs, they introduced EMT64 for the Pentiums and Core chips. EMT64 is functionally identical to x64 from AMD.
So on Vista x64, KeyJedi is running on the 64-bit CLR. But that doesn’t explain why it fails. Most programs, like Paint.NET, just work. What is KeyJedi doing that is special and incompatible with 64-bit Windows? It is registering global system hooks to capture keyboard and mouse messages. Registering hooks and receiving messages involves Win32 calls, which are handled by Michael Kennedy’s Global System Hooks in .NET library. This library includes both managed (Kennedy.ManagedHooks.dll) and unmanaged (SystemHookCore.dll) code. SystemHookCore.dll makes 32-bit Win32 calls and receives 32-bit callbacks. You cannot make 32-bit Win32 calls directly to the 64-bit Windows kernel. You need a translation layer, which is the Windows-on-Windows or WoW layer.
The WoW layer marshals 32-bit Win32 calls to and from their 64-bit equivalent, translating data structures on the way in and out. This marvelous piece of magic is built into 64-bit Windows and allows most 32-bit programs to execute on 64-bit Windows without problem. The WoW layer sits below all 32-bit processes happily marshalling system calls back and forth. If you’re running in a 64-bit process, such as the 64-bit CLR host, there is no WoW layer beneath you. So you cannot load 32-bit DLL, such as SystemHookCore.dll. (This is also why 32-bit kernel-mode drivers don’t work on 64-bit Windows. There is no WoW layer in the kernel. It exists between user and kernel mode.)
Now we know the problem. The question is how to fix it. We could create a 64-bit version of SystemHookCore.dll, but that would involve a lot of spelunking and debugging of unmanaged C++ code. Not exactly how I want to spend my morning. The other option is to force KeyJedi to run on the 32-bit CLR even on 64-bit Windows. Then we would have the WoW layer beneath us and SystemHookCore.dll could merrily assume that it is running on 32-bit Windows while the WoW layer takes care of all the 32-bit to 64-bit Win32 marshalling. So how do we force a managed application to run on the 32-bit CLR…
The easiest technique is to modify your project settings in Visual Studio. Just go to Project Properties… Build… Platform target and change it from Any CPU to x86.
![image_thumb[9]](/wp-content/uploads/WindowsLiveWriter/KeyboardJedionVistax64_98A8/image_thumb%5B9%5D_4.png)
Now you might think, “Wait a second. I’m compiling to MSIL, which is processor independent.” Yes, you are, but when you select Any CPU (the default), your program will load on the 64-bit CLR if available. By selecting x86, you are forcing the program to run on the 32-bit CLR. Then just recompile your program and problem solved. Just one problem… Roy never released the source. (Yes, I’ve emailed Roy and asked him to do recompile with x86 as the target platform.)
We don’t want to modify the application, just ask it to run on the 32-bit CLR. Turns out that the project settings above just twiddle the CORFLAGS inside the PE file header of the executable. The .NET Framework SDK ships with a program called corflags.exe for just this purpose:
![image_thumb[12]](/wp-content/uploads/WindowsLiveWriter/KeyboardJedionVistax64_98A8/image_thumb%5B12%5D_4.png)
You’ll notice that 32BIT has a value of 0, which means Any CPU. We want to twiddle this to 1. One little problem. The assembly is signed. Twiddling even a single bit will invalidate the signature and the CLR loader will prevent the application from loading. If the assembly weren’t signed, you could just execute:
corflags KeyJedi.exe /32BIT+
Time to bring out the big guns. We’re going to disassemble KeyJedi.exe into MSIL. Hold onto your hats…
ildasm /all KeyJedi.exe /out=KeyJedi.il
This produces three files:
KeyJedi.il
KeyJedi.res
Osherove.KeyJedi.MainForm.resources
Time to hack some MSIL… Open KeyJedi.il in your text editor of choice and search for “.corflags”. Change the line to:
.corflags 0x0000000b // ILONLY 32BITREQUIRED
We can’t compile the code yet because we don’t have the private key that matches the public key embedded in the MSIL. Search for .publickey and delete it. (You could change it to your own public key generated with sn -k, but there’s no reason that we need to sign the assembly.) Now we can re-compile the MSIL using ilasm:
ilasm /res:KeyJedi.res KeyJedi.il /output:KeyJedi-x86.exe
If we execute KeyJedi-x86.exe, we get:
![image_thumb[14]](/wp-content/uploads/WindowsLiveWriter/KeyboardJedionVistax64_98A8/image_thumb%5B14%5D_4.png)
Success!!! KeyJedi is now running on Vista x64.
I’m not going to redistribute the recompiled binary because KeyJedi is Roy’s baby and the fix is really straightforward for him to make. Look to his blog for an update. My main purpose was to help people better understand 64-bit compatibility issues and some tricks that 64-bit Windows does so that, in most cases, you aren’t forced to recompile the world to run the programs you’ve come to depend on.
As promised, Microsoft has made the source for the .NET Framework available for debugging purposes. You’ll need to be running Visual Studio 2008 and install this QFE (aka patch). Full instructions for how to enable .NET Framework source debugging can be found on Shawn Burke’s blog here. You can also read Scott Guthrie’s announcement here.
As luck would have it, I couldn’t get this working initially. There was no “Load Symbols” in the right-click menu of the call stack. (“Load Symbols” should appear right above “Symbol Load Information…”)
Double-clicking in my call stack on any frames in the .NET Framework:
resulted in:
After some quick investigation and reading through Shawn’s troubleshooting section at the bottom of his post, I realized that the _NT_SYMBOL_PATH environment variable was overriding the settings in Visual Studio. (I had set up _NT_SYMBOL_PATH to the Microsoft Symbol Server for WinDbg.) The problem is that the symbols provided by the Microsoft Symbol Server have their source information stripped out.
To solve this problem, you have two options.
Regardless of which option you choose, first close all instances of Visual Studio 2008 and delete all the files in your local symbol cache. Visual Studio has no way of knowing which version of the symbols you have. So if you already have System.Web.pdb downloaded from the Microsoft Symbol Server – the PDB file without source information – you won’t be able to debug into System.Web.
To add/modify the environment variable:
Maybe I’m just dense, but it took me awhile to figure out the syntax for _NT_SYMBOL_PATH. Note that you have to separate symbol servers via a semi-colon. Specifying SRV*LocalCache*Server1*Server2 fails miserably. Symbols don’t download and no errors are shown. The four-part syntax is valid, but meant for caching symbols on your network for all developers to share. Local cache is on each developer’s box, Server1 is a fileshare on your network with read-write access for all developers, and Server2 is the actual public symbol server. If you specify a public symbol server as Server1 in the four-part format, symbol loading just fails silently. Use the semi-colon separated syntax noted above to specify multiple public symbol servers and everything works as expected.
The local symbol cache can be the same for all public symbol servers. It can be anywhere that you have read/write access, such as c:\symbols, c:\users\james\symbols, or – my preferred location – c:\dev\symbols.
You should be sure that the Reference Source Symbol Server is before the Microsoft Symbol Server. The order of symbol servers is the order of search. If your debugger doesn’t find the correct PDB file in the local symbol cache, it will check the first symbol server. If the first symbol server doesn’t have the appropriate PDB file, it will proceed to the second. So if you have the Microsoft Symbol Server first, you’ll be downloading the PDB files without source information.
Which brings me to my last point. Right now, source has been released for:
LINQ, WCF, Workflow, and others will be following in the coming months, according to Scott Guthrie. So if I debug WCF today, I’ll download symbols from the Microsoft Symbol Server without source information since the Reference Source Symbol Server won’t have the PDB files. When the PDB files are released, I won’t be able to debug the source until I delete the old PDB files without source information and force a re-download. You can do this by deleting the appropriate folder in your local symbol cache – in this case, the c:\dev\symbols\System.ServiceModel.pdb folder – or you can just delete the entire contents of your local symbol cache and re-download everything. If you’re not able to view source on something that you know is available, the easiest solution is to just clear out your local cache and let Visual Studio download the symbols again from the correct location. Downloading symbols over a broadband connection doesn’t take that long and is a lot faster than trying to troubleshoot which PDB files are causing you problems.
Happy Debugging!!!
To be honest, I usually ignore the Toolbox column in MSDN Magazine. Usually it features various vendors’ offerings around .NET. The December 2007 issue is typical in that it features .netLIVEHELP ($395), Instant C#/VB ($179), and UltraMon ($39.95). November 2007 featured Spread for Windows Forms ($899), Peter’s Date Package ($90), and WinMerge (free). Previous issues are similar. I’m not commenting about the quality of the software, but more about the focus on commercial offerings.
Today I received the January 2008 issue in the mail (it’s not yet online) and flipped it open. The word “mocking” in the Toolbox column caught my eye and I thought, yet another advertisement for TypeMock. Then I did a double-take. Toolbox was featuring Rhino Mocks by Oren Eini (aka Ayende Rahien). The other features were MbUnit (free), JetBrains’ dotTrace ($499), and Continuous Integration: Improving Software Quality and Reducing Risk. Both Rhino Mocks and MbUnit are open source tools. Although dotTrace is a commercial tool, it’s the best profiling tool that I’ve ever used – and I’ve tried a lot of them!* If you watched my MSDN webcast on tools, you’ll notice that I highly recommend all three tools. I hope that Toolbox’s new author, James Avery, keeps up the excellent work and continues to feature great open source frameworks alongside commercial offerings! Times, they are a-changing. Good open source software is starting to get the respect and recognition it deserves.
* To be honest, I’ve heard excellent things about Red Gate’s ANTS Profiler, but haven’t had a chance to try it and compare.
Thanks to everyone who attended my Ignite Your Coding webcast. I enjoyed sharing a small sampling of the wealth of tools available for the Windows and .NET developer. For those of you who missed the webcast (or would like to watch it again), it’s available on-demand here.
Below you will find a list of links that I mentioned during the webcast as well as a few attendee-contributed suggestions:
Resources
Community-Contributed Resources (During the Webcast)
Be sure to check out the rest of the Ignite Your Coding webcast series as there are some other great sessions there.
MSDN Canada is presenting a weekly webcast series called Ignite Your Coding starting Tuesday, November 6, 2007. I will be presenting the second webcast in the series on Tuesday, November 13, 2007 from :
Frameworks and Tools for the Windows Developer
Numerous frameworks and tools exist to help developers be more productive when building applications on Windows. In this session, you’ll discover some indispensable tools that will enable you to be a more effective developer of Windows. Expand your toolset by learning what’s available today!
Here is the full line-up of webcasts. Further details and registration for the other webcasts can be found on the Ignite Your Coding website.
| November 6 | Understanding the Windows – Based Development Platform |
| November 13 | Frameworks and Tools for the Windows Developer |
| November 20 | Security Essentials for Windows |
| November 27 | The Art of Debugging in Windows |
| December 4 | Application Deployment on Windows |
| December 11 | Developing as a Non-Admin |
Here are the code samples from some recent presentations…
Alberta Architect Forum 2007 – Creating Flexible Software
Austin .NET User Group – The NHibernate Mafia and the Persistent Ignorant Domain Model
Edmonton Code Camp 2007 – Building Applications Using ALT.NET
Thanks to everyone for attending the sessions, asking questions, and providing feedback.
The Virtual PC download of Visual Studio 2008 “Orcas” has been great. No install. No chance of corrupting your current Visual Studio 2005 install. It just works and allows you to play with the early bits in a virtual environment. That’s one of the things that virtualized environments excel at. The Virtual PC images were timebombed to prevent their use in perpetuity. Now for the bad news… Microsoft originally announced that the timebomb date was March 15, 2008. In actual fact, it is November 1, 2007. After that, you’ve got a few options as detailed on Jeff Beehler’s blog post:
None of these situations is ideal, especially for those without MSDN Subscriptions. Hopefully we’ll get the next Visual Studio 2008 beta in the near future.
I’ve been getting a lot of questions regarding VstsUnit for ReSharper 3.0. I’ve got good news and bad news.
First the bad news… I’ve been working on it off and on, though it’s offering some significant challenges. The object model is completely different and tests are executed in a dedicated test runner that ReSharper spins up. So test exploration is working, but test running is failing mysteriously without a good way to debug. The problem… I haven’t been able to connect to the transient process with a debugger – even with Debugger.Break(); in the test runner code.
Second piece of bad news… I’m trying to wrap my head around the new test running model in ReSharper. As far as I understand the new API, you get a call per test to run rather than the complete list. I’m not sure if this is going to be workable at all with VstsUnit due to unnecessary limitations imposed by Microsoft. The entire VstsUnit testing API is marked internal with [InternalsVisibleTo(MicrosoftPublicKey)]. So the only way to run the tests is through mstest.exe.
Third piece of bad news… After much struggling, VstsUnit doesn’t work for me for a whole variety of reasons. NUnit and MbUnit are just frictionless by comparison. When I absolutely must run VstsUnit (or NUnit/MbUnit), I’m using Jamie Cansdale’s TestDriven.NET. Not as pretty as the ReSharper Unit Test Explorer, but much more functional. Highly recommended.
The good news… For those of you who wish to continue using ReSharper’s Unit Test Explorer, I’ve released the source code on Google Code for both the ReSharper 2.5 and 3.0 versions. You can find it under vstsunit-resharper. If you have time and interest to work on this project, please drop me an email. I’m accepting patches… 
I’m also releasing the code under The BSD License, which means that if JetBrains wants to grab the code and incorporate it directly into ReSharper, they are more than welcome to it!
N.B. Due to redistribution restrictions, I cannot place the required Visual Studio and ReSharper DLLs into the Subversion repository. You will need to copy the files into lib\ReSharper and lib\VisualStudio. See the Readme.txt files in these directories for more information.
.jpg)
