JetBrains .NET Tools Blog

Using dotPeek, we can peek into assemblies by downloading symbols or by decompiling them. Out of the box, we can also open NuGet packages stored locally. But what about NuGet packages that we haven’t downloaded yet? Well… there’s a plugin for that!

The plugin is available for download. Extract the ZIP file contents and run the appropriate batch file for your version of dotPeek, e.g. Install-NuPeek.1.0.bat for dotPeek 1.0, or Install-NuPeek.1.1.bat for dotPeek 1.1. The plugin is compatible with dotPeek 1.0 and the dotPeek 1.1 EAP. Source code for this plugin is available on GitHub.

After downloading and installing the plugin, dotPeek features a new toolbar icon as well as two new menu items under the File menu. The File | Open from NuGet… menu entry allows us to download and open a NuGet package from any NuGet repository out there. The File | Open NuGet packages.config… menu entry allows us to open all NuGet packages defined in a packages.config file.

Using the toolbar button, we can search for a NuGet package we want to load and decompile using dotPeek. We can download packages from the official NuGet gallery as well as any other NuGet repository out there such as your TeamCity server.

We can search for packages and open them. Using the Load dependencies checkbox, we can automatically download dependencies for the selected package as well. Once downloaded, dotPeek will display the NuGet package and download symbols or decompile contained assemblies.

In a future blog post, we’ll dive into how we can create plugins for dotPeek. If you can’t wait, the sources for this plugin are available on GitHub. In the meanwhile, download the dotPeek EAP and give it a go!

We’ve all been there, someone calls you about the fact that the application is slow. No matter how hard you try, it’s impossible to reproduce the issue on your development machine: the issue only occurs in production. What do you do?

dotTrace makes it really easy to attach a profiler to a remote application. We’re now providing a NuGet package which makes it even easier to get your production application profiled.

Step 1: Install-Package dotTrace.Performance.Remote

Using the Package Manager Console or by using the Manage NuGet Packages dialog, you will be able to install the dotTrace Performance NuGet package into your project.

This NuGet package will verify if you have dotTrace installed on your system. If that’s not the case, it will ask you if you want to download a trial version from the JetBrains website.

The NuGet Package generates the files required for remote profiling from the instance of dotTrace installed on the computer, which varies based on the version. All this is done automatically, but it does require that you have dotTrace installed. Note that the NuGet package currently works with dotTrace Performance 5.2 and 5.3 EAP.

Step 2: Enable-DotTrace

In the Package Manager Console within Visual Studio, we’re adding two commands:

• Enable-DotTrace, which configures your application for profiling with dotTrace
• Disable-DotTrace, which removes the profiler assemblies from your application

To profile your application, simply invoke Enable-DotTrace:

After invoking this command, you will see some assemblies being added to your project. You can now deploy this application to production and start profiling.

Step 3: Profile application

Once you’ve deployed your application, it’s easy to attach dotTrace Performance to it remotely. The only thing you need is the URL where it lives. Simply attach to a remote application and specify the URL, e.g. http://myapp.prod.example.org/AgentService.asmx.

After connecting to the remote profiler, simply attach dotTrace Performance to the process you wish to profile.

Once attached to the remote process, you can work with dotTrace the way you are used to working with it: get a snapshot and analyze the results. After determining the root cause and deploying a fix, you can repeat the process to collect another snapshot and verify that you have resolved the performance problem.

Generally speaking, ReSharper and NuGet get along just fine, happily ignoring each other. NuGet automates downloading, extracting and referencing third party assemblies. ReSharper simply uses those assemblies, without needing to know how they were referenced. The assemblies’ metadata is available for use in IntelliSense, importing namespaces, type navigation, etc.

Unfortunately, there is an overlap where this blissful ignorance can cause problems.

ReSharper has a quick-fix that appears when you use a type that isn’t referenced in the current project. If that type lives in an assembly referenced in another project, ReSharper will offer to add a new reference to this assembly, but it doesn’t use NuGet to do this. Fortunately, we have just released a plugin that will add support for this.

To demonstrate, imagine you have a solution with a couple of projects, one of which is a test project. You want to use xUnit.net, and so you add the “xUnit.net” and “xUnit.net: extensions” packages with NuGet. This adds xunit.dll and xunit.extensions.dll as references. The files live in the packages\xunit.1.9.1\lib\net20 and packages\xunit.extensions.1.9.1\lib\net20 folders.

Later, you add a new project. This is also going to be a test project, and you’re so excited about the code that you start typing before you add any references:

Since you haven’t referenced xunit.dll, ReSharper marks the use of FactAttribute as an error. If you position the cursor on the [Fact] statement, you get a quick-fix (as shown by the red light bulb icon) offering you the option to “Reference ‘xunit’ and use ‘Xunit.FactAttribute’”:

If you select this, ReSharper will add a direct reference to packages\xunit.1.9.1\lib\net20\xunit.dll, and will not use NuGet to do so. This means NuGet’s metadata (packages.config) is not updated, and NuGet doesn’t get a chance to run any install scripts.

ReSharper shouldn’t bypass NuGet like this, and this is an outstanding and well voted issue on our YouTrack instance.

Today, we’re releasing a plugin that adds NuGet support for this situation. Once you’ve installed the plugin, you won’t see anything different – the same menu is displayed – but when you select the “Reference ‘xunit’ and use ‘Xunit.FactAttribute’” option, it invokes NuGet, which adds the references, runs any scripts and creates/updates packages.config.

And since NuGet is doing the installing, it will also install any dependencies. If you repeat the same scenario with xUnit’s TheoryAttribute (which provides parameterised testing), NuGet installs the xunit.extensions package, which in turn causes the xunit package to be installed. Previously, ReSharper would just have added a reference to xunit.extensions.dll, and then offered another quick-fix to add the reference to the required xunit.dll.

It should be noted that neither ReSharper nor NuGet are downloading any packages here. ReSharper is only offering to import types that it knows about from references in other projects, which means the packages are already downloaded and referenced elsewhere in the solution. This plugin just ensures that the normal NuGet installation process is followed.

The plugin is Open Source, and is available on GitHub. You can download a pre-built version: simply extract and run the appropriate batch file for your version of ReSharper. It supports 7.1 and 6.1.1 (if you’re still on 7.0, there’s no excuse: get the free upgrade to 7.1 now!). So download it, use it, report issues and feature requests, or fork it and contribute!

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!