Resolving "The agent process was stopped while the test was running" on a TFS build agent

I'm currently working on a project that uses TFS for automated builds. Recently, our builds started failing with the error "The agent process was stopped while the test was running" while running unit tests. It wouldn't always happen during the same test, though it did frequently.

After inspecting the Event Viewer on the build machines, we found an error in the .NET Runtime that was taking down the build agent:

Application: QTAgent32_40.exe

Framework Version: v4.0.30319

Description: The process was terminated due to an unhandled exception.

Exception Info: Moq.MockException

Stack:

   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.<ThrowAsync>b__5(System.Object)

   at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(System.Object)

   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)

   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)

   at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()

   at System.Threading.ThreadPoolWorkQueue.Dispatch()

   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

The exception that was being thrown on a ThreadPoolThread (always extremely bad, never good) was a MockException: our unit testing framework was throwing an exception that was taking down the build agent.  But where?

How We Solved It

By some miracle, one of our developers decided to run our problematic tests with mstest on the command line on his local machine. As it turns out, this was great because it showed the stack traces for the loose threads on the command line. Turns out we had a lot more loose threads than just the one that was taking down our test agent on the build machine. The command the developer used was (similar to) the following:

mstest.exe /testcontainer:"C:\path\to\my\test.dll" /noisolation

After auditing all of the errors by rooting them out with command line runs of mstest, the solutions to our problems all boiled down to one thing:

*ALWAYS* wrap the contents of 'async void' methods with a try-catch block!

Implementing a WCF service on an Active Directory domain using a ServiceHost in a Windows Service with Windows authentication and a non-system user service account

So, as it turns out, when you want to implement a WCF service on an Active Directory domain using a ServiceHost in a Windows Service with Windows authentication and a non-system user service account, you have to jump through a few hoops for the configuration. I kept getting the error message "A call to SSPI failed. see inner exception". The inner exception is "The target principal name is incorrect.". Like many other people, I kept thinking it had to do with authentication of the *client*. As it turns out, like those other people, I was wrong. It was to do with *verification of the service account running the service*. This is presumably because the *service user is a domain user service account*. To get this scenario working, you have to specify the name of the service user account as the 'userPrincipalName' in the 'identity' element of the 'endpoint' element for your service, like so:

<configuration>
<system.serviceModel>
<services>
<service name="MyProject.MyService">
<host>
<baseAddresses>
<add baseAddress="net.tcp://localhost:12345/MyService"/>
</baseAddresses>
</host>
<endpoint name="MyServiceTcpEndpoint"
 address=""
 binding="netTcpBinding"
 bindingConfiguration="MyServiceTcpBinding"
 contract="MyProject.IMyService">
<identity>
<userPrincipalName value="MyDomainName\MyServiceUserName"/>
</identity>
</endpoint>
<endpoint address="mex" binding="mexTcpBinding" contract="IMetadataExchange" />
</service>
</services>
<bindings>
<netTcpBinding>
<binding name="MyServiceTcpBinding"
transferMode="Buffered"
maxReceivedMessageSize="65535">
<security mode="Transport">
<!-- Use Windows authentication to ensure that we at least have authentication if not encryption -->
<transport clientCredentialType="Windows" />
</security>
</binding>
</netTcpBinding>
</bindings>
</system.serviceModel>
</configuration>

Now you'll get proper connections and authentication via Windows.

Adding files generated at build time to your ClickOnce deployment

So, it used to be that I didn't really like ClickOnce deployment, but it turns out it has a lot of benefits:

• It provides infrastructure that makes it *exceedingly* easy for your average lay-user to upgrade. All they have to do is start the program as normal, and it automatically updates for them (when configured properly)
• It bundles everything up nicely and is easy to install and uninstall (if you're a real person. If you're a script, not so much)

I recently encountered the problem of including files generated at build time (e.g. transformed configuration files) in the ClickOnce deployment package. I found the following that I could include in my ClickOnce project's .csproj MSBuild file:

 <Content Include="Path\To\My.file" Condition=" Exists('Path\To\My.file') ">
