Disclaimer: RedGate is a sponsor of devlicio.us and offered a copy of the product and a ThinkGeek gift certificate as an incentive to review their product. This review is the work of the author and was not approved by anyone other than the author. There, now you know the kind of taint this review has. Please keep reading anyhow. OK? Good!
.NET Reflector is part of any respectable .NET developer’s tool belt. When you want to figure out how something works, why your code breaks when interacting with some library, you view the assembly through .NET Reflector’s lens. The latest version, 6.1.0.11, will display the IL in an assembly as IL, Managed C++, VB.NET, C#, Delphi, or Oxygene. The latest version has been updated to support .NET 4 and allows you to jump into .NET Reflector from Visual Studio. I was disappointed to see that the “Open in .NET Reflector” menu option is only available from the Object Explorer. I would have expected to see this option by right-clicking on the assembly from the References list in the Solution Explorer, but no. Given that other tools (TestDriven.NET in particular) do add this functionality (they actually add “Open in .NET Reflector” from the Solution Explorer!) RedGate needs to address this usability issue.
Otherwise, the free version of .NET Reflector hasn’t changed. It is still a great tool.
So, what about this new, Pro version? First, it costs $195 US. What do you get for that price? You get the ability to generate source code and PDBs so that you can step through the assemblies you use in the languages you know. If you are debugging Microsoft provided assemblies, you can already step through assemblies using the actual source (typically C#) through the Enable .NET Framework Source Stepping option from the Options dialog (in VS 2008/2010, access this dialog from Tools—>Options menu.)
In the past, Microsoft wasn’t always good about keeping their symbol servers and source code servers up to date. Not every group put their code into the repository right away, so service packs and other patches might cause you to lose the ability to step through code. If you use components from other vendors, this option does you no good at all. RedGate is betting that a number of you want to be able to step through all .NET assemblies in VB.NET or C#. At a high level, RedGate generates the source code for an entire assembly and dumps it onto disk. It also writes out a PDB that tells Visual Studio how to map the assembly code to the generated code.
To long time users of .NET Reflector, the code generation piece may sound like old hat. It is. Back in May of 2004, Denis Bauer released a .NET Reflector plug-in that dumps the assembly information as code files (the plug-in was last updated for .NET Reflector v5). If you want a full project file for the dumped files, you used Jason Bock’s FileGenerator plugin. Unfortunately, neither of these allow you to step through code, and that’s what many of us need. .NET Reflector Pro adds that functionality.
The overall experience is seamless. Upon running .NET Reflector, the .NET Reflector top level menu is added to Visual Studio 2008/2010. From here, you can either decompile an assembly in your project, Explore Decompiled Assemblies, or Debug an Executable.
Explore Decompiled Assemblies just pops open the Object Explorer in Visual Studio. I would have expected the list to be reduced to the list of assemblies I had already decompiled, but that isn’t what happened. Debug an Executable is a bit confusing too—it just fires up the executable and attached the debugger. If you have decompiled the assemblies of interest already, you can step through that code. Otherwise, this feature seems to be a bit of a waste. When PDB information does not exist, I would have expected the UI to say something like “.NET Reflector has not created debugging information for the selected executable. Would you like to generate source code and PDBs now?” I should then be able to select the assemblies I want to debug using this new functionality.
All that said, the tool does redeem itself. When selecting .NET Reflector—>Choose Assemblies to Debug, the tool gets things right. This is the only feature in the Pro version that seems to have been completely thought out. At this stage, you are presented with the following dialog:
You can generate the source in C# v2.0/3.0 or Visual Basic 8.0/9.0. You then select the assemblies you would like to be able to step through and press OK. A little while later (time completely dependent on the size of the assembly), you are ready to do source level debugging. In the I tested out, this worked as advertised. I was able to step into System.dll, System.Web.dll, and other assemblies I regularly use. So, for .NET 4.0, clearly a win. F11 works fine, you can set breakpoints etc. For .NET 4.0 developers, this will be very helpful debugging those nasty issues where you need to figure out why your code is causing .NET and other libraries to die.
So, how about Silverlight? I had .NET Reflector generate the source/debug information for System.Windows. Then, I set a breakpoint in the constructor for my Silverlight MainPage.xaml.cs. I was able to step out to MS.Internal.CoreInvokeHandler.InvokeEventHandler.
I tried doing the same thing with the just released Windows Phone SDK. In this case, I was unable to get the application to rebuild correctly and work. After instructing .NET Reflector to generate the information for System.Windows for a Windows Phone Application, I saw this dialog:
After generating the assemblies, Reflector pointed the references in the solution to the new assemblies. Upon debugging, I saw this message (followed by several more for the other updated assemblies):
--------------------------- .NET Reflector --------------------------- The loaded assembly "System.Windows" is not the one .NET Reflector expected.
Expected version: "c:\temp\regen\System.Windows.dll"
Loaded version: "System.Windows.dll"
If the correct assembly is not loaded, debugging may not work. --------------------------- OK ---------------------------
If you are doing any Windows Phone development, the tool does not work for you. I imagine that this shortcoming will be addressed in the coming months—the SDK was only recently released.
The source code gets dropped into an AppData folder. For example, the code for MS.Internal.CoreInvokeHandler is at:
C:\Users\Scott Seely\AppData\Local\Red Gate\.NET Reflector 6\Cache\V4\x86\CS\V35\c46bf0b4-91fb-4aa9-8732-63fe4e8d7afc\MS\Internal\CoreInvokeHandler.cs
Looking in the v35 directory, we see that a PDB is dumped out:
The assemblyLoc file corresponding to the System.Windows.PDB file has the following contents:
c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\System.Windows.dll
For an assembly in the GAC, System.Windows.Forms, the assemblyLoc file points to it’s GAC location:
C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll
which appears to say that the symbols are generated from that particular reference assembly. The GUID named folder contains source code.
Having access to source and single stepping helps me troubleshoot problems faster because I can see why the underlying code doesn’t like what I’m doing when consuming the class libraries. Like most developer tools, this one has its value in the time savings you will get by getting you to the why of a bug in less time. I like the tool because it doesn’t change how I do my day job. It gives me access to more code so I can poke down the debug path even further without pulling out Reflector to grok why my code isn’t behaving as expected. And, I can easily make stepping into other people’s code part of my daily workflow.
Overall, I like the enhancements and am looking forward to using .NET Reflector Pro.
Yesterday I delivered my talk, “Build Your Own MVVM Framework,” at Mix. Thanks to all who came out to listen and allow me a short time to share some of my ideas. I’m very grateful to have had this opportunity. Thanks also to all who voted for the talk. If you were not able to make it in person, Microsoft has made the video of the session available online along with the slides. You can now watch it at http://live.visitmix.com/MIX10/Sessions/EX15. I’m also providing the full source code for the sample application as an attachment to this blog post. If you look at the source code, there are a few things to keep in mind:
I hope this talk and sample give you some ideas. I would love to hear your feedback. Enjoy!
This past Saturday I had an early morning coffee with a friend. He’s an entrepreneurial type – a big thinker who moves at a fast pace and is always thinking ahead. One question he asked of me, “Are you playing checkers or chess?”.
The question was asked around business and career but I could not help but think of the implications to software.
In the agile software world we often use the mantra…”do the simplest thing that works”. I have found that I cringe at the usage of that statement at certain points (when honest - even at my own usage at times upon later reflection). Really, if we step back and honestly evaluate ourselves, how often do we really implement the simplest thing that works. My opinion is that it’s often used as an excuse to get get out of work - a “wild card” of sorts that’s pulled out when convenient.
With “the simplest thing that works”, developers associate the term YAGNI – You Ain’t Gonna Need It. While very often true – you really don’t need that feature (studies have demonstrated and confirmed) – I see times where people confuse YAGNI and the agile principle of “the simplest thing that works”. What’s the difference?
Chess versus checkers my friend. Checkers is a pretty simple game with few rules and even fewer game pieces. Chess however has several game pieces, each of which has their own movements and rules associated with them. The types of discussions and strategies that exist around chess do not exist around checkers. Put simply, chess is much more complex than checkers. Checkers is really treated on a move-by-move basis whereas chess is far more strategic, where moves are setup far in advance of their execution.
When talking about “the simplest thing that works” we have to be careful to not be playing checkers. Play chess instead. Make a small, single move that moves you closer to some strategic end. Like it or not, many waterfall processes are playing chess – trying to anticipate every outcome or piece of functionality and adjust/account for it. What the waterfall practitioner fails to see is the inevitable change. Many agile adopters start playing checkers, making small move after small move, assuaging fears of downstream problems with the comfort that their doing the simplest thing that works.
Therefore, have a strategy, a end in mind, and then do the simplest thing that works that moves you closer to that end. Note however that this may not always be the absolute simplest thing that works.
Arguably, one of the most powerful features of UppercuT (UC) is the ability to extend any step of the build process with a pre, post, or replace hook. This customization is done in a separate location from the build so you can upgrade without wondering if you broke the build.
There is a hook before each step of the build has run. There is a hook after. And back to power again, there is a replacement hook. If you don’t like what the step is doing and/or you want to replace it’s entire functionality, you just drop a custom replacement extension and UppercuT will perform the custom step instead.
Up until recently all custom hooks had to be written in NAnt. Now they are a little sweeter because you no longer need to use NAnt to extend UC if you don’t want to. You can use PowerShell. Or Ruby. Let that sink in for a moment. You don’t have to even need to interact with NAnt at all now.
On the wiki, all of the extension points are shown. The basic idea is that you would put whatever customization you are doing in a separate folder named build.custom. Each step Let’s take a look at all we can customize:
UppercuT can now be extended with PowerShell (PS). To customize any extension point with PS, just add .ps1 to the end of the file name and write your custom tasks in PowerShell.
If you are not signing your scripts you will need to change a setting in the UppercuT.config file. This does impose a security risk, because this allows PS to now run any PS script. This setting stays that way on ANY machine that runs the build until manually changed by someone. I’m not responsible if you mess up your machine or anyone else’s by doing this. You’ve been warned.
Now that you are fully aware of any security holes you may open and are okay with that, let’s move on.
Let’s create a file called default.replace.build.ps1 in the build.custom folder.
Open that file in notepad and let’s add this to it:
write-host "hello - I'm a custom task written in Powershell!"
Now, let’s run build.bat.
You could get some PSake action going here. I won’t dive into that in this post though.
If you want to customize any extension point with Ruby, just add .rb to the end of the file name and write your custom tasks in Ruby. Let’s write a custom ruby task for UC. If you were thinking it would be the same as the one we just wrote for PS, you’d be right!
In the build.custom folder, lets create a file called default.replace.build.rb.
Open that file in notepad and let’s put this in there:
puts "I'm a custom ruby task!"
Now, let’s run build.bat again.
That’s chunky bacon.
Just for fun, I wanted to see if I could replace the compile.step with a Rake task. Not just any rake task, Albacore’s msbuild task. Albacore is a suite of rake tasks brought about by Derick Bailey to make building .NET with Rake easier. It has quite a bit of support with developers that are using Rake to build code.
In my build.custom folder, I drop a compile.replace.step.rb. I also put in a separate file that will contain my Albacore rake task and I call that compile.rb.
What are the contents of compile.replace.step.rb?
rake = 'rake' arguments= '-f ' + Dir.pwd + '/../build.custom/compile.rb' #puts "Calling #{rake} " + arguments system("#{rake} " + arguments)
Since the custom extensions call ruby, we have to shell back out and call rake. That’s what we are doing here. We also realize that ruby is called from the build folder, so we need to back out and dive into the build.custom folder to find the file that is technically next to us.
What are the contents of compile.rb?
require 'rubygems' require 'fileutils' require 'albacore' task :default => [:compile] puts "Using Ruby to compile UppercuT with Albacore Tasks" desc 'Compile the source' msbuild :compile do |msb| msb.properties = { :configuration => :Release, :outputpath => '../../build_output/UppercuT' } msb.targets [:clean, :build] msb.verbosity = "quiet" msb.path_to_command = 'c:/Windows/Microsoft.NET/Framework/v3.5/MSBuild.exe' msb.solution = '../uppercut.sln' end
We are using the msbuild task here. We change the output path to the build_output/UppercuT folder. The output path has “../../” because this is based on every project. We could grab the current directory and then point the task specifically to a folder if we have projects that are at different levels. We want the verbosity to be quiet so we set that as well.
So what kind of output do you get for this? Let’s run build.bat
custom_tasks_replace: [echo] Running custom tasks instead of normal tasks if C:\code\uppercut\build\..\build.custom\compile.replace.step exists. [exec] (in C:/code/uppercut/build) [exec] Using Ruby to compile UppercuT with Albacore Tasks [exec] Microsoft (R) Build Engine Version 3.5.30729.4926 [exec] [Microsoft .NET Framework, Version 2.0.50727.4927] [exec] Copyright (C) Microsoft Corporation 2007. All rights reserved.
custom_tasks_replace:
[echo] Running custom tasks instead of normal tasks if C:\code\uppercut\build\..\build.custom\compile.replace.step exists. [exec] (in C:/code/uppercut/build) [exec] Using Ruby to compile UppercuT with Albacore Tasks [exec] Microsoft (R) Build Engine Version 3.5.30729.4926 [exec] [Microsoft .NET Framework, Version 2.0.50727.4927] [exec] Copyright (C) Microsoft Corporation 2007. All rights reserved.
If you think this is awesome, you’d be right!
With this knowledge you shall build.
Tomorrow I kiss the wife and baby goodbye (sadly) and hop on a plane heading to Mix in Las Vegas. This year I have the unique honor and privilege to present “Build Your Own MVVM Framework.” I’ll be speaking Monday afternoon at 3:30 PM in Lagoon F. Here’s the official description of my talk:
You’ve heard a lot about MVVM, but you’ve struggled to see how it can help you in your day to day work. Or, you are experienced at implementing MVVM, but looking for some ways to maximize on your investment in this methodology. In this talk, we look at a simple MVVM application and see how a small, application-specific framework can help eliminate pain points in our UI development and provide simple and effective solutions. Attendees will walk away with code, but more importantly with an understanding of how to apply some simple ideas to improve productivity with MVVM in their own projects.
This is an intermediate level discussion of MVVM and presupposes knowledge of either WPF or Silverlight and a grasp of the basic MVVM pattern. If you are new to MVVM, let me encourage you to attend Laurent Bugnion’s talk “Understanding the Model-View-ViewModel Pattern,” conveniently scheduled just before me at 2:00pm in Lagoon F.
During the conference, I’m planning to spend plenty of time in the lounge. I’ll probably be working on Caliburn :) If you’re interested in Caliburn and will be at Mix, let me know. If there is enough interest, I can do a small demo/presentation in the lounge at some point. I’m looking forward to seeing you there and thank you to everyone who voted for my talk!
I’ve always been intrigued by the versioning problem. The versioning problem works like this: you build an API (Application Programming Interface) to get some work done. That API is successful and consumers ask for enhancements to the API. At this point, you have a problem: how do you support everyone who uses the current API while adding enhancements? If you have been down this road, you know that you have to solve the problem early—before success.
The way you handle versioning varies. With compiled code and libraries, you send out a new DLL/Assembly/JAR file and tell folks to convert existing code when they have a chance. With Web services, including SOAP, REST, and just HTTP accessible ones, you have other issues. You typically want a single code base to consume the old and updated messages. Given that many of us are now writing REST services, I talked to InformIT about the need for an article explaining how to version these JSON/XML speaking endpoints. That article is now live and available for your reading at http://www.informit.com/articles/article.aspx?p=1566460.
This is a really quick post, mostly for myself so the next time I have this issue I can find the answer (yes, I often search my blog before google).
The error “Cannot use a leading .. to exit above the top directory” can be thrown by ASP.NET when you use relative paths incorrectly. If you generate a url with too many “../../../” levels in it that would take the user above the root directory, you can generate the exception.
Why the exception? Security I guess, but it’s a client URL and the server should know better than let the internet walk the C drive, but at one time a company in Redmond had servers with just such issues. My problem isn’t with the unneeded exception (after all, it would just be a 404 link worst case), but with the bug in ASP.NET that causes it.
If you are using Server.Transfer or HttpContext.RewritePath to redirect a request (say map it to a template page) and have a HyperLink control with the ImageUrl property set, you win an extra “../” by the framework. The fix is to wrap the HyperLink control around an Image control.
In code, if you have:
<asp:HyperLink runat="server" NavigateUrl="~/FlyPage.aspx" ImageUrl="~/Images/DeadFly.png" Width="200" Height="200"/>
Change it to:
<asp:HyperLink runat="server" NavigateUrl="~/FlyPage.aspx"> <asp:Image runat="server" ImageUrl="~/Images/DeadFly.png" Width="200" Height="200" /></asp:HyperLink>
(I said it was a quick post… now go register for CodeStock!)
I work on a web application and I use dotTrace when some profiling is needed. The problem is that I cannot fire off doTrace directly from inside Visual Studio 2008 because the commands and toolbar icons to launch it are permanently disabled. Well, not anymore.
The web application I work on is a 64-bit application. I use a 64-bit version of Windows (namely, Win2008 x64). I installed the 64-bit version of dotTrace 3.1 and it does work stand-alone but it never worked integrated with VS 2008, which is a shame because it contains some neat features like it's enabling the ReSharper test runner to run the chosen test(s) directly under dotTrace profiling. The screen shot below shows how it should look like but on my box these dotTrace commands were simply disabled.
After much disappointment with the missing features, my fellow Devlicio.us blogger Hadi Hariri put me in contact with Oleg Stepanov.
The first suggestion was trying the 32-bit version of dotTrace, which wasn't an option for me because, as I said, my application and all the supporting utilities are 64-bit, it runs under a 64-bit process, so that's ultimately how I need to profile it.
Then Oleg explained that the problem is that VS is a 32-bit application and it was looking for a registry key in the wrong place, not finding it, and then it was assuming dotTrace wasn't available.
Hmmm... That sounded eerily familiar, didn't it? Once again the little annoyances of developing 64-bit code with 32-bit tools come to bite us.
To fix the problem, just like the other time it happened, we just need to copy the right registry key to its corresponding place under the Wow6432Node key.
Open the Registry Editor and go to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ key. One of its GUID-named subkeys will contain the dotTrace information. Just search for dotTrace and find the right subkey. Now just copy (or export/edit/import) that key under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\ and you're ready to restart Visual Studio and see all the integrated dotTrace features come alive.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\
This post is a playground for me, to try out some ideas I want to include in my talk about Windsor at KGD.NET meeting later this month.
We have a messaging application built around two interfaces:
public interface Command
{
}
public interface Handler
void Execute();
public interface Handler<T> : Handler where T : Command
T Command { get; set; }
Hopefully I don’t have to explain how they work. The idea is, application receives commands from somewhere, then it pulls all handlers registered for this command and let them handle the command. Split of Handler interface into generic and non-generic part is there to make up for lack of co/contra-variance in .NET 3.5.
Handlers are quite simple classes implementing closed version of Handler<> interface. For example to change client’s address we’d have the following command
[Serializable]
public class UpdateClientCorrespondenceAddressCommand : Command
private readonly AddressDto address;
private readonly Guid clientId;
public UpdateClientCorrespondenceAddressCommand(Guid clientId, AddressDto address)
this.clientId = clientId;
this.address = address;
public AddressDto Address
get { return address; }
public Guid ClientId
get { return clientId; }
and its handler:
public class UpdateClientCorrespondenceAddressHandler : Handler<UpdateClientCorrespondenceAddressCommand>
private readonly Repository<Client> clientRepository;
public UpdateClientCorrespondenceAddressHandler(Repository<Client> clientRepository)
this.clientRepository = clientRepository;
public UpdateClientCorrespondenceAddressCommand Command { get; set; }
public void Execute()
var command = Command;
if (command == null) return;
var client = clientRepository.Get(command.ClientId);
client.ChangeCorrespondenceAddress(command.Address);
clientRepository.Update(client);
Nothing earth shattering here. We would have similar set up for other business events in the application. We assume we can have more than one handler for single command (for example another handler would update shipping costs and promotions available for the new address of the client).
The ability to pull multiple services from the container via typed factory is not available in Windsor 2.1.1 – you need the trunk version to take advantage of it.
To register the code we create an installer:
public class Installer : IWindsorInstaller
public void Install(IWindsorContainer container, IConfigurationStore store)
container.AddFacility<TypedFactoryFacility>()
.Register(
Component.For<ITypedFactoryComponentSelector>().ImplementedBy<HandlerSelector>(),
Component.For<AutoReleaseHandlerInterceptor>(),
AllTypes.FromAssemblyContaining<Program>()
.BasedOn(typeof(Repository<>))
.WithService.Base()
.Configure(c => c.LifeStyle.Singleton)
.BasedOn(typeof(Handler<>))
.Configure(c => c.LifeStyle.Is(LifestyleType.Transient)
.Interceptors<AutoReleaseHandlerInterceptor>()),
Component.For<HandlerFactory>().AsFactory());
There are a couple interesting things here. First we register typed factory facility, which we’ll use later on to pull handlers for commands we receive. Then we register custom selector for typed factory (discussed below), and an interceptor (discussed below). Then we register all repositories and all handlers from given assembly, configuring handlers with transient lifestyle and with the interceptor we registered above. Lastly we also register typed factory for handlers:
public interface HandlerFactory
Handler[] GetHandlersForCommand(Command command);
The handler factory has to do quite a lot of work for us. Given an instance of a command, it has to pull from the container all the handlers for the command’s type. To do this we need to use a custom selector (and trunk version of Windsor).
public class HandlerSelector:ITypedFactoryComponentSelector
public TypedFactoryComponent SelectComponent(MethodInfo method, Type type, object[] arguments)
Debug.Assert(arguments.Length == 1);
var message = arguments[0];
var handlerType = typeof(Handler<>).MakeGenericType(message.GetType());
return new TypedFactoryComponentCollection(handlerType.MakeArrayType(), new Arguments(arguments));
Based on the command’s type we create closed Handler<> type and return TypedFactoryComponentCollection (new type that pulls all components for given service) passing down the command as typed argument to the resolution.
We can now use the code like this:
private static void Main()
using(var container = new WindsorContainer().Install(new Installer()))
var factory = container.Resolve<HandlerFactory>();
DoActualWork(factory);
Console.ReadKey(true);
private static void DoActualWork(HandlerFactory factory)
var command = ImmitateCommandArrived();
var handlers = factory.GetHandlersForCommand(command);
foreach (var handler in handlers)
handler.Execute();
private static Command ImmitateCommandArrived()
return new UpdateClientCorrespondenceAddressCommand(Guid.NewGuid(), GetSomeAddress());
Notice how simple the calling code is. It has no knowledge of the (quite complex) process that takes place behind the scenes to create strongly typed instances of appropriate classes. It does not even know what actual type of command it got.
Isn’t this code too simple though? It resolves handlers, which are transient components and it does not release them. And we all know transient components need to be released in Windsor, right?
Well – it does release them actually, it just doesn’t do it explicitly. Remember we registered an interceptor with all handlers. Here’s how that interceptor looks like:
[Transient]
public class AutoReleaseHandlerInterceptor : IInterceptor
private static readonly MethodInfo Execute = typeof(Handler).GetMethod("Execute");
private readonly IKernel kernel;
public AutoReleaseHandlerInterceptor(IKernel kernel)
this.kernel = kernel;
public void Intercept(IInvocation invocation)
if(invocation.Method!=Execute)
invocation.Proceed();
return;
try
finally
kernel.ReleaseComponent(invocation.Proxy);
The interceptor releases the component after the call to Execute for us. Thanks to this we take the burden (no pun intended) of releasing the components from the callers, and we make sure our handlers won’t leak memory. This is quite a useful trick actually, and while I have precisely zero knowledge of NServiceBus, I think it could be used to fix the issue Davy discussed, without having to mess with release policy.
Yesterday the ReSharper Twitter Account tweeted about a Zen Coding Plug-in available as a PowerToy. If you’re not familiar with Zen Coding, check out this link. I received a couple of emails from people asking about the PowerToys and what exactly they were, and to be honest, I wasn’t really surprised. I don’t think many have actually heard of them. So I decided to follow Hanselman’s advice of minimizing key strokes, thus the post.
The Power Toys are a series of plug-ins that have been written by the ReSharper developer team, and have been used in fact internally as samples of ReSharper’s API.
You can download the PowerToys for ReSharper 5 from the Early Access Program page (for previous versions, see What next?), which is here.
Unless there’s some API change, there are normally compatible from one build to the next, but just to be safe, download the one corresponding to the nightly build you have.
They are packaged up in a zip file that contains MSI installers for each individual plug-in, as well as a PowerToys Pack which includes them all (and you can pick and choose which one you want during the installation process). Best option is to just pick the full pack. Each MSI is also suffixed with a version, 8 corresponding to Visual Studio 2005, 9 to 2008 and 10 to 2010.
The zip file also contains another zip with the source code, which you can compile and install, if you don’t want to use an installer. If you’re doing this, compile them and place them under the %Program files%\JetBrains\ReSharper\Bin\Plugins folder. Normally best to create a folder for each plug-in (If you’re just interested in having the source but prefer to use the MSI, the installer will also install the source for you).
Once you install them, they should appear as plug-ins under the ReSharper menu:
As you can see from the list, there are quite a few goodies in there, not only Zen Coding!
The PowerToys are not only valuable in terms of the functionality they provide, but also serve as an example of how to write ReSharper plug-ins and interact with the ReSharper API, but they’ve never been released passed Early Access Programs. That is one reason 4.5 PowerToys are not available.
However, we want to change that. We not only want to make them available, but also to document them and offer them as a true OSS project, where the developer community can contribute to them, be it with additional features, bug fixes or providing completely new plug-ins.
This is something that I personally think would be valuable for the community. If you like this idea or have other suggestions, please feel free to give me feedback.
The ability to have static code analysis (aka run FXCop inside the IDE) is not something that is new to Visual Studio 2010. What is new is the simplicity in which you can share the exact same configuration across all of your projects at once.
Prior to VS2010 if you wanted to share your config it was not possible (from what I have ever seen). With VS2008 each .proj file contained a section in the file which laid out each rule that should/should not be turned on. If you wanted to share these what you needed to do was open up each .proj file in a text editor and copy/paste the rules. As you could image, copy and pasting this could get old real fast. In fact I would even argue that I may even prevent you from wanted to use the built in analysis all together.
Here comes Visual Studio 2010 to the rescue. In 2010 you can save your rules to a .ruleset file and you can import this same file into all your projects. No more need for copy/paste by hand.
Steps To Do This:
Step 1: Open up the Code Analysis tab in the project properties.
Step 2: In the drop down choose Browse
Step 3: Find your .ruleset file on disk
Step 4: Rinse and Repeat for all your other projects.
Now that having the ability to share your rule set across projects is painless you have NO excuse not to utilize this feature.
Till next time,
On February 28, 2010, Activision issued a Cease and Desist order against Phoenix Online Studios, creators of “The Silver Lining,” an unofficial sequel to the King's Quest series The sequel had, in 2005, been approved for non-commercial release by the owner of the King’s Quest IP, Vivendi Universal. The team has been working on the 5-part episodic King’s Quest Sequel for eight years (they started before 2005). They had just completed their final milestone and were preparing to submit the game for approval to Vivendi Universal right before Activision and Vivendi merged. Immediately upon acquisition of the King’s Quest IP, Activision shut down Phoenix Studios, with no intent to uphold the previous agreements.
As a long time fan of adventure games, and someone who has always wanted a real sequel to KQ6, I am really saddened by this. Personally, I plan not to have anything to do with Activision until they make this right. I hope you will join me in this. If you have a few minutes, please sign the online petition and consider sending a letter to Activision. Resources are below. Thank you. Now, on with your regularly scheduled programming…
Online Petition: http://www.petitionspot.com/petitions/savetsl/ Facebook Group: http://www.facebook.com/group.php?gid=382202612795&ref=mf MySpace Page: http://www.myspace.com/savetsl Form Letter for Contacting Activision: http://www.tsl-game.com/forum/index.php?topic=8406.0
I haven't mentioned our meetings here in a while but our group has been going strong and enthusiastic all this time.
Tomorrow, March 10th our topic will be build scripts for .Net projects using Rake and Albacore. I've been using Rake and a little bit of Albacore in my own projects and I'm ready to say that it will take a very serious event to make me go back to NAnt or MSBuild.
6:00 pm Pizza and networking time
6:30 pm
How would you to write your build scripts using a scripting language instead of XML? In this month's meeting we will see how the ease of programming in Ruby can be used to create a much more pleasant and extensible build script.
Rake isn't just for Rubyists or Alphageeks anymore. Albacore helps bring the power and expresiveness of the Ruby language to the world of .NET build automation. Using Rake it's never been easier to handle build automation, test execution, continuous integration and just about any task you need to automate for your build.
Michael D. Hall has been developing software on the Microsoft platform for over a decade. He's been an Alt.NETter for years and is really enjoying the exposure to different ideas and concepts beyond the safe confines of the .NET world. Currently he's a consultant working with Obtiva and has started a Cloud Developer's Group that meets monthly in McHenry county.
The following code throws an exception. Can you spot the bug?
public class MyControl : Control { public static DependencyProperty MyPropertyProperty = DependencyProperty.Register( "MyProperty", typeof (double), typeof (MyControl), new PropertyMetadata(0)); public double MyProperty { get { return (double) GetValue(MyPropertyProperty); } set { SetValue(MyPropertyProperty, value); } } }
I’m starting a new series of blogs posts on profiling, where we’ll try and cover common bottlenecks and how to identify them in your applications. However, before delving deeper into the subject, let me make a small but important observation:
Your bottleneck is probably not your for loop
Now, replace that for loop with switch statement, an older version of some outdated algorithm that you feel needs optimizing, or that retched collection of classes that would perform better if you were using an array to loop through them, and you’ll end up with the same observation.
When dealing with business applications, it is unusual for major performance problems to be pinpointed down to specific portions of code or a concrete implementation of an algorithm. Usually most of the issues are bottlenecks at the data level, network level or purely down to how a business decision is made.
Whether we use an ORM or use SQL directly, incorrectly formulated queries are one of the most predominant causes of bad performance. Not understanding concepts such as Lazy or Eager loading when using an ORM can be disastrous to the performance of an application, and are usually portrayed as “ORM XYZ sucks at performance”.
Network bandwidth and latency are other issues; when dealing with web applications for instance, having large pages (i.e. ViewState) or rendering Javascript directly without using script files, are a common problem for performance penalties. Making heavy calls to the server when very little information is required (i.e. UpdatePanel used incorrectly) are again main causes for concern.
In many cases, design decisions we make early can affect the performance of our applications, and it is important to identify these concerns and address them correctly. Using an ORM, profiling it, understanding how Ajax really works and not worrying about working with Javascript, or using an asynchronous architecture when dealing with long running business processes are many ways to avoid bad performance in the long run.
On the other hand, what we shouldn’t do is focus on micro-optimizations, on trying to make the most efficient, yet completely undecipherable algorithm to calculate the probability of winning money when buying lottery tickets, when the underlying problem is a bottleneck caused by a bad query. This kind of approach is often referred to as Premature Optimization, and can be disastrous for a project.
Having said all that, there are times when we need better performance after having eliminated all the obvious causes, and need to discover why something is not performing as well as it should be. Of course, these concerns are greater when the nature of our application demands highly optimized code. In these cases, it is crucial to understand how things work in order to solve the problem. As a old-school boy, before we had managed libraries and drag-n-drop, I’m also a firm believer that it is always important to understand how things work under the covers, even if it is to just improve one self's knowledge.
Therefore, in these series of blog posts about performance, I’m going to focus on the latter, examining the details of code and how some things can perform better than others. So given the disclaimer, let’s get down to business.
In order to do performance tuning, you need to use a tool. Setting stopwatches doesn’t work, because as Christian Gross so rightly pointed out during one of his talks, and I semi-quote: ‘if you’re using a stopwatch, you think you know where the bottleneck is. Most of the time, you’re wrong’. If you are setting using a manual approach of setting calling Start and Stop, trying to time something, you’re assuming you know that the performance problem is located in a particular point, and many times it is not that point. So you end up having to place these kind of diagnostic codes in various places in your code, and soon it becomes a maintenance nightmare. Fortunately, there are tools that can profile your application in a non-invasive manner. When talking about SQL profiling, there’s NHProfiler for instance. When it comes to code performance profiling, the two most known ones are ANT Profiler and dotTrace. I’m going to be using dotTrace. I used it before joining JetBrains and continue to use it now that I’m at JetBrains. I’ll be using version 4.0 which is currently (at the time of writing this post), in Early Access Program and with Beta being released very soon.
Those that are familiar with it ASP.NET MVC know it relies heavily on the use of strings in many areas. For instance, when defining ActionLinks, you write
Html.ActionLink(“Home”, “Index”, “Home”)
where the first parameter is the link text, the second the Action and the third parameter is the Controller. The problem with this of course is that if you type either the second or third parameter incorrectly, you won’t know until runtime. Even if you build your views it won’t help.
An alternative is to use Expression based Html Helpers (another option is to use ReSharper of course :)). These are strongly-typed ActionLinks that do not ship out of the box with ASP.NET MVC, but are available as a separate download in the MVC Futures assembly, which can be thought of as a kind of sandbox for Microsoft to play with. Some of the functionalities in this library have eventually made it to the main core, such as RenderPartial, which was in fact there from pretty much the early Previews of MVC 1, and didn’t get all the excitement until it made it into the core in version 2. Other functionality, including the expression based ActionLinks haven’t made it in yet. When using these helpers, the previous link would be:
Html.ActionLink<HomeController>( a => a.Index, “Home”)
In principle this looks good, and begs the question of why it is not in the main core. Well I don’t know the exact reason, but one could potentially be due to it’s performance. Several people have talked about the difference in terms of rendering when using this version as opposed to the standard string based one. You can find one of those posts here. What I thought I’d do, is actually see how much difference in speed there is between one and the other.
I’m using a very simple project for this profiling. It’s your standard ASP.NET MVC 2 application. On Index page, I’ve added two blocks of code:
The first for loop will render out 1000 links using the string based ActionLink version, whereas the second loop will do the same using the expression-based one.
What we want to do now is run this and see how long it takes for each loop to complete.
Working with dotTrace is as easy as it gets. There are two ways to profile an application: Standalone or integrated within Visual Studio. In the case of the former, you can start up dotTrace outside of Visual Studio and point to an application to profile. On the other hand if you have it integrated inside Visual Studio, then all you need to do is click on the Profile menu option:
Once we do that, we get a dialog box that provides us a series of options, mainly to do with the type of profiling we are going to perform.
Since we’re profiling a web application, we can either use the Development Server or Internet Information Server. In our case we’re going to use the former. dotTrace will automatically pick up the server settings as well as fill out the physical path for our application.
Next come the profiling options. The basic settings are Profiling Type and Meter Kind. The first parameter indicates how profiling will take place. It can be:
Tracing is normally the recommended option. Meter Kind defines how dotTrace logs the time: CPU instruction or Performance counter (uses the Windows API and samples are hardware independent).
Once we have everything setup, we can start profiling our app. dotTrace will launch a small panel that allows us to control data sampling.
dotTrace does not by default however launch the browser. In order to do so, we need to either click on the WebDev server and Open in Browser or just type the URL directly in the browser.
The next step is to perform the operations we want to profile and then click on GetSnapshot.
Since in our case, having rendered the Index action performs these operations, once the page has been loaded, we can click on GetSnapshot and have the profiler launched.
I’m not going to get into all of the details of dotTrace in this first post because otherwise it would never end; we’ll cover some of the aspects in future posts. For now, lets focus on our performance test at hand which is the difference between the two types of ActionLinks (string and expression based).
The easiest way to find what we are looking for is to use the…you guessed it, Find feature. Ctrl+F will bring up a dialog box similar to ReSharper’s Type location. We can then type ActionLink to filter the list of functions down to the ones that interest us
We can see that there are two versions, as expected. Let’s drill in to the second one first, the string based one. Hitting Enter will find the first location. We can then press F3 until we find the one that interests us. Remember, Site.Master and other references to this call also exist. We’re specifically looking for the loop, the one with 1000 calls
We can see that the ActionLink call takes 121ms for 1000 calls. Drilling in, we can see exactly where the time is spent, and 104ms of that is calling GenerateUrl. Now let’s take a look at the Expression based ActionLink
For the same 1000 calls it takes 140ms, which is an increase of approximately 17%. Diving in once again, we can see that 6ms of this is in the parsing of the expression tree, GetRouteValuesFromExpression. What this function does is merely analyze the expression to extract the ActionName from the parameter. The ControllerName it already has since it’s the concrete type the generic method is invoked with, returning both values in a RouteValueDictionary. As such it then needs to call GenerateRouteLink as opposed to GenerateLink since the former takes a RouteValueDictionary as a parameter, whereas the latter takes strings indicating the controller and action. They ultimately both call GenerateUrl.
From the results, the difference between the two calls is not that significant for 1000 links. As the number of links increment, the difference between the two does not change significantly. For instance, rendering 10.000 links, has a difference of 50ms between one version and another. What’s interesting that having run the same profiling on previous releases, the difference in time was nearly double, so there seems to have been improvement in this area. And as we can see, sometimes what might seem a performance problem, isn't necessarily one.
About The CodeBetter.Com Blog NetworkCodeBetter.Com FAQOur Mission Advertisers should contact Brendan
Subscribe Google Reader or Homepagedel.icio.us CodeBetter.com Latest ItemsAdd to My Yahoo!Subscribe with BloglinesSubscribe in NewsGator OnlineSubscribe with myFeedsterAdd to My AOLFurl CodeBetter.com Latest ItemsSubscribe in Rojo
Member ProjectsDimeCasts.Net - Derik Whittaker
Friends of Devlicio.usRed-Gate Tools For SQL and .NETNDependSlickEdit SmartInspect .NET Logging NGEDIT: ViEmu and Codekana LiteAccounting.Com DevExpressFixxNHibernate ProfilerUnfuddle Balsamiq MockupsScrumyJetBrains - ReSharper <-- NEW Friend!
Site Copyright © 2007 CodeBetter.Com Content Copyright Individual Bloggers