But it works on my PC!

The random thoughts of Richard Fennell on technology and software development

Release Manager 2015 stalls at the ‘uploading components’ step and error log shows XML load errors

Whilst seting up a Release Management 2015.1 server we came across a strange problem. The installation appears to go OK. We were able to install the server and from the client created a simple vNext release pipeline and run it. However, the release stalled on the ‘Upload Components’ step.

Looking in event log of the VM running the Release Management server we could see many many errors all complaining about invalid XML, all in the general form

 

Message: Object reference not set to an instance of an object.: \r\n\r\n   at Microsoft.TeamFoundation.Release.Data.Model.SystemSettings.LoadXml(Int32 id)

 

Note: The assembly that it complaining about varied, but all Release Management Deploayer related.

We tried a reinstall on a new server VM, but got the same results.

Turns out issue was due to the service account that the Release Management server was running as; this was the only thing common between the two server VM instances. We swapped to use ‘Network Server’ and everything lept into life. All we could assume was that some group policy or similar settings on the service account was placing some restriction on assembly or assembly config file loading.

vNext Build editor filePath control always returns a path even if you did not set a value

You can use the filePath type in a vNext VSTS/TFS task as shown below 

{
     "name": "settingsFile",
     "type": "filePath",
     "label": "Settings File",
     "defaultValue": "",
     "required": false,
     "helpMarkDown": "Path to single settings files to use (as opposed to files in project folders)",
     "groupName":"advanced"
   }

to present a file picker dialog in the build editor that allows the build editor to pick a file or folder in the build’s source repository

image

While doing some task development recently I found that this control did not behave as I had expected

  • If a value is explicitally set then the full local path to selected file or folder (on the build agent) is returned e.g. c:\agent\_work\3\s\yourfolder\yourfile.txt – just as expected
  • If you do not set a value, or set a value then remove your setting when you edit a build, then you don’t get an empty string, as I had expected. You get the path to the BUILD_SOURCESDIRECTORY e.g. c:\agent\_work\3\s – makes sense when you think about it.

So, if as in my case, you wanted to have specific behaviour only when this values was set to something other than the repo root you need to add some guard code


if ($settingsFile -eq $Env:BUILD_SOURCESDIRECTORY )
{
    $settingsFile = ""
}

Once I did this my task behaved as a needed, only running the code when the user had set an explicit value for the settings file.

A VSTS vNext build task to run StyleCop

I have previously posted on how a PowerShell script can be used to run StyleCop as part of vNext VSTS/TFS build. Now I have more experience with vNext tasks it seemed a good time to convert this PowerShell script into a true task that can deploy StyleCop and making it far easier to expose the various parameters StyleCop allows.

To this end I have written a new StyleCop task that can be found in my vNext Build Repo, this has been built to use the 4.7.49.0 release of StyleCop (so you don’t need to install StyleCop in the build machine, so it works well on VSTS).

To use this task:

  1. Clone the repo
  2. Build the tasks using Gulp
  3. Upload the task you require to your VSTS or TFS instance

Once this is done you can add the task to your build. You probably won’t need to set any parameters as long as you have settings.stylecop files to define your StyleCop ruleset in the same folders as your .CSPROJ files (or are happy default rulesets).

If you do want to set parameters your options are:

  • TreatStyleCopViolationsErrorsAsWarnings - Treat StyleCop violations errors as warnings, if set to False any StyleCop violations will cause the build to fail (default false).

And on the advanced panel

  • MaximumViolationCount - Maximum violations before analysis stops (default 1000)
  • ShowOutput - Sets the flag so StyleCop scanner outputs progress to the console (default false)
  • CacheResults - Cache analysis results for reuse (default false)
  • ForceFullAnalysis - Force complete re-analysis (default true)
  • AdditionalAddInPath - Path to any custom rule sets folder, the directory cannot be a sub directory of current directory at runtime as this is automatically scanned. This folder must contain your custom DLL and the Stylecop.dll and Stylecop.csharp.cs else you will get load errors
  • SettingsFile - Path to single settings files to use for all analysis (as opposed to settings.stylecop files in project folders)

 

image

 

When you run the build with the new task you sould expect to see a summary of the StyleCop run on the right

image

A new vNext task to run StyleCop

Update 6 Feb 2016 - I have made some major changes to this task to expose more parameters, have a look at this post that details the newer version

