Hadi Hariri : Tools

Providing Intellisense, Navigation and more for Custom Helpers in ASP.NET MVC

Hadi Hariri — Wed, 07 Dec 2011 13:47:00 GMT

You probably are aware by now that as of ReSharper 5 we added first-class support for ASP.NET MVC. This included among many things, the ability to provide Intellisense, Create from usage and Navigation to built-in methods such as Controller.View or Html.ActionLink:

Navigation

Ctrl+Left Mouse Click or F12 will navigate to the corresponding View

or to the Action and/or Controller

Intellisense and Create From Usage

Ability to have Intellisense when providing Actions/Controllers

as well as the possibility of creating from usage

However, what happens when you want to use a custom function, for instance, a better ActionLink or your own View method? Did you know that you can still get all these goodies? All you need to do is use some Annotations.

Using JetBrains.Annotations

ReSharper uses annotations via the form of .NET attributes to figure out what an ASP.NET MVC View, Action or Controller is. As such, all we need to do for our custom method and extensions to leverage this, is tell ReSharper what parameter corresponds to what.

Referencing the annotations

To use ReSharper annotations, we have mainly two options (with a third one hopefully coming soon):

1. We can include the library JetBrains.Annotations.dll in our project and reference it.

2. We can copy the annotations and include it as source in our project

[3. We can use nuget install-package JetBrains.Annotations] Coming soon!

The first option is pretty simple. The DLL is located in the ReSharper installation bin folder. For the second option, we open up ReSharper | Options and select Code Annotations entry

select the Copy default implementation to clipboard button and paste into an empty file.

Annotating custom methods

Once we’ve completed this step, all we need to do is annotate our parameters with the correct attributes. We’re interested in 3 different attributes in particular:

AspMvcView which indicates the parameter is a View
AspMvcAction which indicates the parameter is an Action
AspMvcController which indicates the parameter is a Controller

Here is the header corresponding to a base controller with a custom method named ExtendedView

and here’s the header for a custom ActionLink

(the body of both methods are omitted and are not necessary to demonstrate the functionality)

As soon as we do this, ReSharper picks up these methods and offers us the same functionality that is provided for the methods that ship out of the box:

Notice how we still get Navigation (the underlining), Intellisense and Create from usage in our TheOnlyActionLink custom method. Its much the same for the ExtendedView method

That’s all there is to it.

Setting up TeamCity as a native NuGet Server

Hadi Hariri — Thu, 01 Dec 2011 16:27:00 GMT

TeamCity 7.0 EAP (Early Access Program) was recently opened and one of the new features is the built-in support for NuGet. I recently blogged about setting up TeamCity to pack and publish NuGet packages via a plug-in and this plug-in is now included by default in TeamCity 7. However, the real new interesting feature is that TeamCity is now a native NuGet repository too!

Native NuGet Server?

Many of those that have been using NuGet, have most likely been using it to consume packages from nuget.org where there are currently over 3800 unique packages, most of which are open source.

What happens however if for some reason or another you do not want to submit packages to nuget.org? For instance, think that you want to use NuGet to modularize and distribute code inside your own organization, or create libraries for private consumption. In this case, publishing to nuget.org does not make sense. This leaves you with basically two options:

Setup your own NuGet repository by downloading and installing the code that nuget.org for instance
Copy nuget packages to a local share and have everyone read off of that

Both of these options come with their own share of overhead. With the local share you now require sharing of folders and permissions. Setting up your own NuGet repository also requires managing permissions and whatnot separately. At the end of the day, its another service to manage.

Fortunately, you now have a third option: TeamCity. The same server that builds your projects, runs your tests, packs and publishes your packages can now also serve them. The best part of it is that it is so simple, that I had to take up the rest of this blog with the previous nonsense just to give it some meat.

Enabling TeamCity as a NuGet Server

I am not going to cover how to pack and publish packages in this post. All that is covered in detail in the previous post I wrote, so please read that first if you’re not familiar with the process. Enabling TeamCity as NuGet and making packages available consists of two steps:

1. Enable the server to be a NuGet server

Go to Administration | Server Configuration | NuGet tab

Click on the Enable button to enable it. The same screen with then display two different feeds: a public and a private one:

If by chance the Public Url is not available, you will probably see a message telling you that you need to enable the Guest account in TeamCity, which can be done from the General tab.

2. Make your packages be your Artifacts

Since TeamCity itself is going to be a NuGet server, the step to publish a package is no longer required. However, packing the package is. In this step (NuGet Pack Build Type), we can just configure the output for the package to point to some specific folder, for instance packages

We need instruct TeamCity to ouput the results of this folder as artifacts. This is done in the General Settings step of the Build Configuration

and with that, we’re done. Next up is to configure Visual Studio to consume from this feed.

Configuring Visual Studio

Although this step is optional, it is recommended to add your repositories to Visual Studio to avoid having to type long URL’s in each time you want to read from a specific package repository. To do this, click on Options | Library Package Manager | Package Manager Settings

We need to add a new NuGet Repository. I’ve called it Local TeamCity and the URL corresponds to the public URL provided to me by TeamCity in Step 1:

Notice that I have another entry which is Local TeamCity Auth which corresponds to the authenticated version.

Once we have this, we can now easily consume packages from our repository by merely specifying it in the Package Manager Console, either via the Combobox or explicitly in each call:

Summary