<Visible>false</Visible>
 </Content>

 The key part to getting it to work properly is that your build has to do a Build target first, then a Publish target (usually with two separate invocations of MSBuild via a build script, rather than building with a Solution). Fortunately, I was already set up for that, so getting the extra files included was a dream.

Querying XML with namespaces in PowerShell

Apparently it's ridiculously easy to parse XML in PowerShell once you have the right objects set up:

[xml] $xml = Get-Content .\DeploymentProfile.PRODUCTION.xml
$ns = new-object Xml.XmlNamespaceManager $xml.NameTable
$ns.AddNamespace('dns', 'http://www.mycompany.com/Some/Namespace/Deployment/DeploymentProfiles.xsd')
$xml.SelectNodes("//@dns:ServerHostName", $ns) | ForEach-Object { $_.Value } | sort | Get-Unique

In this example, I query a deployment configuration for attributes called "ServerHostName" within the XML namespace "http://www.mycompany.com/Some/Namespace/Deployment/DeploymentProfiles.xsd". This was exceptionally useful today when I quickly needed to figure out what servers my system was using and send that information to others to configure those servers.

Implementing Code Analysis with Team Foundation Server 2012 and later

I've been looking to get Code Analysis going on our team project at work. I found this helpful MSDN article.

Adding a computer to the local machine's list of PowerShell TrustedHosts

Retrieve the current list:

$curValue = (get-item wsman:\localhost\Client\TrustedHosts).value

Set the new list, appending the new host onto the old list:

set-item wsman:\localhost\Client\TrustedHosts -value "$curValue, Server01.Domain01.Fabrikam.com"

Things I've learned (forcibly) on 2014-12-09

1. There are database systems that are actually implemented using the Julian (sort of) calendar. Why ?!
2. It is perfectly legitimate to use script types other than type="text/javascript" in a

Adding less to your MVC 5 project

I'm going to have to just redirect to this post, because I'm in a rush. Hopefully it's still around when you read this.

Note: In order to get this to work, I had my application pool running in 'Integrated Pipeline Mode' and IIS 8 didn't like that, so I had to get rid of the system.web/httpHandlers sections for the dotLess configuration.

Creating Azure Services with Visual Studio 2013 and Windows 8.1

1. Download and install Visual Studio 2013
2. Download and install the Web Platform Installer, v5.0 or greater
3. From the Web Platform Installer, install:
1. Windows Azure SDK and related Powershell utilities and command line tools
4. Start a new solution (or open an existing one)
5. From the NuGet package manager in your solution, ensure that you've installed the 'WindowsAzure.Storage' package, or at least have it in your cache. This is going to be required by the New Project wizard when generating the project.
6. Add a new project
7. In the 'Add new project' wizard, select the C# projects -> Cloud -> Windows Azure Cloud Service
8. Follow this absurdly easy tutorial on implementing an ErrorHandler interceptor (behavior)
9. Add logging to your application using the Microsoft Patterns & Practices Enterprise Library Logging Application Block (which can be found here). 
10. Create a SQL server database in Azure using this tutorial on MSDN. When designing the user roles and authentication, it's recommended that you use the ASP.NET Identity membership design and design your tables accordingly around this.
1. Microsoft has provided an extension to the ASP.NET Identity membership framework specifically for EntityFramework. They recommend that you use a code-first model for generating entities.
2. Log in to Azure through the management portal: http://manage.windowsazure.com/
3. Configure all of your connections and permissions to the database. e.g. you may want to have multiple users: one for read-only operations, another for read-write operations.
4. Generate or write your data model. This article will show you how to create a code-first data model with Entity Framework. Ensure that you include users so that you can support proper application authentication and authorization via the ASP.NET Identity membership framework.
5. The link above also includes instructions on using code-first migrations for when you update your data model.
6. TODO: Elaborate on how to properly set up the database when performing a code-first database design
11. Add an IoC container to your WCF service to enable you to easily develop and unit test it. I've chosen to use Ninject because despite a few minutes of inital frustration, it's actually exceedingly easy to integrate with WCF, especially now that there's the Ninject WCF extensions NuGet package. To integration Ninject with your WCF service, perform the following steps:
1. Install-Package Ninject.Extensions.Wcf -Version 3.2.1.0 (Ninject and Ninject.Web.Common are installed as dependencies for you automatically).
2. Create a NinjectModule descendant to bind your interfaces to concrete implementations. It should look something like the following:

   namespace MyService.CloudStorage.Support
   {
       using System.Diagnostics.CodeAnalysis;
       using System.ServiceModel;
       using Common.Interfaces;
       using global::Ninject.Modules;
       using global::Ninject.Syntax;
       using Services;
       using NinjectServiceHost = global::Ninject.Extensions.Wcf.NinjectServiceHost;
   
       /// <summary>
       /// A <see cref="NinjectModule"/> descendant for bootstrapping our application
       /// </summary>
       public class MyServiceCloudStorageNinjectModule : NinjectModule
       {
           /// <inheritdoc/>
           [SuppressMessage("Microsoft.StyleCop.CSharp.DocumentationRules", "SA1604:ElementDocumentationMustHaveSummary", Justification = "InheritDoc")]
           public override void Load()
           {
               this.Bind<IResolutionRoot>().ToConstant(Kernel);
               this.Bind<ServiceHost>().To<NinjectServiceHost>();
               this.Bind<IMyServiceStorage>().To<MyServiceStorage>();
               this.Bind<ILoggingService>().To<MicrosoftEnterpriseLoggingBlockLoggingService>();
           }
       }
   }
   

