Visual Studio – RichHewlett.com

VS Code Keyboard Mappings in VS 2019

Quick post to let you and ‘future me’ know that Visual Studio 2019 includes the option to use VS Code keyboard mappings out of the box. As someone who has been using VS Code as my development environment much more often than full Visual Studio recently this was a really useful find for me, and one I wasn’t aware of. I had been recently fumbling about in Visual Studio using muscle memory to perform tasks before realising that I am in a different editor and so I need to use the ‘other’ keyboard mappings. I decided enough was enough and so I dug into the Visual Studio settings to tweak some of the keyboard shortcuts and found that you can just tell it to use VS Code mappings instead.

In Visual Studio 2019 > Tools > Options > Environment > Keyboard : Apply following Keyboard Mapping Scheme Visual Studio Code.

So I can now standardise my keyboard mappings across both IDEs and that is one less thing for me to remember.

Visual Studio 2019 Offline Installer

Microsoft have now released Visual Studio 2019 and like VS2017 there is no offline installer provided by Microsoft, but you can generate one by using the web installer setup program to write all the packages to disk.

To create the offline installer just download the usual web installer exe from the Microsoft download site and then call it from the command line passing in the layout flag and a folder path like this:

vs_community --layout  "C:\Setup\VS2019Offline"

In the example above I’m dowloading the Community verssion, but if its the Enterrpise editions installer then the setup file you downloaded will be called vs_enterprise.

The packages will all be downloaded and a local setup exe installer created.

If you want to limit to English then pass –lang en-US flag too.

vs_community --layout  "C:\Setup\VS2019Offline" --lang en-US

You can also limit what workloads to download if you know their names by listing them after a –add flag.

Enjoy your offline installs.

Create New MSTest Projects for Pre .Net 4.5 in Visual Studio 2017

This post outlines the steps to create a new unit test project in Visual Studio 2017 using MS Test V1 and that targets .Net Frameworks prior to .Net 4.5.

Visual Studio 2017 onwards only has new unit test projects for MS Test V2 onwards and .Net 4.5. This is fine for new applications or ones targeting a recent .Net framework version but what if you have an existing solution targeting an older .Net version. Below shows the Unit Test Project available for .Net 4.5, but as you can see in the second screenshot for .Net 3.5 its not available.

If you want to create a new unit test project targeting .Net 3.5/4 for example then follow the steps below:

Create a new MS Test V2 project targetting .Net Framework 4.5 as in the first screenshot above (i.e. File > New Project > Test > Unit Test Project targeting .Net 4.5).

Once its created, change the project to target your earlier .Net Framework (e.g. .Net 3.5). This is done via the Project Properties page. Click Yes and Visual Studio will reload the project.

Once it reloads the project will complain about some references which is fine as we’re now going to remove the MS Test V2 assemblies.

Now remove the two project references to test assemblies.

Then add a reference to the MSTest v1 assembly, Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll. This should be under Extensions in the Add Reference dialog. Alternatively you can browse to them on your hard drive at the following locations:

For pre .Net 4 projects : C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\ReferenceAssemblies\v2.0

For post .Net 4 projects: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\ReferenceAssemblies\v4.0

If you are not running Visual Studio Enterprise, then swap Enterprise in the path for Community etc.

Now rebuild the project and you’re all done.

Find assemblies loaded during debugging in Visual Studio

Sometimes you may get the following error when you are debugging a .Net app in Visual Studio:

“The breakpoint will not currently be hit. No symbols have been loaded for this document.”

Or you may have issues whereby the wrong code version appears to be loading at run time or perhaps when debugging you get an error saying a referenced component cannot be located.

All these issues stem from you not being able to view what components are actually being loaded during debug. If only there was a view in Visual Studio that gave you that info…well this is Visual Studio and so they’ve already thought of that, and its called the Modules view.

During debugging of your application from the menu go : Debug > Windows > Modules

From this really useful view you can see each component that’s been loaded, the file path, the symbol file location, version information and more. This will show you if a component from the GAC has been loaded instead of your local file version, for example. It also enables you to find and load Symbol files for components where they have not been loaded automatically.

For information on the full functionality of this view check out the documentation here.

Platform Targeting in .Net

If you see one of the errors below within your .Net application it is likely as a result of your assembly having been compiled with the wrong target architecture flag set.

1) In this instance the assembly was accidentally compiled for x86 only and run within IIS in a 64bit process:

Unhandled Exception: System.BadImageFormatException: Could not load file or assembly “AssemblyName Version=1.0.0.0, Culture=neutral” or one of its dependencies. An attempt was made to load a program with an incorrect format.