Today a good way to pull together all your measures of code quality is to run SonarQube within your automated build; in a .NET world this can show changes in quality over time for tools such as FxCop (Code Analysis) and StyleCop. However sometime you might just want to run one of these tools alone as part of your automated build. For Code Analysis this is easy, it is built into Visual Studio just set it as a property on the project. For StyleCop it is a bit more awkward as StyleCop was not designed to be run from the command line.

To get around this limitation I wrote a command line wrapper that could be used within a build process, see my blog post for details of how this could be used with vNext build.

Well that was all best part of a year ago. Now I have more experience with vNext build it seems wrong to use just a PowerShell script when I could create a build task that also deploys StyleCop. I have eventually got around to writing the task which you can find in my vNextBuild repo.

Once the task is uploaded to your TFS for VSTS instance, the StyleCop task can be added into any build process. The task picks up the file locations from the build environment variables and then hunts for StyleCop settings files (as detailed in my previous post). The only argument that needs to be set is whether the buidl should fail if there are violations

 

image

Once this is all setup the build can be run and the violations will be shown in the build report, whether the build fails or passes is down to how you set the flag for the handling of violations

image

.

Follow up from my session at the Black Marble Tech Update 2016

There have been some requests for more information about the areas I convered in my presentation at the Black Marble Tech Update 2016 that we held last week.

I could send out slides, but I think it is far more useful to point you at the ‘live’ resource on the Internet. The key reason for this is that the whole of the Visual Studio family is now being released at a ‘cloud cadence’ i.e. new features are appearing rapidly, so anything I write will soon be out of date. Better to look at the live sources where possible.

Hope you find these useful pointers

Fixing cannot load dashboard issues on BlogEngine.NET using sub blog aggregation

As I discovered during my BlogEngine upgrade, there is an effort within the project team to focus the codebase on three possible usage models on any given BlogEngine server instance:

  • Single blog with a user – a personal blog (default)
  • Single blog with many users – a team/company blog
  • Many blogs each with a single user – a set of related blogs that can be agregated togther

I needed the third option, problem was in its history our blog has been both of the other two types, so I have multiple user accounts for each blogs, and login usernames are repeated between individual blogs on the server.

This is not fundamentally an issue for a server running in the third mode, except on the primary blog that is setup to provide agregation of all the other blogs.  Even here, on a day to day basis, it is not an issue either, basic post RSS aggregation is fine. However, when you login as an administration user and try to access the dashboard you get the error

Item has already been added. Key in dictionary: 'displayname' Key being added: 'displayname'

The workaround I have used in the past was to temporarily switch off blog aggregation whenever I needed to access the primary blog dashboard – not the best solution.

After a bit of investigation of the codebase I found that this issue is due to the fact we had users  called ‘admin’ on the primary and all the child blogs. The fix I used was a bit of SQL to do some user renaming from ‘admin’ to ‘adminblogname’ . I needed to rename the username in a few tables.

AS USUAL BEWARE THIS SQL, MAKE SURE YOU HAVE A BACKUP BEFORE YOU USE IT, IT WORKS FOR ME BUT I MIGHT HAVE MISSED SOMETHING YOU NEED


update p
set p.SettingValue = concat (p.SettingValue , ' ', b.BlogName)
from be_Profiles p
    inner join be_Blogs b on
        b.BlogID = p.BlogId
where
SettingName ='displayname' and
SettingValue = 'admin';

update p
set p.UserName = concat (p.UserName , b.BlogName)
from be_Profiles p
    inner join be_Blogs b on
        b.BlogID = p.BlogId
where
username= 'admin';

update u
set u.UserName = concat (u.UserName , b.BlogName)
from be_Users u
    inner join be_Blogs b on
        b.BlogID = u.BlogId
where
username = 'admin';

update r
set r.UserName = concat (r.UserName , b.BlogName)
from be_UserRoles r
    inner join be_Blogs b on
        b.BlogID = r.BlogId
where
username = 'admin';

 

This is not a problem specific to admin users, any username duplication will cause the same error. This basic SQL script can be modified to fix any other user accounts you might have username clashes on.

Once this SQL was run I was able to login to the dashboard on the primary blog as expected.

Upgraded to BlogEngine.NET 3.2