3. Create a Global Application Class (global.asax) if one's not already created: Right-click on your project -> Add -> New Item ... and in the window that comes up, go to Visual C# -> Web -> Global Application File

4. Update your Global class to extend from Ninject.Web.Common.NinjectHttpApplication and override the CreateKernel() method and return a new CustomNinjectModule (as created above). The method should look something like this:

   namespace MyService.CloudStorage
   {
       using System.Diagnostics.CodeAnalysis;
       using System.Web;
       using Ninject;
       using Ninject.Web.Common;
       using Support;
   
       /// <summary>
       /// A global <see cref="HttpApplication"/> class for managing the lifecycle
       /// of the application
       /// </summary>
       public class Global : NinjectHttpApplication
       {
           /// <inheritdoc/>
           [SuppressMessage("Microsoft.StyleCop.CSharp.DocumentationRules", "SA1604:ElementDocumentationMustHaveSummary", Justification = "InheritDoc")]
           [SuppressMessage("Microsoft.StyleCop.CSharp.DocumentationRules", "SA1615:ElementReturnValueMustBeDocumented", Justification = "InheritDoc")]
           protected override IKernel CreateKernel()
           {
               return new StandardKernel(new NinjectSettings(), new MyServiceCloudStorageNinjectModule());
           }
    }
   }
   

1. Update your .svc file for your service(s) and add an extra XML attribute that looks like this: <%@ ServiceHost Service="HelloNinjectWcf.Service.GreetingService" Factory="Ninject.Extensions.Wcf.NinjectServiceHostFactory" %>