That’s all there is to it. By merely publishing our packages as artifacts, TeamCity now provides a full-fledged nuget server which opens up great possibilities when it comes to working and managing dependencies between projects. TeamCity is currently in EAP and much of what I’ve described here is in open to improvements. That is why your feedback is very important. Download 7 and start playing with it today. Let us know what you think.

Native NuGet Support in TeamCity

Hadi Hariri — Wed, 24 Aug 2011 20:01:00 GMT

A few months ago, Scott Hanselman gave a session at TechEd US were he showed some new features we were working on for TeamCity, in order to provide first class support for NuGet. He later blogged about it here.

Instead of delaying until the next release of TeamCity, this feature (like many), has been developed as a plug-in. Eugene, who has been working on it, announced the availability of a first build a few weeks ago. After some initial trials and changes, I decided to setup YouTrackSharp to automate the publishing of the NuGet package. It was surprisingly easy as you'll see.

1. Installing the Plug-in

If your project is running on TeamCity at Codebetter.com, you can skip to Step 3, since it's already installed and configured. If not, then grab the latest build from our public TeamCity server. Place the zip file into the plugins folder of your TeamCity installation and restart the server.

2. Configuring the NuGet version

Once the server is running, and agents updated (automated procedure), you then need to tell TeamCity what NuGet version you want to use. The plug-in knows about the nuget.org feed to it can grab the latest version of the command line tool directly. Click on Administration | Server Configuration. If the plug-in installed correctly, you should now have a new Tab called NuGet:

Click on the "Install additional versions of the NuGet.exe Command Line". TeamCity will read from the feed and display available versions to you in the dialog box. Select the version you want and click Install:

Pull, Pack, Publish

The plug-in offers three main operations:

Pulling NuGet packages required to build your project
Creating NuGet packages
Publishing Packages

In my case, I want to create the package and publish it. To give you a general idea of my build process, here's the outline of the build steps:

The NuGet related steps are 3 and 4. Step 1 simply builds the project by building the solution file. Step 2 runs the MSpec tests.

3. Building the package

This step is for building the actual package. We create a new Build Step in our project and select NuGet Packages Pack. This will give us the following configuration screen:

As you can see, the configuration is pretty straightforward. Notice that in the Specification file, we can also provide a csproj file as opposed to a NuGet spec file. The advantage to this is that we do not have to redefine information such as version number and copyright information in the spec file. If you're not familiar with this feature, check out David Ebbo's post.

I've also checked the option to Include Sources and Symbols. This is also explained in David Ebbo's post and it's for publishing the sources to Symbolsource. Additional command line parameters (if required) can be passed in the Additional Commandline arguments. If you want to make this a release build, you can also do this by defining Configuration=Release in the Properties field.

Finally I've specified the Build number of the package using the TeamCity variable %build.number% which auto increments on each build, and is also used by another feature of TeamCity new in 6.5 which is called the AssemblyPatcher, which I'll show you as the last step.

4. Publishing the package

The next step is to publish the package. As before, we need to add a Build Step and select NuGet Packages Publish.

This step is even easier to configure. By convention it uses nuget.org as the destination to publish the package. If you have your own NuGet server then fill in the address in the Packages Sources field. If you're using nuget.org, leave it blank. You need to provide your API key which is stored in a password protected field and finally indicate which packages you want published. Here you can list each package individually or use wildcards. [Note: relative paths are allowed but at the time of writing this post, there was an issue and I was using the full path. This should be fixed soon].

If you want to publish to multiple sources, all you need to do is add another step. Note however that we did not have to specify an extra step to publish the sources to symbolsource.org. TeamCity will follow NuGet's convention and do this for you automatically.

5. AssemblyInfo Patcher

Although this step is optional I recommend you use it. The AssemblyInfo Patcher is a new Build Feature added to TeamCity which temporarily patches all your projects AssemblyInfo.cs files to update the version number, and then reverts it back after the build is complete. This allows your build number, artifacts, packages and assemblies to all have the same version number. Adding this option is as simple as selecting it from the main project configuration screen:

That's it. There's nothing more to it. With a few simple build steps we have now fully automated packaging and publishing NuGet packages. As I mentioned initially, if you've got your project on CodeBetter, you already have this feature enabled. If you're running your own server, just download the plugin and set it up. It's very simple.

Try it out and please give us your feedback!

YouTrackSharp and YouTrackForReSharper on JetBrains GitHub

Hadi Hariri — Wed, 17 Aug 2011 14:38:00 GMT

Just a quick note to say that I’ve transferred the YouTrackSharp project from my own account over to the JetBrains account on github. I’ve also pushed the initial spike of YouTrackForReSharper which is a plug-in for ReSharper to talk to YouTrack. We’re looking for contributors for this project, so if you’re up to it, fork away!

Machine.Specifications for ReSharper 6 now available

Hadi Hariri — Wed, 20 Jul 2011 14:16:00 GMT

Many, myself included, have been eagerly awaiting the release of the ReSharper Runner of Machine.Specification (MSpec) for ReSharper 6. I’m glad to announce that this is now available, which is the result of a team-effort between Victor Kropp, Chris Nicola, myself and of course Alexander Gross, long-time contributor and main maintainer of the MSpec project.

NuGet packages have already been updated to support ReSharper 6. The source code can also be obtained via SymbolSource.org if using NuGet or directly from Alexander’s GitHub account.

Installing the Runner in ReSharper 6

If you’re new to MSpec or have simply forgotten how to install the runner under ReSharper, here are some simple steps to use Mspec in your project and integrate it with ReSharper:

1. Run the command install-package Machine.Specifications (or Machine.Specifications-Signed if you want the signed version). If this is an existing project, issue the command update-package instead of install-package.