I have just completed the upgrade of this blog server to the new release 3.2 of BlogEngine.NET. I did a manual upgrade (as opposed to the automated built in upgrade) as I needed to make a few changes from the default settings. The process I used followed the upgrade process document

  1. Downloaded the latest release and unzip the folder
  2. Run the SQL upgrade script (in /setup/sqlserver folder), this adds some new DB constraints
  3. Created a IIS web site using the new release
  4. Copied in the sample web.config from the /setup/sqlserver folder.
  5. Copied in my App_DATA folder
  6. Accessed my site

As I had not copied anything from the old custom folder, I had theme issues at this point. However, I decided to moved all the blogs to the newest generation of theme templates, so did a quick fix up by hand on each one, picking the required theme and making sure any settings, like Twitter accounts, were set (note these are set on a per blog/per theme basis, so changing a theme means you need to reenter any custom values). I also needed to copy in a few missing logos and any extra widgets from my old custom folder the blogs were using.

Once this was all done I had an upgraded blog server.

Running CodeUI tests on a VM with on remote desktop session open as part of a vNext build

If you want to run CodeUI tests as part of a build you need to make sure the device running the test has access to the UI, for remote VMs this means having a logged in session open and the build/test agent running interactivally. Problem is what happens when you disconnect the session. UNless you manage it you will get the error

Automation engine is unable to playback the test because it is not able to interact with the desktop. This could happen if the computer running the test is locked or it’s remote session window is minimized

In the past I would use a standard TFS Lab Management Environment to manage this,you just check a box to say the VM/PC is running coded UI tests and it sorts out the rest. However, with the advent of vNext build and the move away from Lab Manager this seems overly complex.

It is not a perfect solution but this works

  1. Make sure the VM autologs in and starts your build/test agents in interactive mode (I used SysInternal AutoLogin to set this up)
  2. I connect to the session and make sure all is OK, but I then disconnect redirecting the session
    • To get my session ID, at the command prompt, I use the command query user
    • I then redirect the session tscon.exe RDP-Tcp#99 /dest:console, where RDP-Tcp#99 is my session ID
  3. Once I was disconnected my CodeUI test still run

I am sure I can get a slicker way to do this, but it does fix the immediate issue

Updated:

This bit of Powershell code could be put in a shortcut on the desktop to do the job, you will want to run the script as administrator

$OutputVariable = (query user) | Out-String

$session = $OutputVariable.Substring($OutputVariable.IndexOf("rdp-tcp#")).Split(" ")[0]

& tscon.exe $session /dest:console

Live Writer becomes Open Live Writer

My primary blog editor has been Microsoft Live Writer for years, but it has always been a pain to install via Windows Essentials (as I don’t want the rest of the product), also I was never able to find the right version when I rebuilt a PC. This was not helped by the fact there has been no development of the product for years, so I struggled to remember what year version I really needed (last one was 2012 by the way).

So it is great news that the code base has gone Open Source at  http://openlivewriter.org/, and this is my first post using the new editor. Seem to work great.

Nuget restore fails to restore all the files on VSTS build if using project.json files

We are currently working on updating a Windows 8 application to be a Windows 10 Universal application. This has caused a few problem on a TFS vNext automated build box. The revised solution builds fine of the developers box and fine on the build VM if opened in Visual Studio, but fails if built via the VSTS vNext build CI MSBuild process showing loads of references missing.

Turns out the issue was due to Nuget versions.

The problem was that as part of the upgrade the solution had gained some new projects. These used the new project.json file to manage their Nuget references, as opposed to the old packages.config file. Visual Studio 2015 handles these OK, hence the build always working in the IDE, but you need Nuget.exe 3.0 or later for it to handle the new format. The version of Nuget installed as part of my vNext build agent was 2.8. So no wonder it had a problem.

To test my assumptions I added a Nuget Installer task to my build and set an explicit path to the newest version of Nuget.

image

Once this was done my build was fine.

So my solution options are

  1. Don’t use the agents shipped with TFS 2015, get newer ones fro VSTS this has a current version of Nuget (just make sure your agent/server combination is supported. I have had issues with the latest VSTS agent and a TFS 2015 RTM instance)
  2. Manually replace the version of Nuget.exe in my build agent tools folder – easy to forget you did but works
  3. Place a copy of the version of Nuget.exe I want on each build VM and reference it s path explicitly (as I did to diagnose the problem)

The first option is the best choice as it is always a good plan to keep build agents up to date