12. Implement your business logic
1. If you're designing your service properly, you'll need to ensure that communications between clients and your service are secure. Toward that end, you'll need to use SSL to encrypt your communications. There's a number of things involved in this:
1. Generate certificates for your server and your client
2. Ensure that your IIS server is correctly configured to use 'https' bindings on your site, along with the server-side certificate that you've generated.
3. If you're using Windows Store Apps to access a WCF service, you'll need to ensure that you use a CustomBinding correctly configured with the right *BindingElement objects to create an SSL secured, HTTPS-transported binding.
• For the server, in your service's concrete implementation, you'll need to remove any .config file configuration, and add a method specified according to a convention that WCF recognizes that looks like the following:

  /// <summary>
  /// The service certificate store name
  /// </summary>
  private const StoreName ServiceCertificateStoreName = StoreName.My;
  
  /// <summary>
  /// The service certificate store location
  /// </summary>
  private const StoreLocation ServiceCertificateStoreLocation = StoreLocation.LocalMachine;
  
  /// <summary>
  /// Configures the specified configuration.
  /// </summary>
  /// <param name="config">The configuration.</param>
  /// <remarks>
  /// A service endpoint configuration method determined by convention.
  /// <see href="http://msdn.microsoft.com/en-us/library/hh205277(v=vs.110).aspx"/>
  /// </remarks>
  public static void Configure(ServiceConfiguration config)
  {
   ServiceEndpoint serviceEndpoint = new ServiceEndpoint(
    ContractDescription.GetContract(typeof(IMyServiceStorage), typeof(MyServiceStorage)), 
    new CustomBinding(
     new TransportSecurityBindingElement(),
     new SslStreamSecurityBindingElement { RequireClientCertificate = false },
     new TextMessageEncodingBindingElement(MessageVersion.Soap12WSAddressing10, Encoding.UTF8),
     new HttpsTransportBindingElement()
    ), 
    new EndpointAddress("https://localhost/MyService.CloudStorage/MyServiceStorage.svc")
   );
  
   config.AddServiceEndpoint(serviceEndpoint);
  
   const string ServiceCertificateThumbprint = "[a 40 digit hexadecimal certificate thumbprint here]";
  
   X509Store certificateStore = new X509Store(ServiceCertificateStoreName, ServiceCertificateStoreLocation);
  
   certificateStore.Open(OpenFlags.ReadOnly);
  
   X509Certificate2Collection x509Certificate2Collection = certificateStore.Certificates.Find(
    findType: X509FindType.FindByThumbprint,
    findValue: ServiceCertificateThumbprint,
    validOnly: false
    );
  
   certificateStore.Close();
  
   X509Certificate2 serviceCertificate = x509Certificate2Collection.Cast<X509Certificate2>().FirstOrDefault();
  
   if (serviceCertificate == null)
   {
    throw new ConfigurationErrorsException(String.Format("No certificate representing the service with thumbprint {0} could be found in {1} store at {2} location", ServiceCertificateThumbprint, ServiceCertificateStoreName, ServiceCertificateStoreLocation));
   }
  
   ServiceCredentials serviceCredentials = new ServiceCredentials
   {
    IdentityConfiguration = new IdentityConfiguration
    {
     // TODO: Change this to authenticate the clients
     CertificateValidationMode = X509CertificateValidationMode.None
    },
    ServiceCertificate =
    {
     Certificate = serviceCertificate
    }/*,
    ClientCertificate =
    {
     // TODO: Resolve the client certificate
     Certificate = serviceCertificate
    }*/
   };
  
   config.Description.Behaviors.Add(serviceCredentials);
   // config.Description.Behaviors.Add(new ServiceMetadataBehavior { HttpGetEnabled = true, HttpsGetEnabled = true });
  }
  



• For the Windows Store App client, you'll need to have a similarly configured counterpart channel factory and binding for connecting to the service:

  this.channelFactory = new ChannelFactory<IMyServiceStorageChannel>(
   binding: new CustomBinding(
    new TransportSecurityBindingElement(),
    new SslStreamSecurityBindingElement(),
    new TextMessageEncodingBindingElement(MessageVersion.Soap12WSAddressing10, Encoding.UTF8),
    new HttpsTransportBindingElement()
   ),
   remoteAddress: new EndpointAddress(serviceUri)
  );
  
  this.passwordVault = new PasswordVault();
  
  // This IDispatchMessageInspector is a custom addition for our own brand of authentication
  this.channelFactory.Endpoint.EndpointBehaviors.Add(new ClientAuthenticationDispatchMessageInspector(this.passwordVault));
  