(For info IIS has an Application Pool setting under Advanced Settings that enables you to run the App Pool as a 32 bit process instead of 64bit. This is off by default.)

2) Here a .Net application targeting a 64 bit processor was run on a 32bit system:

This version of ConsoleApplication1.exe is not compatible with the version of Windows you’re running. Check your computer’s system information to see whether you need a x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher.

If you are looking for a quick fix, then just recompile your assembly with the “Any CPU” option as your platform target. See project properties, build tab for this setting. If you want more information and explanation then read on.

When compiling .Net assemblies in Visual Studio (or via the command line) there are a few options regarding optimising for certain target platforms. If you know that your assembly needs a to be deployed only to a 32bit environment (or it needs to target a specific processor instruction set) then you can optimise the output of MSIL code (what the compiler produces ready for a JIT compilation at run time) for that platform. This is not normally required but perhaps, for example, you have to reference unmanaged code that targets a specific processor architecture.

Essentially this sets a flag inside the assembly metadata that is read by the CLR. If this is set incorrectly then this can result in the above errors but also other odd situations. For example if you compile your app to target “x86” and then reference an assembly that is targeting a “x64” platform then you will see an error at runtime due to this mismatch (BadImageFormatException). Running an “x86” application will still work on a 64 bit Windows but it will not run natively as 64bit but will instead run under the WOW64 emulation mode which enables x86 execution under 64 bit (with a performance overhead), which may or may not be a valid scenario in your case.

If you want to reproduce the situation try creating a new console application and in the build properties tab set Platform Target to “x86”. Then create a new Class Library project, set a reference to it in the Console Application, and then in the build properties tab set it to target the “x64” platform. Build and run the application which will show the above BadImageFormatException.

The target platform for your project is set in the Project Properties tab in Visual Studio, under Build (see screenshot above). If you are compiling via the command line you use the /platform switch.

“AnyCPU” became the default value from VS2010 onwards. “AnyCPU” used up to .Net 4.0 means that if the process runs on a 32-bit system, it runs as a 32-bit process and MSIL is compiled to x86 machine code. If the process runs on a 64-bit system, it runs as a 64-bit process and MSIL is compiled to x64 machine code. Whilst this enables more compatibility with multiple target machines it can lead to confusion or unexpected results when you consider that Windows duplicates system DLLs, configuration and registry views for 32bit and 64bit processes. So Since .Net 4.5 (VS2012) there is now a new default subtype of “AnyCPU” called “Any CPU 32-bit preferred” which basically follows the above rules except that if a process runs on 32bit system then it will run as a 32 bit process (not 64bit as before) and its MSIL will be compiled to x86 code not x64. This change essentially now forces your process to run under 32bit on a 64bit machine unless you untick the option and turn off the default setting. This setting can be seen on Project properites Build tab as “Prefer 32-bit”.

It is worth noting that you may see a confusing “Multiple Environments” option in Visual Studio which can be automatically added after migrating solutions from older versions of Visual Studio (I believe it has been removed as a new option in VS2015 onwards but can hang around in older solutions). Use the Configuration Manager tab to check the setting for each assembly. Most developers will want to target “Any CPU” which supports multiple target environments. If you are getting the above errors then use the steps below to check the assembly and if incorrect then try recompiling with “Any CPU” instead.

How to confirm a target platform for a given assembly:

So how do you confirm which processor architecture an assembly was built for? Well there are a few ways:

1) Using .Net reflection via a simple Powershell command:

[reflection.assemblyname]::GetAssemblyName("${pwd}\MyClassLibrary1.dll") | format-list

Running this command pointing to the assembly you want to check will produce output like this below (results truncated):

An assembly compiled to target AnyCPU:

Name                  : ClassLibrary2
Version               : 1.0.0.0
CodeBase              : file:///C:/TempCode/crap/pttest/x86/ClassLibrary2.dll
ProcessorArchitecture : MSIL
FullName              : ClassLibrary2, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null

Same assembly but now compiled to target x86 :

Name                  : ClassLibrary2
Version               : 1.0.0.0
CodeBase              : file:///C:/TempCode/crap/pttest/x86/ClassLibrary2.dll
ProcessorArchitecture : X86
FullName              : ClassLibrary2, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null

Same assembly again but now compiled to target x64 :

Name                  : ClassLibrary2
Version               : 1.0.0.0
CodeBase              : file:///C:/TempCode/crap/pttest/x86/ClassLibrary2.dll
ProcessorArchitecture : Amd64
FullName              : ClassLibrary2, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null

2 )You can also see this information from a de-compiler tool such as dotPeek. Below shows a screenshot showing a x86, 64, AnyCPU and x64 targeted assemblies.

3) Use the CorFlags Conversion Tool