2. Inside the packages folder corresponding to Machine.Specifications, a tools folder is created with a series of assemblies and some batch files. There are a series of batch files named InstallResharperRunner.X.X. – VS20XX.bat where X’s correspond to the version of ReSharper and of Visual Studio. By executing the corresponding one, it will copy the assemblies to the ReSharper plug-in folder.

You can of course do the second step manually, by copying the Machine.Specifications.ReSharperRunner.X.Y files to the ReSharper Plugins folder, located either under the ReSharper bin folder in %Program Files%\JetBrains\ReSharperX\bin (for all users) or under %APPDATA%\JetBrains\ReSharperX\bin (user-specific settings).

With that you should be up and running.

Enjoy.

Coverage with TeamCity and dotCover with MSTest, NUnit or MSpec

Hadi Hariri — Fri, 10 Dec 2010 11:26:00 GMT

As some of you know, we recently shipped TeamCity 6 which includes, out of the box, a bundled version of dotCover. What this means is that you can now get coverage reports for your code easily, and of course, for free if you’re using the Professional version of TeamCity. The setup is quite easy if you are using MSTest and NUnit. For MSpec, you need to take a few additional steps.

Using MSTest / NUnit Runners

Normally build files consist of a series of tasks that involve compilation and running of tests. With TeamCity, you can separate some of these steps out into individual TeamCity Build steps, which is what we will be doing in this case (everything that we see here applies to both MSTest and NUnit).

Here is our build.xml (MSBuild) file:

As we can see, other than compiling a solution, which in this case consists of the actual application and the test assemblies, not much else going on.

[Note: this could have been done using the SLN as the Runner Type under TeamCity since this example build script does not do much else. In real scenarios however, build scripts do more than just call a solution (in fact normally you’d call projects not solutions)].

In TeamCity, we create a new build project and setup the VCS root. We then add a new Build Step which calls this MSBuild file:

Notice that all we are doing here is calling our MSBuild script. No coverage settings yet.

Next thing is to add an additional build step in TeamCity. This time, we are going to call MSTest as opposed to MSBuild:

(the sections cut out are blank).

In the .NET Coverage tool section we select JetBrains dotCover and then add the assemblies we want coverage for (just the name of the assembly) prefixing them with +: and filtering out those we do not want coverage for with –:.

That’s all there is to it. Once we run the Build, we should now see a new tab with Coverage Reports as well as a new Artifact which contains the Coverage files zipped up.

The Code Coverage tab goes into more detail:

We can even drill down into individual classes and examine the code coverage:

If we are using NUnit instead of MSTest, the only difference is there test runner we select when adding a new Build Step in TeamCity. Instead of MSTest we choose NUnit along with the version:

What about MSpec or my Specific Test Runner?

If we are using MSpec or a different test runner that is not supported directly by TeamCity, we can still get coverage reports; we just need to do a little bit of additional configuration. TeamCity has an API which allows us to send it messages when we want to interact with it (this is actually quite a powerful feature but out of scope for this post so please leave a comment if you’d like me to cover it in more detail). We can leverage this API to tell it when to start coverage and where to get the results from.

Here is the build script for MSpec:

We have created two targets. The second one (TeamCity) is the one we are interested in. This does a couple of things:

1. The first <Exec> runs all MSpec tests so that we can see the test results inside TeamCity. This is not strictly necessary for Code Coverage but usually build processes do display these results. The --teamcity option we are passing in to MSpec is for it to generate the system messages that are then fed to TeamCity (see point 3)

2. The second <Exec> is the one that runs dotCover. This uses a configuration file called dotCover.xml which we will examine further down. We pass in the c (or coverage) option when calling dotCover.

3. This is a message we send to TeamCity to tell it that we have run coverage. We indicate the tool we are using (dotcover in this case) and where the results are located. TeamCity uses this information to then display the results in the UI. This is one of the API messages mentioned earlier.

Finally we need to define the dotcover.xml file with out configuration for running dotCover (for detailed information on creating dotCover configuration files, see here and here):

In terms of TeamCity, we then just define our build step that calls out to the build script:

Notice how we do not specify .NET Coverage options explicitly. And if all goes well, we can see the coverage output just as before:

Summary

We can see that running code coverage is now pretty straightforward when using MSTest, NUnit or even a custom test runner. Most of what we have covered for MSpec will work with pretty much any test runner in terms of coverage (feel free to vote here for MSpec support).

With any build process, there are numerous ways of doing the same thing. I’m going to show you one of them. Based on your setup and needs you might want to do things differently. Fortunately TeamCity is flexible enough to allow for many scenarios.

One thing to be aware of is that dotCover creates some temporary files for the XmlSerailizer in the Temp profile folder. This normally is not a problem unless the folder does not exist. If you are running TeamCity under the SYSTEM account, make sure that the folder C:\Windows\system32\config\systemprofile\AppData\Local\Temp exists. This will probably change in future versions so to avoid any possible issues.

Enjoy!

Writing plug-ins for ReSharper: Part 2 of N

Hadi Hariri — Tue, 20 Jul 2010 21:02:00 GMT

[Finally I’ve managed to get the second part of the post on plug-ins. Sorry for the delay to everyone who was waiting. Appreciate your patience. And now I’ll resume my holidays!]

