Nov 012013
 

A lot of people involved in web development (including myself) have hit a problem with the latest versions of jQuery. Right now there are two versions of jQuery available on NuGet – 1.9.1 and 2.0.x. According to the jQuery team, both versions will be developed in the future and for developers targeting web applications the recommended version is 1.9.1 instead of 2.0 (jQuery UI for example does not work with v2.0).

By default NuGet will install the latest version of jQuery automatically. Of course, if you use the Package Manager Console, you can force version 1.9.1. But as soon as you update and you forget to do a safe update (see my previous post here on how to do that), you are stuck with version 2.0.

To prevent such issues, an easy solution is to force the package to stay under version 2.0 by changing it in the packages.config file like this:

<package id="jQuery" version="1.9.1" targetFramework="net45" allowedVersions="[1.9.1,2)" />

The right parenthesis means that the allowed versions should go up to (but not including) version 2.0

In the nasty situation when you’ve already updated the version and you have also dependencies on jQuery, you can downgrade the version using the following Package Manager Console commands:

Uninstall-Package jQuery –Force Install-Package jQuery -Version 1.9.1

Remember to change the packages.config afterwards.

Sep 242013
 

This is a follow-up on my previous post with a slight variation of the command. If your package source contains pre-release packages, then the previous command is not enough. The change is minor, though:

Get-Package –Updates -IncludePrerelease | ForEach-Object { Update-Package $_.Id –Safe -IncludePrerelease }

This will include all prerelase packages in the update.

Apr 152013
 

there are situations when you need to update the referenced NuGet packages and use a safe update.Safe update means that the packages are updated to the latest version that has the same major version as the current one. For example: suppose the project has a reference to “MyPackage” version 1.2.3.4. In the NuGet repository there is a MyPackage version 1.2.7.8 and one with version 2.0.0.0.

A safe update would update the package to the version 1.2.7.8, while a regular update would update it to the latest version (2.0.0.0). While the safe update can be done using the package manager UI from Visual Studio, the safe update requires using the powershell console directly.

Fortunately, there is a very easy way of updating safely all references. Open the Package Manager Console (Tools->Library Packager->Package Manager Console) and type the following command:

Get-Package –Updates | ForEach-Object { Update-Package $_.Id –Safe }

Jul 282011
 

I find that with the extension support in VS2010, programmers don’t really have an excuse for not using tools to increase their productivity and to increase the overall quality of their work. I am a really lazy programmer, in the sense that I don’t’ like to do repetitive boring tasks. Extensions are one of the solutions to being a happy lazy programmer. The other one is writing quality code, but that’s another story. So here is a list of all Extensions that I use in day-to-day work

 My list of Visual Studio 2010 Extensions
Continue reading »

May 182011
 

When doing TDD or at least unit testing, it is necessary to know how much of your code is covered by tests and, more importantly, which code isn’t. Since we migrated to NUnit the integrated Visual Studio 2010 code coverage does not do the job anymore for us (although I’ve found several articles on how to enable it, for some reason I couldn’t get it running).

There are two tools that you can use instead – one of them is NCover, which is a great tool but not free. The other one is PartCover, which is a free code coverage tool. I’ve opted to go with the latter. The main problem with PartCover is the almost non-existent documentation. After several hours of trying out different combinations of options I finally got it running and it does it job really good.

Continue reading »

May 182011
 

 

One of our main requirements when performing the migration was to have the same level of integration with our Team Build system. This means that the build should run all tests and fail if any test fails. Also we should be able to see in the build log which tests have failed.

This step is the most complicated one so here is a quick breakdown of all the steps involved:

  1. Setting up the build server
  2. Changing the build template
  3. Add a new ForEach sequence to iterate through all test assemblies
  4. Add a sequence to run all tests in a single test assembly
  5. Invoke NUnit
  6. Publish NUnit results
  7. Mark the build as broken if not all tests pass
  8. Modify the workflow to support projects without a test settings file
  9. Check in the build template file.

Continue reading »

May 182011
 

 

I am working in a large WPF project that is in a continuous evolution. Initially when we started the project we didn’t have any kind of unit testing in mind, then later we switched to an (almost) TDD approach. Since we use TFS for source control and automated builds, the natural decision was to use MSUnit as the test framework. Although this approach has some benefits, after the project has grown in size we have reached several limitations.

Continue reading »

May 172011
 

 

I often work on various branches of the same project (using TFS). This means that I have folders setup like:

[root]/Project

[root]/Branch A/Project

[root]/Branch X/Project

Sometimes I have to keep multiple Visual Studio instances open at the same time with branches of the same project and because by default VS2010 only displays the solution name in the title bar, switching between different windows can become very confusing.

Continue reading »