The CorFlags Conversion Tool (CorFlags.exe) is installed with Visual Studio and easily accessed by the VS Command Line. It enables reading and editing of flags for assemblies.

CorFlags assemblyName

Assuming you have the .Net 4 version installed with .net 4 and above you’ll see something like this. Older versions do not have the 32BITREQ/PREF flags as per the change for .Net4 discussed above:

Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  4.6.1055.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Version   : v4.0.30319
CLR Header: 2.5
PE        : PE32
CorFlags  : 0x1
ILONLY    : 1
32BITREQ  : 0
32BITPREF : 0
Signed    : 0

To interpret this output see the table below and check the PE value (PE32+ only on 64bit) and the 32bit Required/Preferred flags. It is also possible to update these flags using this tool.

Summary

Below is a simple table of results to show the impact of Platform Target on the complied assembly and how it is run on a 32/64bit OS. As you can see the 32 preferred flag has resulted in an AnyCPU assembly being run as 32bit on a 64bit OS, the table also shows the values you get when you use the techniques above for determining the target platform for a given assembly.

Platform Target in Visual Studio	PowerShell Result	dotPeek Result	CorFlags 32BITREQ	CorFlags 32PREF	CorFlags PE	Runs on 32bit OS as	Runs on 64bit OS as
AnyCPU (pre .Net 4)	MSIL	MSIL	0	0	PE32	32 bit process	64 bit process
AnyCPU (.Net 4 +) 32 bit NOT preferred	MSIL	MSIL	0	0	PE32	32 bit process	64 bit process
AnyCPU (.Net 4 +) 32 bit Preferred (default)	MSIL	x86	0	1	PE32	32 bit process	32 bit process (under WOW64)
x86	x86	x86	1	0	PE32	32 bit process	32 bit process (under WOW64)
x64	Amd64	x64	0	0	PE32+	ERROR	64 bit process

In summary, there are a few simple rules to be aware of with using AnyCPU and the 32bit Preferred flag but essentially AnyCPU will enable the most compatibility in most cases.

Exporting an HTML Report From your VS/TFS Test Results

Have you ever wanted to export your unit test results from Visual Studio or your TFS Build? Sometimes you may need to provide evidence of your unit testing position to a project stakeholder. This may be for an internal review or as part of a gateway check in a waterfall project. Alternatively you may just want to export your test results for storage later. Out the box Visual Studio provides the Test Results view which is a great tool for seeing the tests that passed/failed in a build, but it is in a custom file format (*.trx) and requires Visual Studio to view.

However I recently found this command line tool on CodePlex by ‘ridomin’ called trx2html which ‘does what it says on the tin’, it converts trx files to HTML. Using the command line, just pass the file path to your test results file for your solution or TFS Build (*.trx) to the trx2html.exe and out pops a fancy HTML report (example below).

The tool is open source on CodePlex and so you can download the latest version from: http://trx2html.codeplex.com.

No VS with Notepad++ and Programmers Notepad

Sometimes, despite Visual Studio being an excellent IDE, you want to go the No VS route and hack your code in notepad. Perhaps you just want to make a quick change and its not worth firing up the full VS experience. Maybe you are only checking the code as a background time-filler in between other tasks you don’t want VS eating up your workstations resources all day. Perhaps most likely you’ll need to edit your code on a PC without VS (e.g. Netbook). A while ago I came across this excellent post by SecretGeek where he’s used a batch script to add compilation to the excellent Notepad++. I recommend taking 5 minutes to follow his instructions and get this working as it makes Notepad++ even more useful. Don’t forget you will need to change the .Net framework path in the batch file if you’re coding apps older than .Net 4.0.

I’ve also copied the batch file and then modified it to work for solution files too, so I can compile the whole solution if required instead of just the project file. I’ve then added a second entry in the Notepad++ file (as per SecretGeek’s instructions) and a second shortcut key for this batch file. The only change required is to amend the “*.*proj” to “*.*sln”. This change assumes that the project and solution files are NOT in the same folder though as this confuses the .Net compiler.

As good as Notepad++ is as a notepad tool, if you need something a little more like a mini IDE then I recommend “Programmers Notepad”. Not only is it an excellent lightweight Notepad like tool but it also supports “projects” and tools. By far the best feature though is that it parses the output from the compiler and highlights the results. Also clicking on the error will take you straight to the offending line of code (see screenshots below).

It is easy to integrate SecretGeek’s above batch files into Programmers Notepad. Go to Tools > Add Tool, and set it up like this:

Now we’re cooking! So what’s left? Well what about being able to run your Unit Tests from this mini IDE? Let’s assume Visual Studio is installed on the machine in question (which negates the point of the exercise perhaps, but not always as sometimes you have it installed but just don’t want to run the full blown VS IDE) so we can run MSTest via a batch file. For this batch file to work though we have to make a few more assumptions:

1 You will always run the tests whilst the unit test project code is the open active document in Programmers Notepad.
2 The test assembly name is the same name as the test project file.

Using these assumptions we can code the RunTests.bat batch file to find the active document’s VS project file (*.*proj) and use its name to find the output assembly name in the bin\debug folder. Once we have the test assembly we can throw it at MSTest for it to run the tests. Assigning this new batch file to a Tool menu item in Programmers Notepad (as we did with the other batch files above) we can run the tests within Programmers Notepad and the test results will be output into the output window.

The code for the RunTests.bat batch files is:

@ECHO OFF

Set MSTestPath="C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\MStest.exe"

:findproj

Set current=%cd%

If not exist *.*proj goto tryFindProjAgain
REM get project file name
FOR %%f IN (*.*proj) DO Set dllname=%%f
REM Convert proj file name to test assembly name
set dllname=%dllname:csproj=dll%
Set fullpath=%cd%\bin\Debug\%dllname%

%MSTestPath% /testcontainer:%fullpath% /detail:errormessage

goto end

:tryFindProjAgain

ECHO No project file found in:
ECHO %cd%

cd ..

REM detect if we are at the root level
if "%current%"=="%cd%" goto end

goto findproj

:end

Installing Team Foundation Server on Windows Home Server 2011

Twelve months ago I wrote a post documenting “installing Team Foundation Server 2010 on Windows Home Server” which has proved very popular. Well things move on and since then Microsoft have released a new version of Windows Home Server (WHS 2011). There are many differences between V2 of WHS compared to V1 but the main points for the purpose of this post are that WHS 2011 is build on top of Windows Server 2008 R2 (compared to Windows Server 2003 for V1) and controversially the Drive Extender technology has been removed. Whilst Drive Extender was no doubt useful for storage pooling it did make installing applications like TFS a little concerning. As described in my original article I wouldn’t install an application or a SQL Server database into the Drive Pool (it just feels wrong to me and wouldn’t trust it) and I stick by this especially as it’s been suggested that one of the reasons for Microsoft removing DE was due to it not playing nicely with enterprise applications that would be targeted for use on the new Small Business Server Essentials product range with which WHS 2011 shares it’s code. No DE means you can install TFS now to whichever drive wherever you like in WHS 2011, and the fact that it’s built on the excellent Server 2008 base means it benefits from stability and performance improvements this brings. I’ve not found any issues with TFS on WHS 2011 and don’t expect to (although its not supported so you install it at your own risk). I think that WHS 2011 will make an even better TFS server than WHS V1.

Other than the decision of where to install TFS due to DE, the installation instructions are the same as in my original post. After installation I recommend installing the TFS Power Tools and then configuring TFS backups as described in these posts: Backing Up TFS 2010 Using PowerShell: Part 1, Backing Up TFS 2010 Using PowerShell: Part 2 and Backing up TFS 2010 with new Power Tools Backup Plan.

XML Error in TFS Power Tools Backup Plan

Whilst checking the Windows Event Log on my server I found this worrying error being reported by the Team Foundation Server Power Tools Backup & Restore Tool :

Error: Tfpt Backup Restore : There is an error in XML document (499, 100).

I posted an article about using this tool to backup your TFS server in September, and it has been successfully backing up daily since that time. The above error has been reported after every daily backup for the past few weeks it seems. It immediately follows an information event from MSSQL$SQLEXPRESS stating that the “Database has been backed up”. To investigate more I opened the TFS Admin Console on the server and clicked “Take Full Backup Now” whereby I got the same error interactively – well at least it’s consistent.

From here you can open the log, and in that I can see it’s reporting that the BackupSets.xml file in the root of the backup target location is invalid:

[Info   @20:30:15.977] Backup Set Name Tfs_DefaultCollection database Backup
[Info   @20:30:15.977] Backup Set Description Tfs_DefaultCollection database – Full Backup
[Info   @20:30:15.977] Adding database Tfs_DefaultCollection to the backupset
[Error @20:30:16.352] System.InvalidOperationException: There is an error in XML document (499, 100). —> System.Xml.XmlException: There is an unclosed literal string. Line 499, position 100.

On opening the file there appears to be nothing wrong with the XML as such but in my case it didn’t seem complete, as the last successful backup only detailed one entry not the usual two (*.bak and *.trn files). This file seems to be record of the backups as opposed to being core to the actual SQL backup process so I deleted/renamed the BackupSets.xml file and ran another full backup. This time it worked fine and a new BackupSets.xml file was created. It’s now running fine again.