In the previous part of this series, we saw the basics of how to create a plug-in for ReSharper, install it and run it. We created a context action that would allow us to mark a public method as virtual (where applicable). However, this was done as an explicit action by the user, as such, you didn’t get any kind of hint or suggestion to do this. What we want to do now is make this a hint, so that highlighting appears under methods that could be made virtual. In this part we are going to expand on the same plug-in and convert it into a QuickFix.

What is a QuickFix?

Have you seen the little squiggly lines that appear in Visual Studio?

They usually indicate a Suggestion (field can be made read-only), Warning (possible null reference) or Error. ReSharper analyzes and can detect potential issues in the code (similar to what static checker of Code Contracts does). These are known as Highlights and they are related to QuickFixes in that usually a highlight has an QuickFix associated to it, which invokes a context action. This is usually done by placing the cursor on top of the highlighting and press Alt+Enter

Highlighting Daemons

In the gutter of the Visual Studio editor (right-side), ReSharper displays a series of warnings, errors and hints, which indicate potential issues on a specific file. These issues are detected by background processes known as Daemons. Since what we are looking for is for ReSharper to warn us of existing methods that could be made virtual, what we need to do is somehow hook into these daemons.

Step by Step Guide

The Daemons in ReSharper use the Visitor pattern to use act on elements, be it code, files, etc. The first step is to implement an IDaemonStage interface, which hold metadata about our daemon stage at at the same time acts as a factory for the actual process we are implementing.

[DaemonStage(StagesBefore = new[]  { typeof(LanguageSpecificDaemonStage) })]
public class MakeMethodVirtualDaemonStage: IDaemonStage
{
     public IDaemonStageProcess CreateProcess(IDaemonProcess process, DaemonProcessKind processKind)
     {
         return new MakeMethodVirtualDaemonStageProcess(process);
     }

     public ErrorStripeRequest NeedsErrorStripe(IProjectFile projectFile)
     {
         return ErrorStripeRequest.STRIPE_AND_ERRORS;
     }
}

There are two main methods to implement. The CreateProcess is what creates the actual process for us and the NeedsErrorStrip which indicates whether this daemon uses the gutter to display strips. The DaemonProcessKind parameter passed into the first method helps us discriminate on when this process should be executed, i.e. only during checking of visible (current) document, during solution wide analysis, etc.

The next step is to implement the process via the IDaemonStageProcess interface:

  public class MakeMethodVirtualDaemonStageProcess : IDaemonStageProcess
  {
      readonly IDaemonProcess _process;

      public MakeMethodVirtualDaemonStageProcess(IDaemonProcess process)
      {
          _process = process;

      }

      public void Execute(Action<DaemonStageResult> commiter)
      {
          if (_process.InterruptFlag)
          {
              return;
          }

          var file = _process.ProjectFile.GetPsiFile(CSharpLanguageService.CSHARP) as ICSharpFile;

          if (file != null)
          {
              var highlights = new List<HighlightingInfo>();

              var processor = new RecursiveElementProcessor<IMethodDeclaration>(declaration =>
              {

                  var accessRights = declaration.GetAccessRights();

                  if (accessRights == AccessRights.PUBLIC && !declaration.IsStatic && !declaration.IsVirtual &&
                      !declaration.IsOverride)
                  {
                      var docRange = declaration.GetNameDocumentRange();

                      highlights.Add(new HighlightingInfo(docRange, new MakeMethodVirtualSuggestion(declaration)));
                  }
              });

              file.ProcessDescendants(processor);

              commiter(new DaemonStageResult(highlights));
          }

      }


  }

The main meat of this class is in the Execute method. We first check to make sure that we’ve not received an interruption (Interrupt Flag raised) due to some external action. Next step is to get access to the current file (remember that we are visiting the entire visible document, not just a specific method). Having the file, we can now create a RecusiveElementProcessor* to perform a tree walk of the AST and perform the specific action on each element. The action to perform is declared as the lambda expression. Since we’re interested in the method declaration, the type is IMethodDeclaration (there are many others). If we look at the expression, we can see that it’s pretty much the same as that of Part 1, the only difference is that we add the results to the highlighting variable.

The HighlightingInfo class has a parameter which can be a Suggestion, Warning or Error, as explained previously. Since in our case we need a suggestion, we pass in the MakeMethodVirtualSuggestion:

[StaticSeverityHighlighting(Severity.SUGGESTION)]
public class MakeMethodVirtualSuggestion : CSharpHighlightingBase, IHighlighting
{
     public ICSharpTypeMemberDeclaration Declaration { get; private set; }

     public MakeMethodVirtualSuggestion(ICSharpTypeMemberDeclaration memberDeclaration)
     {
         Declaration = memberDeclaration;
     }

     public string ToolTip
     {
         get { return "Method could be marked as virtual"; }
     }

     public string ErrorStripeToolTip
     {
         get { return ToolTip; }

     }

     public override bool IsValid()
     {
         return Declaration.IsValid();
     }

     public int NavigationOffsetPatch
     {
         get { return 0; }
     }
}

This class is pretty simple. The main property to define is the ToolTip, which is the text that will show when we hover of the highlighting. The ErrorStripeToolTip is what’s displayed in the right-hand side gutter. Finally the Attribute StaticSeverityHighlighting is to indicate what type of tip it is (Warning, Error, etc.).

[*Note: In this case, the operation we want to perform is very simple. If we want a more complex scenario where we need to do some processing before and after each element is visited or have a more fine-grained control, we can implement the IRecurisveElementProcessor. I’ll cover this in another post].

To recap, right now we would have everything place to display highlighting when a method that could be made virtual is encountered. The only remaining part is to now be able to apply a QuickFix. This is in many ways similar to the ContextAction we saw in Part 1:

[QuickFix]
public class MakeMethodVirtualQuickFix : BulbItemImpl, IQuickFix
{
    readonly MakeMethodVirtualSuggestion _highlighter;

    // Takes as parameter the Highlighter the quickfix refers to
    public MakeMethodVirtualQuickFix(MakeMethodVirtualSuggestion highlighter)
    {
        _highlighter = highlighter;
    }

    // In the transaction we make the necessary changes to the code
    protected override Action<ITextControl> ExecuteTransaction(ISolution solution, IProgressIndicator progress)
    {
        _highlighter.Declaration.SetVirtual(true);

        return null;
    }

    // Text that appears in the context menu
    public override string Text
    {
        get { return "Make Method Virtual"; }
    }

    // Indicates when the option is available
    public bool IsAvailable(IUserDataHolder cache)
    {
        return _highlighter.IsValid();
    }
}

The MakeMethodVirtualQuickFix needs to implement the IBulbItem and IQuickFix interfaces. For ease of implementation we can inherit from BulbItemImpl. The constructor should take as parameter always the actual highlighting that has given way to invoking the QuickFix, in our case the MakeMethodVirtualSuggestion. Similar to the ContextAction we implemented in Part 1, the actual fix itself is pretty trivial. All we need to do is make the method virtual. How do we get access to the method? The easiest way is via the Declaration property of the highlighting passed in (this is a property we added before). The only thing left is to call the SetVirtual method on it. Since we are in the ExecuteTransaction method, ReSharper makes sure that any change made is executed as a whole.

The rest of the properties are trivial. Text returns the text of the QuickFix (what appears in the menu), and IsAvailable indicates when the QuickFix is available, which in our case is whenever the highlighting is valid.

The End Result

Once we compile the plug-in and place it in the corresponding Plugins folder under ReSharper\Bin, we’re done. Here’s the end result:

and invoking Alt+Enter on the highlighting gives us:

Summary

Extending ReSharper to create highlightings and quick fixes is pretty simple once you understand how all the pieces fall into place. Most of the code will usually be the same and what will vary will be the actual element processing to be performed and the corresponding QuickFix. As mentioned previously (in the Note), for complex scenarios, we can have more control over the tree walk and that’s something we’ll examine in a future post.

I’ve placed the code up on my github account so feel free to download it, play with it and ping me if you have any comments or questions. The code is updated to work with ReSharper 5.1

Show Covering Tests with dotCover

Hadi Hariri — Tue, 06 Jul 2010 20:58:00 GMT

One of the new features dotCover has added is the ability to find tests that cover a certain piece of code. Something remotely similar has been available in ReSharper, although it has been kind of an archaic solution (i.e. Find Usages on Method calls, locate Test assemblies in Result window).

dotCover makes this easier by providing quick access to this information and extends it in functionality.

Below we can see some tests from an MVC application. Let’s run Code Coverage on it using dotCover first.

Now let’s switch over to the Source Code and select some random source code, in this case the MembershipService.ChangePassword line in the ChangePassword action:

In order to see the tests that cover this line of code, we can either press the default key combination of Ctrl+Alt+K or select the option Show Covering Tests from the dotCover:

dotCover will then display a small window showing all the different tests that cover that line of code.

At this point, we can run the selected tests or add them to the existing ReSharper Test Runner session. This allows us to easily jump from specific sections of code to the corresponding tests and execute them instantly.

One minor note: The default key mapping conflicts with KeePass, but you can easily re-assign it via Visual Studio Tools | Options | Keyboard, or do as I did and change KeePass to Ctrl+Alt+P (P as in Password…makes more sense).

Zen Coding and ReSharper PowerToys

Hadi Hariri — Thu, 11 Mar 2010 11:25:00 GMT

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.

What are they?

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.

Where can I get them and how do I install them?

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!

What next?

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.

Profiling Apps 1 of N: The MVC ActionLink

Hadi Hariri — Tue, 09 Mar 2010 20:34:00 GMT

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.

Premature Optimization

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.

When it does boil down to code

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.

To Express or not Express

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.

The Project

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:

 <% for (int i = 0; i < 1000; i++)
{%>
  <%= Html.ActionLink("Link " + i, "Index", "Home")%><br />
  <%
} %>
 
<% for (int i = 0; i < 1000; i++)
{%>
  <%= Html.ActionLink<HomeController>(a => a.Index(), "Link " + i)%><br />
  <%
} %>
 

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.

Setting up dotTrace Profiler

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:

Sampling: dotTrace will do frequent analysis of calls stacks. It’s the least intrusive, has very little impact on performance, but gives approximate timing.
Tracing: dotTrace receives notifications from the CLR on entry/exit of methods. More precise timing and call information.
Line-by-Line: dotTrace logs times for every statement in methods. Most precise but also has higher impact on performance.

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).

Profiling our application

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.

Summary

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.

ASP.NET Support in ReSharper 5

Hadi Hariri — Wed, 20 Jan 2010 17:04:00 GMT

Although I mentioned briefly in the past some of the new features ASP.NET MVC features ReSharper 5 supports, I thought it would be a good idea to sum up the main ones in a single post and go into a little bit more detail on them.

ASP.NET

ReSharper ‘s support for ASP.NET is not restricted only to MVC.In fact, most of the new features are for general ASP.NET, be it WebForms (also known as Traditional, Classic, For Historical Purposes Only?) or MVC.

Go to File Member