• For the Windows Store App, you'll also need to have the server's public key (assuming it's not trusted, e.g. a self-signed certificate) added to the app's certificate declarations in the package manifest. There's a video on how to do it here on Channel 9. For the sake of convenience, I'll reproduce the steps here:
1. Obtain your server's public key in DER-encoded .cer format.
2. Open the Package.appxmanifest file for your App in Visual Studio
3. Go to the Declarations tab.
4. Under the 'Available Declarations' box, select 'Certificates' and click 'Add' if there's no Certificates declaration already added.
5. Select the 'Certificates' declaration in the 'Supported Declarations' box.
6. In the 'Certificates' group on the large pane, click 'Add New'.
7. In the certificate parameters box that comes up, enter 'Root' in the 'Name' field, and select your public key file. Once you do this, Visual Studio will automatically import it into your project.
8. Save the manifest.
13. Publish it to Azure Services
1. If you've designed your application correctly, you'll be using HTTPS for communicating with your clients. Read Microsoft's guide on MSDN to uploading a certificate with your service.
14. Implement your Windows 8.1 client // TODO: Elaborate on this
15. Unit test your Windows 8.1 client on your own local machine.
1. Visual Studio 2012 / .NET 4.5 added the ability to do asynchronous unit tests to MSTest!
2. In order to unit test the Windows 8.1 Metro client against services on your localhost, you'll have to read this. It describes the new security features in Windows 8(.1) and how to explicitly enable your application to communicate through the network loopback interface. 
3. You can also read this. Bottom line, you have to ensure that you enable a loopback exemption for your unit tests.
16. Unit / integration test it against your Azure service
1. Ensure that you've created a 'Staging' area in your Azure configuration panel and you're not testing against production! Testing against production is extremely poor practice!
17. Publish your App on the Windows Store if you so choose

Correcting the default check-in action for associated work items in Team Foundation Server

I've found that it's a giant pain in the ass in TFS when associating work items to checkins because the default assocation action is 'Resolve' rather than 'Associate'. When I'm working on features, I like to do bits of functionality in units and check them in to source control in small batches to make my changes more manageable. Unfortunately, many times I've forgotten to change the association action when associating work items with change sets and it's resolved my issue instead of just associating the work item with the change set. This becomes problematic because it skews my records and metrics for how much time is spent working on a task. Fortunately one can change this in the registry:

HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\[Version Number]\TeamFoundation\SourceControl\Behavior

Quick fix.

Regarding pre-test invocation scripts when deploying to a Test Agent with TFS

So, I learned something interesting about TFS Test Agents today and they way they handle pre-test invocation scripts when running tests on a Test Agent. In Microsoft Test Manager, do the following:

1. Connect to a Team Project
2. Change into 'Lab Center' mode
3. Click on 'Test Settings' in the top bar-ish area. This will open up the Test Settings Manager.
4. Edit or create a new 'Test Settings' item and open it up.
5. In the 'test settings' editor, under the 'Steps' column on the left-hand side, go to 'Advanced' -> 'Scripts'. You're now presented with the scripts page where you can specify scripts to be invoked before and after the execution of your test run.

Now, **here's the important thing** :

The script file(s) you specify in these boxes do not get copied to the Test Agent per se. Instead, their contents get read and merged with an automatically generated script that's created by the Test Agent. The script that actually gets run on the Test Agent will look similar to the following:

REM **************************************************************************** 

REM *  Generated by Microsoft Visual Studio 

REM *  Copyright (c) Microsoft Corporation. All rights reserved. 

REM *   

REM **************************************************************************** 

set ResultsDirectory=C:\Users\Autotest\AppData\Local\VSEQT\QTAgent\23620\00C4EF~1\Results 

set DeploymentDirectory=C:\Users\Autotest\AppData\Local\VSEQT\QTAgent\23620\00C4EF~1\DEPLOY~1 

set TestRunDirectory=C:\Users\Autotest\AppData\Local\VSEQT\QTAgent\23620\00C4EF~1 

set TestRunResultsDirectory=C:\Users\Autotest\AppData\Local\VSEQT\QTAgent\23620\00C4EF~1\Results\00C4EF~1 

set TotalAgents=1 

set AgentWeighting=100 

set AgentLoadDistributor=Microsoft.VisualStudio.TestTools.Execution.AgentLoadDistributor 

set AgentId=1 

set TestDir=C:\Users\Autotest\AppData\Local\VSEQT\QTAgent\23620\00C4EF~1 

set BuildDirectory=\\SOMESERVER\SomeShare\TFSDrops\HRST\CWSTAM~1.SPR\CWSTAM~3.1 

set DataCollectionEnvironmentContext=Microsoft.VisualStudio.TestTools.Execution.DataCollectionEnvironmentContext 

set TestLogsDir=C:\Users\Autotest\AppData\Local\VSEQT\QTAgent\23620\00C4EF~1\Results\00C4EF~1 

set ControllerName=TSTTFSTHR01:6901 

set TestDeploymentDir=C:\Users\Autotest\AppData\Local\VSEQT\QTAgent\23620\00C4EF~1\DEPLOY~1 

set AgentName=00C4EFD8-A65F-4B5E-AD5F-04F93895B543 

REM **************************************************************************** 

REM *  User Commands 

REM *   

REM **************************************************************************** 

echo "My actual user commands from my script file here"

This is important to keep in mind when you're writing the commands in the script to be executed, because no files get copied with the script file you reference in the Test Settings, and there's no mention of where that script file originally came from, so the script is effectively executed without any context except for that which is given to it by the TFS Test Agent in the prefixed lines.

A huge annoyance in Windows 8 store apps

Apparently Bindings are no longer TwoWay by default as they were in WPF. They're now OneWay, which was a huge annoyance and wasted a solid half hour of my time trying to debug my bindings.

Creating a WPF app with Microsoft Prism Framework 5

To get started, do the following:

• follow the tutorial provided by Microsoft.
• follow the followup tutorial for linking views and view models, specifically the section titled "Creating the View Model Using a View Model Locator"
• setup auto-wiring for the container in this section of the tutorial.
• Ensure that you set the default ViewModel factory in the Bootstrapper.ConfigureContainer method: ViewModelLocationProvider.SetDefaultViewModelFactory(viewModelType => this.Container.Resolve(viewModelType));

Getting an "RPC endpoint not found/not listening" exception when connecting to a remote machine with PowerShell

Lately I've been dealing with a lot of remote management for the purposes of automating our deployment process for the product on which I'm working. I've been able to connect other (pre-configured) machines, but when I wanted to connect to my own machine in unit tests, I've been unable to do so until now. Each time I try to connect, I'd get an exception along the lines of "The remote RPC server is not responding". I double checked that my "Windows Remote Management (WS-Management)" service is up and running, so I was perplexed as to why I still couldn't connect. I had turned off my firewall (temporarily, of course), and as if that wasn't enough, I'd explicitly enabled the rules for Windows Remote Management. As it turns out, (at least when you're running Windows Server 2008 R2) the service runs by default, but is not configured to allow remote management by default. (Totally makes sense, right ? /sarcasm) To remedy this, you need only run the following under and Administrator command line:

winrm quickconfig

This will enable your machine to accept incoming connections. You should also ensure that your firewall has been properly configured to allow the remote management rules (pre-existing, come with Windows). Also make sure that your service is actually running.

Creating a certificate chain of self-signed certificates for development / testing / private environments

As anybody who's ever tried to develop secure services with SSL knows, it's expensive to buy trusted certificates from a certification authority. This is especially true if you're an independent developer who doesn't have a lot of resources. Therefore, we need to be able to generate self-signed certificates in order to develop and test our code before we actually go buy a Trusted Certificate for production. This tutorial will show you how to create a chain of trust and start generating certificates from a self-signing authority. The information here is based off of Microsoft's documentation on MSDN about the matter.

1. Create a signing authority certificate:

• makecert -n "CN=My Signing Authority" -r -sv MySigningCert.pvk MySigningCert.cer

You'll be prompted for passwords for securing the private key. Ensure that you remember them, you'll need them to create the merged file.


2. Merge the private key file and public key file into an encrypted key (this isn't mentioned in the MSDN article linked above, but you can find the documentation here):

• pvk2pfx /pvk MySigningCert.pvk /spc MySigningCert.cer /pfx MySigningCert.pfx /pi mycertpassword /po mycertpassword /f

This step isn't necessary for signing site certificates, but does make things more convenient for storing the certificate and installing it on different machines. Be careful: you should never leave keys laying around file systems on machines, they should always either: a) be stored in an encrypted store like that provided by Windows, or b) be stored on separate storage media that can be physically locked away with access only available to trusted personnel.


3. Start creating site certificates with your signing certificate:

• makecert -iv MySigningCert.pvk -n "CN=www.mywebsite.com" -ic MySigningCert.cer -sv sitekey.pvk sitekey.cer -pe

Now, as above, I recommend that you merge the .pvk and .cer into a .pfx for easy transport and storage.

Retargeting a Windows 8 application to Windows 8.1

Apparently, fuck Windows 8. So says everybody. Including Microsoft. That's why at some point you're going to have to retarget your Windows 8 app (if you were crazy enough to make any) for Windows 8.1. Fortunately, Microsoft provides a guide for doing so in Visual Studio 2013 here. Fortunately, it's as simple as right-clicking on your solution in the Solution Explorer and clicking on Retarget for Windows 8.1

Making TFS builds consistent with desktop builds when invoking MSBuild directly on a .*proj file

As it turns out, MSBuild has more than a few quirks when being invoked through TFS compared to being invoked through a command line or from Visual Studio. Some of them are pretty well documented. Others are not, like the fact that in a .*proj file, the OutDir variable is inherited to sub-MSBuild tasks.  There's also quirks because OutputPath is used to determine OutDir, but not in all cases. If you're going to specify OutputPath in the properties when invoking the MSBuild task, you should also explicitly override the OutDir variable as well to ensure consistency, unless you **TRULY** understand the differences between the two and how MSBuild determines OutDir, and you **REALLY** want it to be that way.

Getting code signing to work with ClickOnce on a TFS Build Agent

Code signing is a giant pain in the butt. You have to :

• Obtain the certificate for signing the code by:
1. buying the certificate from an issuer.
2. generating your own self-signed certificate
• Configure ClickOnce within your project file with the following property elements:
• <signmanifests>true</signmanifes>
• <manifestcertificatethumbprint>A387B95104A9AC19230A123773C7347401CBDC69</manifestcertificatethprint>
• Log into your machine **as the user running the build controller / agents ** and import the key to their user Personal certificate store!
• Run 'certmgr.msc' from the Run command in the start menu (WinKey + R is the hotkey)
• In the Certificate Manager that comes up, go to Personal in the tree, right-click, and select All Tasks -> Import ...
• In the Certificate Import Wizard window that comes up, select Next to move to the 'File To Import' screen.
• Select your certificate file, which has the same thumbprint as specified in your project file, then click Next to move to the 'Certificate Store' screen.
• In the 'Certificate Store' screen, select the 'Place all certificates in the following store' option, then click Browse to select the store. Choose 'Personal' in the selection window. Click Next to move to the "Completing the Certificate Import Wizard" window.
• On the "Completing the Certificate Import Wizard" window that comes up, click Finish to import the certificate.

You should now be able to build and sign your code on a TFS Build controller / agent.

Converting an existing Windows Store app to using the Prism Framework

I began converting an existing Windows Store App to using the Prism Framework provided by Microsoft. However, I'm running into the following error:

The primary reference "Microsoft.Practices.Prism.StoreApps" could not be resolved because it was built against the ".NETCore,Version=v4.5.1" framework. This is a higher version than the currently targeted framework ".NETCore,Version=v4.5".

This post on stackoverflow.com recommends installing the Microsoft Build Tools 2013 package, which is available here:
http://www.microsoft.com/en-ca/download/details.aspx?id=40760

That didn't work.

I later realized that I had installed Prism with NuGet, so I went and checked the publishing dates on the versions. The latest (and default, which I had installed) was 1.1.0. The date on 1.0.1 was much older, and after reverting to that version, I was able to get my program to compile and run with a few modifications to the steps in this tutorial. The modifications are as follows:

• Change the return type of the App.OnLaunchApplication method to 'void' to match the 1.0.1 version of the Prism.StoreApps library.
• In the App.OnLaunchApplication method, ensure that there's a call to :
• NavigationService.Navigate("Main", null); where "Main" is the initial page name, and there's a MainPage class in your Views folder.
• Move the existing MainPage class into the Views folder in the root of the project.

Creating my first Windows 8 store app

As you may or may not be aware, there are multiple types of applications that can be created for Windows 8:

• Windows store apps, which use the new Metro interface
• Desktop-based apps which are like those created for previous versions of Windows that can still run in the Desktop app.

I'm quite familiar with creating WPF apps for Windows, but Metro apps are new, and those are what I'll be working on. With that in mind, Microsoft provides the Prism framework which helps provide additional classes, interfaces, events etc to help people develop Windows Store apps that keep consistent with Windows 8 design principles and help the apps perform properly. I'll be starting with the MSDN link here.