http://blogs.msdn.com/b/visualstudioalm/archive/2015/10/23/team-foundation-plugin-for-intellij-idea.aspx 

And if you aren't using VSOnline yet for your Java development, check out this site that explains how to get started...

http://java.visualstudio.com

Calling all Java developers!!

We need your help. If you are a Java developer, tell us what you want or need from Microsoft. We want the Java development experience to be great. If there is something we can change or add, we want to know.

Thanks,

Jason

1. The very first step is to upgrade your Server. Your build machines should match the version of your server.
2. To upgrade your build machine to TFS2012 follow the instructions on
   http://msdn.microsoft.com/en-us/library/jj620928.aspx
3. If you need Visual Studio on the build machine, install VS 2012 on the build machine. You will probably want to keep VS2010 on the build machine as well. This shouldn't cause any problems.
4. The next step is to recompile any custom activity assemblies that this build machine uses to target the 4.5 .net framework and the version 11.0.0.0 Team Foundation assemblies.
1. Open the solutions for your custom activities
2. Open Properties on each project and change the target framework to 4.5
3. Remove all TeamFoundation references and replace them with the ones that ship with Visual Studio 2012 (the version number should be 11.0.0.0 - NOT 10.0.0.0).
4. Recompile the solutions and check in the binaries to the custom assembly location
5. ALL assemblies in the custom assembly location for a 2012 controller should be compiled against the 11.0.0.0 versions of the TeamFoundation assemblies.
5. The final step before testing your builds is to "clean up" any versioned namespaces in your Build Process Templates (XAML files)
1. locate all of your XAML files - these are usually in $/TeamProject/BuildProcessTemplates
2. for each XAML file: check it out, clean it by removing versioned namespaces, and check it back in (see http://blogs.msdn.com/b/jpricket/archive/2012/07/17/tfs-2012-cleaning-up-workflow-xaml-files-aka-removing-versioned-namespaces.aspx)
6. Finally, you should be able to test your build definitions.

Limitations

• A 2010 Build machine will NOT work with a 2012 Team Foundation Server
• A 2012 Build machine will NOT work with a 2010 Team Foundation Server
• A 2012 Build machine cannot build a 2010 template that contains versioned namespaces that reference 10.0.0.0 assemblies
• A 2012 Build machine cannot build a 2010 template that calls out to custom activities that are compiled against 10.0.0.0 Team Foundation Assemblies
• Build Definitions that reference custom types may not be editable in both Visual Studio 2010 and 2012
• It's hard to identify all the combinations here, but if loading your custom types causes Team Foundation assemblies of the wrong version to be loaded then the editor will not work as desired.
• Note that in Visual Studio 2012, you should be able to edit other parts of the definition, just not the process parameters that cause errors.

Problems you might face and workarounds:

• After upgrading your templates and custom assemblies as described above, you will only be able to edit them in Visual Studio 2012.
• If you install both Visual Studio 2010 and 2012 on the same machine, make sure you install them in that order: 2010 and then 2012.
• Opening a template in the VS 2010 Worflow Designer on this machine will not work without changes to the template. It will attempt to load the 2012 Team Foundation assemblies as well as the 2010 versions which will cause errors when it tries to evaluate any types. There's really nothing wrong with the actual template.
• If you have to have the designer working in 2010 on a machine with 2012 installed, you can change the namespaces in the XAML file to use the full assembly name including the version information. But I wouldn't recommend this, since it will have to be removed for the template to work in 2012.
• The 2012 Workflow Designer should work fine if you followed the steps above to "clean" the XAML
• If you get the following error when building your definitions against a recently upgraded build machine, you should restart your build machine service from the TF Admin Console on the build machine.
• TF215097: An error occurred while initializing a build for build definition \Project1 (Dev10)\Simple - Manual: The values provided for the root activity's arguments did not satisfy the root activity's requirements:
  'DynamicActivity': Expected an input parameter value of type 'Microsoft.TeamFoundation.Build.Workflow.Activities.BuildSettings' for parameter named 'BuildSettings'.
• I am not sure what caused this error when I did it, but the fix was pretty simple once I figured it out.
• UPDATE: Several customers have continued to get this error after upgrading even though they restarted their build service. It turns out that these customers had fixed most of their custom assemblies but not all. If you continue to see problems like this one (even intermittently), it means that there is still a build definition that uses assemblies/activities that are compiled against the 10.0.0.0 assemblies. Once the error starts, all subsequent builds fail because the old assemblies are loaded into the build services memory. Only restarting will resolve this issue.
• If you get the following error, you didn't update ALL your custom assemblies to reference the 11.0.0.0 versions of the TF assemblies.
• TF215097: An error occurred while initializing a build for build definition \Project1 (Dev10)\Advanced - Manual: The root element of the build process template found at $/Project1 (Dev10)/MyActivities/MyActivities/AdvancedBuildProcessTemplate.xaml (version C42) is not valid. (The build process failed validation. Details:
  Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error:   Compiler error(s) encountered processing expression "DropBuild AndAlso BuildDetail.Reason = Microsoft.TeamFoundation.Build.Client.BuildReason.ValidateShelveset".
  Type 'IBuildDetail' is not defined.
• If you get any errors like these, the XAML file probably still contains some versioned namespaces.
• TF215097: An error occurred while initializing a build for build definition \Project1 (Dev10)\Moderate - Manual: The root element of the build process template found at $/Project1 (Dev10)/BuildProcessTemplates/ModerateBuildProcessTemplate.xaml (version C31) is not valid. (The build process failed validation. Details:
  Validation Error: Compiler error(s) encountered processing expression "New Microsoft.TeamFoundation.Build.Workflow.Activities.BuildSettings()".
  'BuildSettings' is ambiguous in the namespace 'Microsoft.TeamFoundation.Build.Workflow.Activities'.
  Validation Error: Compiler error(s) encountered processing expression "Microsoft.TeamFoundation.Build.Workflow.Activities.CleanWorkspaceOption.All".
  'CleanWorkspaceOption' is ambiguous in the namespace 'Microsoft.TeamFoundation.Build.Workflow.Activities'.

Problem:

After Upgrading your Visual Studio client or your build machine from 2010 to 2012, you start seeing errors like these…

1. Opening a XAML file in Visual Studio 2012 - System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Exception: The component “Microsoft.TeamFoundation.Build.Workflow.Design.InvokeForReasonDesigner’ does not have a resource identified by the URI…
2. Editing a build definition in Visual Studio 2012 – Unable to cast object of type ‘Microsoft.TeamFoundation.Build.Workflow.Activities.TestSpecList’ to type ‘System.Collections.Generic.List`1[Microsoft.TeamFoundation.Build.Workflow.Activities.TestSpecList]’.      
3. Editing a build definition in Visual Studio 2012 – [A]Microsoft.TeamFoundation.Build.Workflow.Activities.BuildSettings cannot be cast to [B]Microsoft.TeamFoundation.Build.Workflow.Activities.BuildSettings. Type A originates from ‘Microsoft.TeamFoundation.Build.Workflow, Version=10.0.0.0, …’ in the context ’Default’ at location …. Type B originates from ‘Microsoft.TeamFoundation.Build.Workflow, Version=11.0.0.0, …’ in the context ‘Default’ at location ….
4. Building on a TFS 2012 Build Machine - Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "BuildDetail.BuildNumber". Type 'IBuildDetail' is not defined.

Background:

Due to a bug in one of our activities in TFS 2010, the Visual Studio Workflow Designer would add versioned namespaces to the XAML file upon saving it. They look something like this:

xmlns:mtbw1="clr-namespace:Microsoft.TeamFoundation.Build.Workflow; assembly=Microsoft.TeamFoundation.Build.Workflow, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"

The version number in this string forces Workflow to attempt to load the 10.0.0.0 assemblies. These assemblies contain the same types as the 11.0.0.0 assemblies and cause all kinds of problems.

[Update: 9/27/2012]

There is another cause for some of these errors. In addition to checking your XAML, you should also look for any custom assemblies in the Controller's Custom Assembly Path that are compiled against the TFS 10.0 assemblies. Most likely, you will need to recompile any custom assemblies you have against the latest released copies of the .Net framework and the TFS assemblies.

[Update: 10/24/2012]

Fixed a bug in the code below that was removing too many of the namespaces. Some unused namespaces can still be required by the VisualBasic expressions.

Workaround:

Unfortunately, there isn’t a good way for us to fix this problem. Even if we fixed Visual Studio 2010 so that it doesn’t cause the problem, but we can’t prevent those who already have it. The best I could do is create a small program that will strip out all unused namespaces like these from the XAML. Here’s the source code…

[UPDATE: I added some code below to leave in the namespaces listed in the mc:Ignorable attribute found at the top of the file. If you have something listed there that isn't defined, you will not be able to open the XAML in the Workflow Editor.]

using System;
using System.Collections.Generic;
using System.Text;
using System.IO;
using System.Xml;
using System.Text.RegularExpressions;

namespace XAMLCleaner{
    class Program
    {
        static void Main(string[] args)
        {
            if (args.Length == 2)
            {
                if (args[0].StartsWith("/report", StringComparison.OrdinalIgnoreCase))
                {
                    XamlCleaner.RemoveUnusedNamespaces(args[1], args[1], true);
                }
                else
                {
                    XamlCleaner.RemoveUnusedNamespaces(args[0], args[1], false);
                }
            }
            else if (args.Length == 1)
            {
                XamlCleaner.RemoveUnusedNamespaces(args[0], args[0], false);
            }
            else
            {
                PrintUsage();
            }
        }

        static void PrintUsage()
        {
            Console.WriteLine();
            Console.WriteLine("Usage:");
            Console.WriteLine(" XAMLCleaner.exe <xaml_file> [<new_xaml_file>]");
            Console.WriteLine(" - removes unused namespaces from xaml_file and");
            Console.WriteLine(" optionally puts the changes in new_xaml_file.");
            Console.WriteLine(" XAMLCleaner.exe /report <xaml_file>");
            Console.WriteLine(" - prints the unused namespaces found in xaml_file.");
            Console.WriteLine();
        }
    }

    class XmlNamespace 
    {
        public String Prefix { get; set; }
        public String Namespace { get; set; }
        public String Declaration { get; set; }
    }

    static class XamlCleaner
    {
        public static void RemoveUnusedNamespaces(String inputFile, String outputFile, bool reportOnly)
        {
            List<XmlNamespace> namespaces = new List<XmlNamespace>();
            List<String> ignoredNamespaces = new List<String>();
            String fileContents = File.ReadAllText(inputFile, Encoding.UTF8);
            String newFileContents = fileContents;
            Regex ignorableRegex = new Regex("(:Ignorable=\")(.*?)\"", RegexOptions.Singleline);
            Regex regex = new Regex("(xmlns\\:)(.*?)=\"(.*?)\"", RegexOptions.Singleline);

            foreach(Match m in ignorableRegex.Matches(fileContents))
            {
                ignoredNamespaces.AddRange(m.Groups[2].Value.Split(' '));
            }

            foreach(Match m in regex.Matches(fileContents))
            {
                namespaces.Add(new XmlNamespace() { Prefix = m.Groups[2].Value, Namespace = m.Groups[3].Value, Declaration = m.Groups[0].Value });
            }

            foreach (XmlNamespace ns in namespaces)
            {
                // Only remove namespaces that are not in the Ignore section
                // and contain version=10
                // and are not used in the file
                if (!ignoredNamespaces.Contains(ns.Prefix) && 
                    ns.Namespace.IndexOf("version=10", StringComparison.OrdinalIgnoreCase) >= 0 &&
                    !fileContents.Contains(ns.Prefix + ":")) 
                {
                    Console.WriteLine("Removing unused namespace: {0}", ns.Declaration);
                    newFileContents = newFileContents.Replace(ns.Declaration, String.Empty);
                }
            }

            if (!reportOnly)
            {
                File.WriteAllText(outputFile, newFileContents, Encoding.UTF8);
            }
             
        }
    }
}

Examples:

>XAMLCleaner /report DefaultTemplate.xaml

This will list all the unused namespaces, but will not actually change the file

>XAMLCleaner DefaultTemplate.xaml

This will remove all unused namespaces and overwrite the file that was read in.

>XAMLCleaner DefaultTemplate.xaml NewTemplate.xaml

This will remove all unused namespaces and write a new file called NewTemplate.xaml.

We don’t know exactly how we will end up fixing this issue since we don’t want to forcibly change all build process templates. So, for now you will have to fix these up yourself. I recommend a one time conversion of the files and then simply don’t edit them in Visual Studio 2010 any more.

Hopefully this post will save some of you some time.

In TFS 2012, we have completely switched over to Display names in the UI. To make this work consistent everywhere, we repurposed the IBuildDetail fields to show Display names (“John Smith”) instead of account names (“domain\jsmith”). Unfortunately, some customizations need the account name which is unique (the display name is not necessarily unique).

Luckily, it is possible to get this information…

Custom Activities or XAML

In a custom activity (or in the XAML file), you simply need to access the IBuildDetail.Requests[0].RequestedFor field. A build request is really an IQueuedBuild. IQueuedBuild now has RequestedFor, RequestedBy, RequestedForDisplayName, and RequestedByDisplayName. It is also possible to get to the build request from the IBuildDetail object by using the new IBuildDetail.Requests property.

NOTE: It is possible for the Requests property to be empty or to contain more than one item. It may be empty if no build request was associated with the build or if the request was somehow deleted. This situation is rare, but should be accounted for. If you use the Gated check in feature and choose to batch your builds, you can end up with multiple requests per build. This is the only reason you should have more than one request in the Requests property.

Here is a code snippet of how to get this new information:

XAML example:

    <mtbwa:WriteBuildMessage Message="[BuildDetail.Requests(0).RequestedFor]" Importance="High" />

CodeActivity example:

    public sealed class GetRequestedFor: CodeActivity<String>
    {
        public InArgument<IBuildDetail> Build { get; set; }

        protected override String Execute(CodeActivityContext context)
        {
            // Obtain the runtime value of the Text input argument
            string requestedFor = context.GetValue(this.Build).Requests[0].RequestedFor;
            return requestedFor;
        }
    }

Custom Tasks or Targets

Unfortunately, the $(RequestedFor) property has changed in the same way as described above for builds that use the UpgradeTemplate. The fix is basically the same – you need to get to the Request object and get the information from it. However, this requires a custom MSBuild Task, since you can’t get to the properties of the IBuildDetail object directly in MSBuild.

Using an inline Task is perfect for this. Here is an inline Task that you can include in your targets or proj files that will update $(RequestedFor) to the correct value.

In this example, I put this in my TfsBuild.proj file (at the bottom just before the “</Project>” end element.

<UsingTask
    TaskName="GetRequestedFor"
    TaskFactory="CodeTaskFactory"
    AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll" >
    <ParameterGroup>
      <TeamFoundationServerUrl Required="True"/>
      <BuildUri Required="True"/>
      <RequestedFor Output="True"/>
    </ParameterGroup>
    <Task>
      <Reference Include="mscorlib" />
      <Reference Include="Microsoft.TeamFoundation.Build.Client" />
      <Reference Include="Microsoft.TeamFoundation.Build.Common" />
      <Reference Include="Microsoft.TeamFoundation.Client" />
 
      <Using Namespace="System" />
      <Using Namespace="Microsoft.TeamFoundation.Build.Client" />
      <Using Namespace="Microsoft.TeamFoundation.Build.Common" />
      <Using Namespace="Microsoft.TeamFoundation.Client" />
 
      <Code Type="Fragment" Language="cs">
 
        <![CDATA[
           RequestedFor = String.Empty;
           if (!String.IsNullOrEmpty(TeamFoundationServerUrl))
           {
               Uri serverUri = TfsTeamProjectCollection.GetFullyQualifiedUriForName(TeamFoundationServerUrl);
               // Attempt authentication early. On failure, this is where a good error message will be logged
               TfsTeamProjectCollection collection = new TfsTeamProjectCollection(serverUri);
               collection.Authenticate();             
 
               IBuildServer buildServer = (IBuildServer)collection.GetService(typeof(IBuildServer));
               IBuildDetail buildDetail = buildServer.GetBuild(new Uri(BuildUri));
               
               String requestedFor = buildDetail.RequestedFor;
               if (buildDetail.Requests != null && buildDetail.Requests.Count > 0)
               {
                   requestedFor = buildDetail.Requests[0].RequestedFor;
               }


               // Assign the value to the output parameter               
               RequestedFor = requestedFor;
           }
        ]]>
 
      </Code>
    </Task>
  </UsingTask>


  <Target Name="BeforeGet">
    <GetRequestedFor TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)">
      <Output PropertyName="RequestedFor" TaskParameter="RequestedFor" />
    </GetRequestedFor>
    <Message Text="RequestedFor = $(RequestedFor)" />
  </Target>

I am calling the task in the BeforeGet target as an example. It could be used where ever you need it as long as you have the TFS Url and BuildUri.

Happy Building!

Simply add the new activity “WriteCustomSummaryInformation” to your build process template (*.XAML). It has several properties that allow you create a new Section and add text to that section…

• SectionKey – Specifies a unique identifier for the section.
• SectionDisplayName – Specifies the name to display on the Build Details View.
• SectionPriority – Specifies the relative priority of this section.
• Message – This is the string that is displayed inside the section.

Here are some examples of WriteCustomSummaryInformation and what the XAML would look like in notepad…

<mtbwa:WriteCustomSummaryInformation SectionKey="NewSection" SectionDisplayName="My New Section" SectionPriority="75" Message="This is message 1” />
<mtbwa:WriteCustomSummaryInformation SectionKey="NewSection" SectionDisplayName="My New Section" SectionPriority="75" Message="This is message 2. Click [here](http://www.bing.com) to open Bing.com” />
<mtbwa:WriteCustomSummaryInformation SectionKey="NewSection" SectionDisplayName="My New Section" SectionPriority="75" Message="This is message 3. Click [here](vstfs:///WorkItemTracking/WorkItem/1) to open the first work item in this collection.” />

And here is how that would look on the Build Details View…

More Details….

Priorities: 0 is the highest priority for a section. The standard sections start at about 100 and continue in increments of 100 for the most part.

Adding to an existing section: You can find out the Key and priority of existing sections by hovering your mouse over them. Using that Key, you can add messages to the top of existing sections. You cannot remove existing sections but they will take on the priority that you provide. Thus, you could move them to the bottom by providing a very high priority.

Links: By using the syntax [text](link) you can embed hyperlinks into your messages. links that start with “vstfs:” are assumed to be valid TFS artifact links and will be evaluated that way. All other links will be passed to the OS for evaluation.

Customizing the old way: The 2010 way of customizing your Build Details View still works and provides a lot more customization than we have provided in this feature.

I hope this makes your customizations much easier and allows you do more with Build!

Happy Customizing!

Well, in TFS11 we decided to create diagnostic logs all the time. However, we don’t want to slow down the build. So, we write the diagnostic logs to files and copy them to the drop location. These logs are written in an xml format, and we provide a transform to display it nicely in a browser.

From the Build Details View you can click on the new Diagnostics sub menu to View the logs for a completed build. (Note this only works for builds that have a drop location – gated and private builds don’t necessarily have them.)

This menu item will open the drop folder location that contains the logs for this build. From there you can choose which file to open. We generate one file for the controller and one for each agent that was used during the build. So, if you know the error was on the agent you can jump straight there. If you aren’t sure, start in the controller log and you can click on links there that will open the agent logs.

But what about hung builds…

Unfortunately, a build can get stuck in many different ways even in TFS 11. Sometimes the only way to see where the build is stuck is to view the diagnostic logs. Especially since the build may just be going really slow for some reason. You don’t want to have to stop the build to see what’s wrong.

While a build is in progress, the Diagnostics menu contains another option to request that the logs be put on the drop location (it’s called Request Logs).

If you request logs during the build, they will be copied out to the drop location as they are. Once that finishes, the Diagnostics menu will contain a menu item to view the logs produced at that time. Those logs will still exist even once the build is finished. They are placed under a directory that has the date time they were requested as the name.

We hope this will make diagnosing strange build failures a little easier for everyone. It also allows all the paranoid build admins to speed up their builds by reducing the verbosity to Minimal (that’s our new default in TFS11).

Happy Building!

The solution to this problem is not to allow parallel builds and check-ins, because that may lead to broken builds. Rather the solution is to allow the build definition to build more than one queued build at a time (or to Batch the builds). By batching the queued builds, you can increase the throughput almost as much as you want (until you have a build failure – more on that below).

Here’s how this works in TFS11…

On the build definition Trigger tab, you can specify to “Merge and build” gated builds and provide the maximum size for a batch.

When a build starts the TFS server will look at this setting and start the build with the next 5 queued builds from the definition’s queue. The build process has been updated to handle multiple queued builds. This is what it does with the queued builds (also called build requests)…

1. The Sync Workspace activity unshelves the changes from each build request in the order that they were in the queue
2. If one of the shelvesets cannot be unshelved because it conflicts with another shelveset, then that build request is removed from the build and placed back into the queue.
3. All of the changes are compiled together.
4. Tests will run as normal
5. If the compilation or tests fail the build (tests don’t have to fail the build), all of the build requests are returned to the queue and marked to build independently.
6. If the compilation and tests succeed, the changes are divided back up into their appropriate groups and checked in separately on behalf of the user that submitted the gated check-in. So, 5 build requests will generate 5 changesets even though they are built with one build.

In the instructions above, you may notice an algorithm to handle build failures. This is how the default algorithm works:

1. Build 1 starts with 3 build requests
2. compilation fails
3. the 3 build requests are returned to the queue to build again
4. Build 2 starts with just 1 of the build requests and succeeds
5. Build 3 starts with just 1 of the build requests and fails (this was the bad check-in)
6. Build 4 starts with just 1 of the build requests and succeeds
7. Requests 1 and 3 were eventually checked in, but 2 was rejected

Notice that when a batched build fails, you end up building more times than you would have if you didn’t batch at all. This means that you should keep the batch size to a small number. For our builds internally, 5 works well. If you end up with a bad check-in in every batch, you should do one of two things: 1) stop using batched builds or 2) stop letting that dev check-in.

Technically speaking, this algorithm could be changed, but it would be very difficult. We chose a pattern that we felt was simple, effective, and transparent.

Batching builds also leads to some strange relationships between builds and build requests. In the failure case, the first build has 3 build requests associated with it and by the end of the building process, each build request has 2 different builds associated with them. So, we have a many to many relationship between build requests and builds. In Visual Studio, you can see this on the build details window and in the build explorer.

And there’s a new view called the Build Request view. If you click on one of the Request links above you will get to this new view that looks a lot like the Build Details View.

Hopefully, this information will help you understand this new feature in TFS11.

Happy Building!

How does NuGet help you with your build automation?

In short, NuGet allows you not to have to check-in all those binaries that you depend on to build and deploy your application. If you use NuGet, it will simply download all the dependencies at build time.

From the link above or from within Visual Studio, you can install NuGet. This will install a Visual Studio plugin that does all the magic. If you want to know more about the magic of NuGet, check out this post by Phil Haack.

A Quick Example:

In this example, I will simply create a project that uses a simple NuGet package (ELMAH) and builds it on a standard build machine. I already have TFS installed with a Build Controller and Agent ready to go.

Note: I am using TFS11 Beta, so any screen shots are subject to change before release. However, everything I am doing should work in Visual Studio 2010 as well.

First, we need to create our sample application.

Here are my steps:

1. From within Visual Studio, create a new C# Windows Console Application called “SimpleLoggingExample” and add it to source control. (No NuGet stuff yet.) 
2. Add the ELMAH NuGet package to our application by right clicking on the solution in Solution Explorer and choosing “Manage NuGet Packages …”. (This dialog is pretty straight forward: click on Online then use the Search box in the upper right corner to find ELMAH).
3. Now simply click the Install button on the ELMAH package and close the dialog. Now, your solution has the ELMAH package installed and we can start using it.  
4. Go to your Program.cs file and add this code to the Main method:

           static void Main(string[] args)
           {
               Elmah.MemoryErrorLog log = new Elmah.MemoryErrorLog();
               log.Log(new Elmah.Error(new Exception("Hello ELMAH!")));
   
               List<Elmah.ErrorLogEntry> list = new List<Elmah.ErrorLogEntry>();
               log.GetErrors(0, 100, list);
               foreach (Elmah.ErrorLogEntry err in list)
               {
                   Console.WriteLine(err.Error.Exception.Message);
               }
           }

5. Now save everything and test it, but don’t check-in yet. If you press Ctrl+F5 in Visual Studio, you should get a command window with the output “Hello ELMAH!”.

Now, we need to decide what we want to checkin.

By default, NuGet will add all the files needed to build and run your program to the solution (and source control). If you were to simply check-in everything now, the build would work perfectly and your drop location would include everything you need. However, depending on the NuGet packages that you are using this could lead to a lot of extra files in Source Control that you really don’t want to version. So, how do you avoid checking in all those extra files? It is so simple…

1. Right click on the Solution in Solution Explorer
2. Click on “Enable NuGet Package Restore”
3. Click “Yes” when prompted
4. Undo the ‘add’ on the Package folder in your solution
1. Go to the Pending Changes window in Visual Studio
2. Right click the Packages folder
3. Select “Undo”
4. Confirm the undo of all the files under that folder.
5. Check in the solution from the Pending Changes window (make sure all files are checked/included)

After you finish these steps, you have a solution that can be built on any machine. Simply do a “TF.exe Get” to get the files and then use MSBuild or Visual Studio to build it. Part of the build process will download the package and its dependencies for you!

But how do we get NuGet to work on the build machine?

Simple. The build machine will do the same thing that any of your developers or testers would do, get the files from source control and build them. That’s the beauty of NuGet – it is built into your build system. But, to finish the example, let’s walk through the work you have to do to get this solution to build on your build machine.

1. First, with the solution still open in Visual Studio, go to Team Explorer
2. In TFS11 Beta, you have to navigate to the Builds page
3. Then, click on the “New Build Definition” link
4. On the build definition editor window fill in the Build Defaults –> Drop Location (this should be a share usually on the Build Machine itself).
5. All the other settings should be automatically filled in because you have the solution open.
6. Save the definition
7. Go back to the Builds page in Team Explorer
8. Right click on the new definition (SimpleLoggingExample) and select “Queue New Build”
9. On the Queue Build dialog, click Queue.

This should cause a build to start on your build machine. You can watch the progress of the build from the Builds page or by opening up the build by double clicking on it.

You should notice that it succeeds without any errors. The build machine successfully downloaded the NuGet packages for the build. If you open the drop folder, you can see the evidence of it by the fact that the Elmah.dll assembly is there just as expected. And if you open a command window to this folder, running “SimpleLoggingExample.exe” should work as expected.

Well, that’s it! I was totally surprised by how easy this was to set up and get going. NuGet is definitely changing the way that .net applications are built! And if you are a producer of .net libraries, you may want to consider creating a NuGet package for your library and providing it to the world :)

Happy Building!

The only workaround is to restart the service.

To make this a little easier, I wrote a simple console application that will check the service every five minutes and ensure that it is still running. Unfortunately, this application has to run as an administrator because of the security around services. Simply create a Windows Console Application in VS, add a reference to System.ServiceProcess for the project,
and replace Program.cs with this code...

 using System;
 using System.Collections.Generic;
 using System.Diagnostics;
 using System.Linq;
 using System.ServiceProcess;
 using System.Text;
 using System.Threading;
 using System.Threading.Tasks;
 
 namespace KeepAliveBuildService
 {
 class Program
 {
 static void Main(string[] args)
 {
 String serviceName = args.Length > 0 ? args[0] : "TfsBuildServiceHost.2012";
 while (true)
 {
 // Make sure the service is up
 EnsureServiceIsStarted(serviceName);
 // Wait five minutes
 Thread.Sleep(new TimeSpan(0, 5, 0));
 }
 }
 
 static bool EnsureServiceIsStarted(String serviceName)
 {
 try
 {
 var service = new ServiceController(serviceName);
 LogMessage(String.Format("{0} Status {1}", serviceName, service.Status));
 if (service.Status != ServiceControllerStatus.Running)
 {
 LogMessage(String.Format("Starting {0}", serviceName, service.Status));
 service.Start();
 return true;
 }
 }
 catch (InvalidOperationException)
 {
 LogMessage(String.Format("No service with the name {0} could be found.", serviceName));
 }
 catch (Exception ex)
 {
 LogMessage(ex.ToString());
 }
 
 return false;
 }
 
 static void LogMessage(String message)
 {
 String source = "KeepAliveBuildService";
 String log = "Application";
 if (!EventLog.SourceExists(source))
 {
 EventLog.CreateEventSource(source, log);
 }
 
 EventLog.WriteEntry(source, message);
 Console.WriteLine(message);
 }
 }
}

You can run the program interactively on the desktop (remember to run as Admin) or you can create a Windows Service torun the application for you.Please note that this is only a problem for the TFS11 Beta Build Service. We have since fixed the problem and it should not appear in future versions

Sorry about the bug :(