As part of the code navigation features of ReSharper, you have the possibility to locate a file member, be it a method, property, class, etc. very easily by using the the Go To File Member (Alt+\) option. You can search instantly and hit Enter to navigate to the specific one. [For the record, I’m using the Visual Studio Keyboard Scheme. If you’re using IntelliJ (why?) go to the web site and download the PDF mapping files.]

Notice how it it looks for anything that matches the characters introduced, so for instance typing “Exc” would give us all those with the word “Exception”

Well you now have this functionality in ASPX, ASCX, ASAX and Web.config files also as of ReSharper 5!

The same goes for the File Structure tool Window (Ctrl+Alt+F).

Go To Related Files

Many times, an ASPX has references to other files, such as Cascading Style Sheets, Javascript Files, Master Pages and User Controls. You can now navigate to these files efficiently by using the Go To Related Files (Ctrl+Alt+F7)

Master Pages

Version 5 also adds support for Master and Content Pages. To begin with, we have added support for navigation. Using Go To Declaration (Ctrl+Left Mouse) on the ContentPlaceHolderID will take you from the Content Form/Page to the corresponding ContentPlaceHolder of the Master Page

If you are in the Master Page, you can navigate to all its inheritors (Shift+Alt+F12)

You can also create content place holders from usage. When defining a ContentPlaceHolderID that does not exist, you have the option to create it in the Master Page (Alt+Enter)

Last but not least, in a page that uses a master page, you can generate content place holders by pressing Alt+Ins

which in turn will bring up a dialog box for you to pick and choose what you want

User Controls

You can now navigate to user controls as well as automatically import the correct references.

File Generation

There are new code generation options for ASP.NET with version 5. By pressing Alt+Ins in the Solution Explorer, we are presented with a popup menu

where you can choose from a selection of items to generate. You can also access this menu from anywhere (not only in the Solution Explorer) by now pressing Ctrl+Alt+Ins. This is actually an awesome new addition to ReSharper 5 (Ctrl+Alt+Ins) and it removes even more friction when create new items!

We’re asked for a name (which is the base minimum required to create an item) and If the item selected requires more information, then we’ll be prompted accordingly. For example, when creating a WebForm with Master Page, it’s convenient to specify which Master Page we want to use. In this case, once the page has been created, we’ll be given a chance to provide this information

I have to say, that I love Ctrl+Alt+Ins in ReSharper 5.

Refactoring and Assistance

In terms of Refactoring and Coding Assistance there are a few new features. One of them is the auto-update of ending tags. If you have for instance a div tag, and want to change it to span, as you start typing span, the end tag is automatically updated to reflect the changes you’re making live.

If you have a series of elements that you want to surround within a tag, you can easily do this by selecting all the elements and choosing Surround with Template (Ctrl+E,U)

ASP.NET MVC

ReSharper 5 treats ASP.NET MVC as a first class citizen. As such, it now has knowledge of concepts such as Views, Controllers and Action.

Navigate to View

For those of you working with ASP.NET MVC, you might have noticed that Views are now underlined in Actions

When you click on the View with Ctrl+Left Mouse, you’ll be presented with a dropdown menu

Here you have two options. The first is to navigate to the source for the View method (navigation to external sources is another new feature of ReSharper 5). The second option is to go to the View. Although you can navigate to the View in Visual Studio by right-clicking and selecting Go To View, one advantage the underlining adds is that it serves as hint for non-existent views, as you can see in the action below, which doesn’t have a corresponding View file.

View discovery also works with named Views. If a named view exists, the string literal will be underlined

On the other hand, if it doesn’t exist, it will be highlighted as an error, once again providing you the benefit of discovering any missing views earlier on.

Action Links

Those of us who have worked with ASP.NET MVC applications, know the problems with using strings when defining ActionLinks. Not only do you run into issues when refactoring, but misspelling an action or controller causes unnecessary pain. Some of us, including myself, have often resorted to using the expression based Actions available in the MVC Futures library.

ReSharper 5 now provides Intellisense, preventing you from mistyping Actions and Controllers

Similar to named Views, if you define a non-existing Action, you will get it highlighted. The difference here is that by pressing Alt+Enter, ReSharper will create the Action for you (create based on usage)

And much like Views, you can now navigate to Actions and Controllers from an ActionLink by choosing Go To Declaration (Ctrl+Left Mouse) on the Action and Controller respectively.

User Controls

Navigation is also provided for User Controls

as well as Intellisense

Summary

I’ve outlined some of the main features that ReSharper 5 brings to the table in regard to ASP.NET. There are many smaller features that you can discover eventually as you play with it more. If you haven’t yet, make sure you download 5 from JetBrains. Don’t forget to follow ReSharper on Twitter if you want tips, tricks and latest info.

Writing plug-ins for ReSharper: Part 1 of Undefined

Hadi Hariri — Tue, 12 Jan 2010 13:27:00 GMT

ReSharper does a lot of things, but as they say, you can’t please all the people all of the time. However, one the great things about ReSharper is that it is quite extensible and there are already quite a number plug-ins available. Some of the better known ones are:

- StyleCop for ReSharper by Howard Van Rooijen

- TDD Productivity Plugin by Eric Hexter

- ReSharper Test Runner for MSpec by Alexander Groß

and of course there is also the repository of plug-ins available from the JetBrains site, where many of these are located.

Now I’m no expert on writing plug-ins for ReSharper, and the authors of the previous ones leave the bar quite high, but seeing that I actually now have the time to play with them, I’ve decided to do so by sharing my experiences with you in a series of blog posts.

