Monthly Archives: December 2011

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

 

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

 

image 

 

or to the Action and/or Controller

 

image

Intellisense and Create From Usage

Ability to have Intellisense when providing Actions/Controllers

 

image

 

as well as the possibility of creating from usage

image

 

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

 

image

 

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

 

image

 

and here’s the header for a custom ActionLink

image 

 

(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:

 

image

 

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

 

image

 

That’s all there is to it.

Setting up TeamCity as a native NuGet Server

 

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.

image

 

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:

 

  1. Setup your own NuGet repository by downloading and installing the code that nuget.org for instance
  2. 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

 

image

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

 

image

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

 

image

 

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

 

image

 

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

 

image

 

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:

 

image

 

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:

 

image

 

 

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.