But it works on my PC!

The random thoughts of Richard Fennell on technology and software development

No error detail when using VMPrep

When using VMPrep to setup a VM for use in a Lab Management system I got the error cross at the bottom of the dialog

image

Not too much help, usually there is a link to the log file or a message.

If you look in the log file in c:\user\[name]\Appdata\Roaming\LMInstaller.txt you see that the path to the Patches folder is invalid.

This is fixed by editing the VMPrepTool\VMPrepToolLibrary\Applications.XML file and correcting the path (which I had made a typo in)

Using Nuget and TFS Build 2010

At one of our recent events I was asked if I had any experience using Nuget within a TFS 2010 build. At the time I had not, but I thought it worth a look.

For those of you who don’t know Nuget is a package manager that provides a developer with a way to manage assembly references in a project for assemblies that are not within their solution. It is most commonly used to manage external commonly used assemblies such a nHibernate or JQuery but you can also use it manage your own internal shared libraries.

The issue the questioner had was that they had added references via Nuget to a project

image

Their project then contained a packages.config file that listed the Nuget dependencies. This was in the project root with the <project>.csproj file.

<?xml version="1.0" encoding="utf-8"?>
<packages>   <package id="Iesi.Collections" version="3.2.0.4000" />   <package id="NHibernate" version="3.2.0.4000" />
</packages>

This packages.config  is part of the Visual Studio project and so when the project was put under source control so was it.

However, when they created a TFS build to build this solution all seems OK until the build ran, when they got a build error along the lines

Form1.cs (16): The type or namespace name 'NHibernate' could not be found (are you missing a using directive or an assembly reference?)
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets (1490): Could not resolve this reference. Could not locate the assembly "Iesi.Collections". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets (1490): Could not resolve this reference. Could not locate the assembly "NHibernate". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.

Basically the solution builds locally but not on the build box, the assemblies referenced by Nuget are missing. A quick look at the directory structure show why. Nuget stores the assemblies it references in the solution folder, so you end up with

Solution Directory
      Packages – the root of the local cache of assemblies created by Nuget
      Project Directory

If you look in the <project>.csproj  file you will see a hint path pointing back up to this folder structure so that the project builds locally

<Reference Include="NHibernate">
      <HintPath>..\packages\NHibernate.3.2.0.4000\lib\Net35\NHibernate.dll</HintPath>
</Reference>

The problem is that this folder structure is not known to the solution (just to Nuget), so this means when you add the solution to source control this structure is not added, hence the files are not there for the build box to use.

To fix this issue there are two options

  1. Add the folder to source control manually
  2. Make the build process aware of Nuget and allow it to get the files it needs as required.

For now lets just use the first option, which I like as in general in do want to build my projects against a known version of standard assemblies, so putting the assemblies under source control is not an issue for me. It allows me to easily go back to the specific build if I have to.

(A quick search with your search engine of choice will help with the second option, basically using the nuget.exe command line is the core of the solution)

To add the files to source control, I when into Visual Studio > Team Explorer > Source Control and navigated to the correct folder. I then pressed the add files button and added the whole Packages folder. This is where I think my questioner might have gone wrong. When you add the whole folder structure the default is to exclude .DLLs (and .EXEs)

image

If you don’t specifically add these files you will still get the missing references on the build, but could easily be thinking ‘ but I just added them!’, easy mistake to made, I know I did it.

Once ALL the correct files are under source control the build works as expected.

Seeing loads of ‘cannot load load assemblies’ errors when editing a TFS 2010 build process workflow

I have been following the process in the ALM Rangers build guide and in the Community Build Extensions to edit a build process workflow. Now I am sure this process was working until recently on my PC (but we all say that don’t we!), but of late I have found that when the .XAML workflow is loaded into Visual Studio I see loads of warning icons. If I check the list of imported namespaces many of them also have warning icons which if the icons are clicked they say the assembly cannot be found.

image

Now all these errors did not stop the editing process working. What I found was that if I made an edit in the graphical designer for the workflow or edited a property of an activity then my Visual Studio instance locked for about 20 seconds and it was fine (whilst there was loads of disk activity). I also noticed I got no intellisense when setting properties. Not a great position to be in but at least I could make some edits, if only slowly.

Using Process Monitor I could see that Visual Studio was scanning folders for the files when loading the XAML workflow, but not finding them.

The fix is actually simple. In the project that is being used as a container for the workflow being editing, make sure you reference the missing assemblies. These can be found in one of the following folders

  • C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE
  • C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies
  • C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\ReferenceAssemblies\v2.0

On my PC most of the assemblies were in the ReferenceAssemblies folder, not the first two, but on checking another PC at my office they were present in the PrivateAssemblies (which VS does scan)

Not sure why this has stopped working, what removed the files from my PrivateAssemblies folder, the only thing I can thing that I did was to install the Dev11 preview, But can’t see how this should have any effect.