The ReSharper API is pretty extensive and can be overwhelming as I’ve been discovering, so I want to try and take it slowly. This might mean that at times, the code is not always complete and might be missing a few checks for example, but will come in due course.

Everything that I’ll cover applies to version 5.0 which is currently in Beta. There have been some changes from previous versions so if you’re working with 4.5 some of the code might not work.

The First Plug-in

I was initially intending to write a useless plug-in for the first demo that didn’t do much, but after talking to Orangy (aslo known as Ilya) who commented on a tweet Jeremy Skinner had posted a few days back:

we decided to use it as the first sample.

I’m going to build up the sample over the next few series of posts, so the initial solution is not the ideal one or complete, but it will help introduce a few core concepts. Ideally this feature should be implemented as what’s known as a QuickFix but we’re first going to do it as a ContextAction.

ContextAction

So what exactly is a Context Action? It’s actions that can be applied based on the context (the name is quite descriptive). They shows up as items in a popup menu which is invoked using Alt+Enter (don’t use the mouse for this…it’s very unproductive).

What we want to do in this first version of the plug-in is to write a new action that makes methods that are public and not declared virtual, virtual, something NHibernate users would appreciate greatly. As mentioned previously, in this first version we’re going to add a context action.

1. Creating a plug-in assembly

ReSharper plug-ins are assemblies that are located in Plugins folder (by default %programFiles%\JetBrains\ReSharper\v5.0\Bin\Plugins). Each plug-in is in it’s own folder and doesn’t require any further registration. Therefore the first step is to create a class library which will host our context action.

2. Creating the Context Action Skeleton

In order to create a context action, we need to implement the IContextAction interface. This interface has one method IsAvailable which indicates to us if that particular action is available given the context, and a property of type IBulbItem[] which contains a series of bulb items. Each IBulbItem in turn has a property Text which is the text that appears next to the item in the context dropdown, and an Execute action, which is what happens when the item is selected. So as we can see, a context action can consist of more than one bulb item. An added benefit to this decoupling is the re-usability of bulb items. By implementing IBulbItem, we can potentially use it in more than once place (obviously if it makes sense).

Many times however, we only want one bulb item per action, and to somehow simplify the process, we can inherit from the BulbItemImpl class. This class defines an abstract Text property that represents the text of the bulb item, and also has an ExecuteTransaction member which is where our code is executed. We’ll see the difference between this method and Execute shortly.

       public class MakeMethodVirtualContextActions: BulbItemImpl, IContextAction 
{ 
    protected override Action<ITextControl> ExecuteTransaction(ISolution solution, IProgressIndicator progress) 
    { 
        throw new NotImplementedException(); 
    } 
  
    public override string Text 
    { 
        get { throw new NotImplementedException(); } 
    } 
  
    public bool IsAvailable(IUserDataHolder cache) 
    { 
        throw new NotImplementedException(); 
    } 
} 
     

Before implementing any of the methods, there’s one thing we need to do. ReSharper requires that context action have a constructor with a parameter that implements a IContextActionDataProvider. This parameter is actually useful to use to provide information about the context as we’ll see shortly. Therefore, we need to add a constructor to the previous code (lines 6-9). Since our action is only for C#, we will use a ICSharpContextActionDataProvider. We then save this provider for later use (line 3). What we’re effectively doing here of course is nothing more than dependency injection. The plumbing (passing in the correct provider) is taken care of for us by ReSharper.

       public class MakeMethodVirtualContextAction : BulbItemImpl, IContextAction 
{ 
    readonly ICSharpContextActionDataProvider _provider; 
  
  
    public MakeMethodVirtualContextAction(ICSharpContextActionDataProvider provider) 
    { 
        _provider = provider; 
    } 
    protected override Action<ITextControl> ExecuteTransaction(ISolution solution, IProgressIndicator progress) 
    { 
        throw new NotImplementedException(); 
    } 
  
    public override string Text 
    { 
        get { throw new NotImplementedException(); } 
    } 
  
    public bool IsAvailable(IUserDataHolder cache) 
    { 
        throw new NotImplementedException(); 
    } 
} 
     

3. Defining Availability

The next step is to define when our action is available. In order to do so, we need to implement the IsAvailable method. In our case, we want to convert methods that are public and not virtual, to virtual. We therefore need to identify methods that are public and not virtual. We also need to filter out static methods. In order to get access to the current context we’re in, we can use the provider we injected in via the constructor. The provider has a GetSelectedElement method which corresponds to the element the caret is on. Since we’re interested in a method, we can invoke this function, requesting back a method declaration. If the caret is in the context of a method (i.e. header, body), it will return this information. If it’s not, it will return null.

If we have a valid method declaration, the next step is to find out if it is public. We do that by invoking GetAccessRights [In later series we’ll see that further checks are necessary here]. If it is public, we then need to check whether it is a static method, an override or already virtual. Based on that, we return true or false, indicating whether the action is available in the current context.

       public bool IsAvailable(IUserDataHolder cache) 
{ 
    var item = _provider.GetSelectedElement<IMethodDeclaration>(false, true); 
  
    if (item != null) 
    { 
        var accessRights = item.GetAccessRights(); 
  
        if (accessRights == AccessRights.PUBLIC && !item.IsStatic && !item.IsVirtual && !item.IsOverride) 
        { 
            return true; 
        } 
    } 
    return false; 
} 
     

4. Performing the action

When the action is available and the user selects it, what we need to do is make the method virtual. This is done in the ExecuteTransaction method. Since we are going to modify the code, we need to make sure that the file is writable. Normally this would be done by invoking a call to a method named EnsureWritable. However, inside the method ExecuteTransaction, this is done for us, so we don’t have to worry about it. This is one of the differences between ExecuteTransaction and IBulbItem.Execute.

So how do we go about modifying code in ReSharper? Well remember that refactoring code is ReSharper’s daily bread. It’s what it does. As such, there’s a ton of infrastructure in place to allow us to do modify code easily. In fact, making a method virtual is as easy as calling a method, as shown below.

       protected override Action<ITextControl> ExecuteTransaction(ISolution solution, IProgressIndicator progress) 
{ 
    var method = _provider.GetSelectedElement<IMethodDeclaration>(false, true); 
  
    if (method != null) 
    { 
        method.SetVirtual(true); 
    } 
  
    return null; 
} 
     

5. Testing the plug-in

The only thing left to do is test that it works (writing unit tests for plug-ins is something we’ll cover in the future). One option is to copy the assembly to the plug-in folder for ReSharper and restart Visual Studio. However, in order to be able to debug it, what we can do is set the project properties to start an external program, which is non other than devenv.exe, and pass as parameter to it /ReSharper.Plugin <Path_to_Plugin_Assembly>, instructing ReSharper to load a specific plug-in.

How does ReSharper know which classes in the assembly are context actions? The easiest way is to decorate these with the ContextAction attribute

       [ContextAction(Group="C#", Name = "MakeMethodVirtual", Description = "Adds context action to make methods virtual")] 
    public class MakeMethodVirtualContextAction : BulbItemImpl, IContextAction 
    { 
   
     

This information is also what appears under ReSharper –> C# –> Context Actions

Now all that’s left is to try it out. Write a new class, add a few methods and check to see it’s all working correctly.

Public static method (not available)

Private method (not available)

Public method (option available)

What’s next?

In this first part we’ve seen the basics of writing plug-ins for ReSharper. In the next blog post, we’ll extend the example to also include properties and we’ll change it to be a QuickFix as opposed to a context action. This means that we’ll get some nice highlighting by ReSharper telling us something can be changed (similar to when you have something named incorrectly for instance), thus being more *in your face*.

There’s so much more to see than what’s here, and gradually we’ll drill more into each of the different areas, examining parameters, return values, etc. Until then, Happy ReSharping (did I just coin that? Too lame?)

Dynamic objects and ReSharper

Hadi Hariri — Tue, 24 Nov 2009 19:41:00 GMT

As you might have heard by now, C# 4.0 (or is it just 4?…) comes with a new keyword: dynamic. This means that you could do something like the following:

Simply put, ExpandoObject is a class that allows you to add and remove members at runtime. This allows us to call methods that are resolved at runtime. As such, the previous code will compile.

Just as you can declare methods, you can also declare properties:

This no doubt can come in handy when working with ViewModels and ASP.NET MVC.

However, there is one minor problem with dynamic objects: you lose intellisense, which means that if in your view, instead of typing dynaCustomer.FirstName, you type dynaCustomer.FristName, you won’t get any errors until you run the app.

And that’s where ReSharper can help:

This is the same code, but with ReSharper activated inside Visual Studio 2010! I typed the FirstName property for the first time. After that, I have full intellisense support for it. The same would apply to methods:

That puts dynamic into perspective.

Getting your OSS binaries with Horn

Hadi Hariri — Mon, 23 Nov 2009 08:54:00 GMT

Recently Billy McCafferty wrote a post on Horn, a package manager that Paul Cowan and Dave the Ninja have developed, similar to the idea of Ruby’s Gem. Although it’s a step in the right direction, it does have issues. To be able to use it, you need to download Horn and build it. But not only that, you also need to install Subversion, Git, Powershell, Rake, PSake, Cake, Fake…and a whole slew of SCM’s and build tools. Why? Because Horn builds from source. As such, it needs to access the SCM a specific project uses, download the files locally and run the build script. Since OSS projects are free to choose what build script they use, that also adds to the complexity. Some are happy with MSBuild, which isn’t normally an issue since it’s part of every .NET install. However, others use Rake, which in turn requires Ruby. You get the picture…

Although this isn’t necessarily an issue for some people, for others, it is. Forgetting for a moment scenarios such as those imposed by IT departments on corporate networks (permissions to install software, firewall, etc..), there are many that are not too comfortable with building from source, something beyond running an MSBuild file or compiling a VS solution inside the IDE.

Welcome to Horn Server-Side

In order to ease some of these concerns, the Horn team developed a server-side solution. A service now takes care of figuring out all dependencies and building packages and since it does this on a scheduled basis, it saves you the time of having to wait for a project to be built. This also saves you from having to install anything on your machine, including SCM’s and build tools. In fact, you don’t need to install anything if you don’t want to. For you to interact with this server, Dave built an ASP.NET MVC application that shows all the OSS packages in their respective categories. For each package there is normally the official released version and the trunk. iMeta has gracefully offered to host the server up in clouds. Go see for yourself.

If you prefer a command line version, I hacked one together in a morning and it’s available from the Horn repository. This allows you to issue commands like:

horn-get –u http://hornget.net –c orm –d nhibernate-2.1

which will download NHibernate 2.1 zip for you with the necessary binaries.

Take a look, experiment and provide feedback to the Horn team. There is still room for improvement, but no doubt, Horn is helping remove some of the barriers in the adoption of Open Source.