BugGuardian for ASP.NET Core

There is a new member in the BugGuardian family.

Quite a long ago, I've released BugGuardian, a library that allows you to automatically open a Bug or a Task work item on either Visual Studio Team Services or Team Foundation Server if your application experiences an unhandled exception. (Read more here)

After a while, two official extensions where released: BugGuardian.WebForms and BugGuardian.MVC. As the name states, they are targeting the ASP.NET WebForms and MVC respectively, making the adoption of BugGuardian even easier for who is using those platforms. But those 2 libraries have a limit: they only works with the traditional ASP.NET, running on the full .Net Framework.

Today, I'm very happy to announce that the BugGuardian.AspNetCore extension is finally available.

BugGuardian.AspNetCore is specifically written to support ASP.NET Core applications. It adds a Middleware to your application to let you automatically intercept all the exceptions.
And the good thing is that it supports projects with ASP.NET Core using both .Net Full Framework and Net Core.

You can find the source code (and all the information about its configuration) on GitHub here: https://github.com/n3wt0n/BugGuardian.AspNetCore

The package is also available on NuGet, here: https://www.nuget.org/packages/DBTek.BugGuardian.AspNetCore

Happy Coding :)

VSTS - RM & PM in GA, Search for a file and Microsoft Teams

This month we had not one, not two but even three feature release of Visual Studio Team Services!

I had to choose between so many new features to have my top 3 list this month, so it means that they are the very best.

Package Management & Release Management General Availability

Package Management now hosts NuGet and npm packages and helps you manage the lifecycle of your packages with new features like release views. It continues to offer best-in-class support for the latest NuGet updates and great integration with Team Build.

Packages enable you to share code across your organization: you can compose a large product, develop multiple products based on a common shared framework, or create and share reusable components and libraries. Package Management facilitates code sharing by hosting your packages, sharing them with the people you select, and making them easily accessible to Team Build and Release Management.
The Package Management extension is available in the marketplace

Release Management is also available in GA in VSTS and TFS 2017. Using Release Management, you can fully automate the delivery of your software all the way to production. It is an essential element of DevOps that helps your team continuously deliver software to your customers at a faster pace and with lower risk.

To use Release Management, first create release definitions and then configure environments and specify automation steps in each environment to deploy the software and run tests against it. You can set up automatic deployment to the environments as soon as the build is available to deliver value continuously to your customers. You can also configure approvals on each environment.

Search for a file or folder in commit history

Similar to the files tab, users can now search for a file or folder in a repository and see the history of commits for that file or folder. For any Git repository, go to the path control box on the History tab and start typing to initiate a history search experience for the file or folder you are looking for.

Microsoft Teams integration

Microsoft Teams is a new chat-based workspace in Office365 that makes collaborating on software projects with Team Services a breeze. Team Services users can stay up to date with alerts for work items, pull requests, commits, and builds using the Connectors within Microsoft Teams. Starting November 9, users will also be able to bring their Kanban boards right into Microsoft Teams.

WorkItems History: My first extension for VSTS and TFS

I'm very excited and proud to share with you the first version of my very first Extension for Visual Studio Team Services and Team Foundation Server: WorkItems History.

What

WorkItems History is an extension that adds a "History" hub to the Work section of VSTS/TFS and allows you to see the history of the added/modified work items.

Why

Working in a team is not always easy, especially when you need to have "things under control". With this extension, you can have a little more control of what is happening on your work.

Other info

I decided to release this extension as Open Source Software.

You can have a look at its GitHub page (https://github.com/n3wt0n/WorkItemsHistory) and, if you wish, you can contribute to the project. Please refer to Contribution guidelines and the Code of Conduct for more details.

Usage, support and Feedback

The extension is publicly available on the VS Marketplace, at this link: https://marketplace.visualstudio.com/items?itemName=DB.WorkItemsHistory

You can take a look at the GitHub repo to find more information on usage or installation of the extension.

If you encounter any issue using this extension, please let me know through the Issues page on GitHub and I'll fix the problem as soon as possible!

I'm waiting for your feedback :)

Data and News from Connect(); 2016

On Wednesday, November 16, 2016, Microsoft demonstrated at Connect(); 2016 its vision of enabling the future of development with solutions that serve any developer, any application and any platform.

They have also shared some very interesting data about services and products adoption:

• More than 20 million Visual Studio 2015 installs (with the free Community edition representing more than 14 million of those)
• 1 million Visual Studio Code monthly active users (MAU).
• 4.6 million registered Visual Studio Team Services users
• More than 25,000 developers from 1,700 companies have contributed to .NET Core and related open source repositories, with nearly 2/3 of the contributions coming from outside Microsoft.
• 1 million Visual Studio Dev Essentials members
• Half-a-million more Xamarin users since the acquisition, a 3x increase over the company’s previous growth rate.
• 20,000- registrations for the SQL Server on Linux private preview, including over 50% of the Fortune 500.
• 1.6 million Azure SQL Databases in the cloud and over 100 billion queries per day
• More than 120,000 new Azure subscriptions/month
• Approximately 1 out of 3 VMs on Azure are Linux
• 35% month over month growth of Microsoft Graph in past year.
• 47,000 active third party applications built using Microsoft Graph and more than 1 billion API transactions on Microsoft Graph
• More than 400M Windows 10 devices
• The Windows 10 Cortana search box now has over 141 million monthly active users

Brian Harry has written a very good blog post (read it here) with all the announcements about TFS and VSTS. Take a look at it!

VSTS - Manual deploy, Git imports and Queues

Here we are for a new episode of my personal "top 3 new VSTS features" series. Let's talk about September.

Deployment manual intervention

You can now pause execution during deployment to an environment. Including a Manual Intervention task enables you to pause a deployment, perform manual steps, and then resume further automated steps. You can also reject the deployment and prevent further steps from executing after a manual intervention.

You should note that a manual intervention task splits the overall execution into three phases. 

• The first phase runs on an agent, and after it is done, the agent is released. 
• The manual intervention phase does not require any agent. 
• After it is completed, any tasks following the manual intervention task are run in the third phase, possibly on a different agent. The artifacts are downloaded during both the agent phases, since different agents may be used for both of them. You should not assume that the state from the first phase is available during subsequent phases.

Import Git repositories

We can now import a Git repository from GitHub, BitBucket, GitLab, or other locations, into Visual Studio Team Services. You can import into either a new or an existing empty repository.

To import into a new repository, from the repository selector drop-down, click Import repository. 

If the source repository is a publicly available repository, then simply provide the clone URL of the source repository and you are good to go.

However, if the source repository is a private repository and can be accessed using basic authentication (username-password, personal access token, etc.), then check the “Requires authorization” check-box to provide the corresponding credentials.

Instead, to import into an existing empty repository, on the Files page, click the Import repository button and provide the clone URL. You will need to provide credentials if the source repository is private and requires authentication.

Build queue tab

They've implemented a new design for the Queued builds page that shows a longer list of queued and running builds, and in a more intuitive fashion. Looks good...

About Xamarin build (again)

Back in April, in one of my posts (read it here) I explained  that it was no more necessary to  include the "Xamarin License step" when building Xamarin solutions using the Hosted Agents.

Starting from now, it is no more necessary to include this step for every Xamarin builds, for both Hosted and personal agents.

Indeed, as reported on the new Visual Studio Team Service update: 

The Xamarin License step is no longer necessary and has been removed from the build templates shipped with VSTS and TFS 15. As part of this effort we will also deprecate the task. All build definitions that use this task should be updated to remove it in order to prevent any disruption when the task is finally removed.

Have good builds ;)

VSTS - New features for Build & Release

Microsoft has published a new feature set for Visual Studio Team Services which brings some very interesting new things to the tool.

Build and release summaries

There are two new bits of information that will show up on the build and release summaries. 

First, you’ll notice that console logs are now available in the Test pivot. Console logs are published as test result attachments and can be previewed in the Tests tab in the Build summary and Release summary panes.

Second, it’s very common to need to understand and identify test cases or containers that take the most time to run. You can now find this information by sorting the Duration column in the Tests tab in the Build/Release summary panes. In addition to the duration of individual tests, you can also look at aggregate duration of test containers or test runs by grouping by the respective pivots.

Release Management improvements

This release brings with it quite a few Release Management (RM) improvements. Let’s walk through the new capabilities…

First, Release Management now supports linking repositories (both Git and Team Foundation Version Control) as artifact sources directly to a release definition, enabling you to consume resources in your repos without having to publish build artifacts with the same files. Note: There is no support yet for auto-triggering new releases when a commit is made into these repositories, but that work is in flight, so stay tuned.

Additionally, you’ll find these new features:

• Copy, Export, Import. A new extension has been published in the Marketplace that lets you copy, import, and export release definitions.
• Schedule Based Deployment Condition. You can now configure a condition on an environment to pick up the successful deployments (or the latest one) from another environment and promote them at the selected time. This capability allows you to have time-based deployments that happen on a repeatable schedule. Chose the Deployment Condition tab in your environment to configure the schedule.
• Release Management REST APIs. You can now use the REST APIs for Release Management service. They are published at: https://www.visualstudio.com/en-us/integrate/api/overview. Most of these APIs work with the on-premises releases of RM features in TFS 2015 Update 2 as well (changes between TFS and Team Services versions are indicated in the API docs). 
• Simplified Release Definition Wizard. The wizard to create release definitions has been simplified. You can enter most of the inputs to setup a definition with a single environment in this wizard. They have also simplified the process for adding more environments into a definition or to clone an environment. 
• New Job Execution Variables. Below are a set of variables now available that let you access information about artifact sources when executing deployment jobs. These variables are available in the format: RELEASEARTIFACTS_. represents the artifact source that is included in the release definition. You can find the name of the alias in the Artifacts tab of a release definition. 
  DEFINITIONID BUILDNUMBER BUILDID REPOSITORY_NAME SOURCEBRANCH SOURCEBRANCHNAME SOURCEVERSION BUILDURI REQUESTEDFORID REPOSITORY_PROVIDER REQUESTEDFOR TYPE
  Note: For scripts, replace the underscore with a period.

Introducing BugGuardian.MVC and BugGuardian.WebForms

Today I'm very excited to announce that I have released two additional modules for BugGuardian.

For who doesn't know it, BugGuardian is a library that allows to easily create a Bug or a Task work item on your Visual Studio Team Services account or on your on-premises Team Foundation Server 2015 in the case your application throws an Unhandled Exception.

To better support the integration of this library with web projects, today I'm announcing the availability of BugGuardian.MVC and BugGuardian.WebForms.

BugGuardian.MVC (GitHub, NuGet) is an extension for BugGuardian specifically written to support Asp.net MVC applications. 

It adds an Action Filter to your application to let you automatically intercept all the exceptions.

BugGuardian.WebForms (GitHub, NuGet), instead, is an extension for BugGuardian specifically written to support Asp.net WebForms applications.

They are based on the new BugGuardian version 1.3.0 and they support projects written with the .Net Framework v4.0 and above.

As it is for BugGuardian, these two additional libraries are OSS so feel free to see their code on GitHub.

If you encounter any issue using these libraries, please let me know through the GitHub Issues pages and I'll fix the problem as soon as possible!

Again, I want to thanks my friend and fellow MVP Marco Minerva (@marcominerva, GitHub) for the support and the suggestions.

Welcome BugGuardian

Someone of you has maybe noticed the I did only few post in the last months. This happened because of two main reasons.

The first one is, as some of you already know, I moved in another country far away from home, with a completely different culture and language, to start a new adventure. This inevitably took a lot of time from the already small amount of spare time I have.

The second reason I wasn't so active here, that is also the reason of this post, is that I worked on a new project that I have released today: BugGuardian.

What is BugGuardian

BugGuardian is an Open Source library, written in C# like Shared Project, that allows to easily create a Bug work item on your Visual Studio Online account or on your on-premises Team Foundation Server 2015 in the case your application throws an Unhandled Exception.

It can also be invoked manually in try/catch blocks to keep track of handled exceptions.

It supports applications written with the .Net Framework v4.0 and above, and it can be used on every kind of project, including:

• Asp.net
• Asp.net MVC
• WPF
• Windows 8 / 8.1 Apps
• Windows Phone 8 / 8.1 Apps
• Universal App
• Universal Windows Platform Apps (Windows 10)
• and so on...

As I mentioned, it is OSS so you can find the sources on GitHub.

To let you install and use it without having to build the sources by your own, I have published it on NuGet. Just search for BugGuardian in the Package Manager GUI or run the following command in the Package Manager Console:
Install-Package DBTek.BugGuardian

Usage, support and Feedback

Refer to the project documentation to find examples about how to use this library. You can also find some code samples in the TestApps folder.

Anyway, just to make an example and to show it's really simple to use, this is the code you need to manage an exception and to open a Bug on your VSO / TFS:

using (var creator = new DBTek.BugGuardian.Creator())
{
    creator.AddBug(myException);
}

If you encounter any issue using this library, please let me know through the Issues page and I'll fix the problem as soon as possible!

I'm waiting for your feedback :)

I want to thank you my friend and fellow MVP Marco Minerva (@marcominerva) for the support, the patience and the Code Review.

Deploy a Web App to Azure with the Visual Studio Online Build

In this post we are going to see from sratch how to deploy a solution to an Azure Web App using the new Visual Studio Online Build platform.

To do it, we will use only the web portal of VSO.

Connect Azure to VSO

First of all we have to let Visual Studio Online know that we have an Azure account we want to use as deploy endpoint for our solution. Go the the Team Peoject Settings page (clicking on the button in the upper right corner of the project page), click on the "Services" tab, then on "Add new Service Connection" and then on "Azure".

At this point a pop-up will appear and we have to insert the ID of the Azure subscription which contains or will contain the Web App to publish, a name for it and the authentication mode.

We can use either a subscription certificate or the credentials.

When done, our Azure subscription and our VSO account will be connected (for this project).

Create the build definition

Now that we have linked VSO and Azure, let's go to the Build section of the project and create a new deployment build definition.

We eant to deploy to Azure, so in the "Deployment" section click on "Azure Website" (like shown in the image).

This creates a new build definition with some steps to configure.

Let's see how to proceed step-by-step.

The first one is the "real" build task. It's completely customizable but the most important thing is to define the solution file it has to use as build source. Select it like shown in the image, near the red arrow.

In the second step we have to set the how to execute the post-build Unit Tests. If we don't have unit tests (that is bad...) or we don't want to execute them (also this is bad :) ), we can safely remove this step using the "X" button that appears when the mouse pointer is over it.

The third step is the most important one for our scenario, because it publishes the build result to the Azure Web App.

In its settings there is a drop down where to select the target Azure subscription (if the previous Azure service connection worked properly). Then, in the "Web App Name" textbox, we have to write the name of the Web App we want to deploy. In theory this also appears as a drop down itself, but currently it doesn't load the existent Web Apps names (don't forget that the new Build platform is still in preview)

For this reaso, here I've written down some notes about the Web App name

• If we use a non-existent Web App name, it will create it on our Azure subscription using the selected region
• If we use a Web App name that doesn't exist in our subscription but which already exist in the selected region, the deploy process will fail
• If we use a Web App name that already exists in our subscription but it is in a region different from the selected one, the deploy process will fail
• If we use a Web App name that already exists in our subscription and it is in the selected region, the deploy will use it as target and will update it.

So pay attention about what we write :)

The two remaining steps allow us to index and to publish the application symbols (suggested, to have more information in the case of unhandled exceptions) and to publish the build artifacts somewhere.

When all the parameters are set we can go ahead and save our build definition, giving it a name.

We can also change all the default parameters in the upper tabs to customize the build process accordingly our needs.

Let's deploy!

Now that we have completed all the customizations, it's the moment to launch the build and to verify that the deploy works fine.

To start the build, click on the "Queue build" button in the build definition toolbar or in the contextual menu.

When we click on that button, VSO will queue a build based on our build definition and will execute it either on our servers or in a Microsoft Datacenter (if we have chosen to do it with the hosted agents).

Anyway, the build progress will be shown in the real time web console that appears as soon as the build is queued.

When is starts, it firstly execute the build and test tasks:

Then, if both are successful, the deploy to Azure:

When all the tasks will successfully finish, we have our web application deployed and running on Azure. Easy!

Place the Database under Source Control - free eBook

Normally, a Source and Version control system shows huge benefits in coordinating the efforts of the development team, ensuring a complete audit trail of all changes to the code files, and allowing the team to reproduce any specific revision or build.

Database developers can and should also benefit from source control's audit history and change-tracking capabilities, but there's more to it than simply placing a few database build scripts into a subfolder of the application development team's project folder in source control. Unlike application developers, database developers are not assembling files into a neat little application package, but are instead running scripts that feed off each other and off existing database objects, while negotiating the close interdependency between the code and the data.

To cover what we can call "Database Lifecycle Management", and consider it a branch of ALM, RedGate has developed an interesting free ebook, called "SQL Server Source Control Basics"

Unfortunately, the book's authors decided to use SVN, but you can take the core concepts and bring them to Team Foundation Server or Visual Studio Online as well.

Topics include:

• Source control core concepts
• Choosing a database version control system and structure
• Branching and merging strategies
• Automating database versioning and deployment from source control
• An introduction to database continuous integration

The eBook gives a detailed walkthrough of database source control concepts, with code samples and clear examples.

You can download it, for free, here:

http://www.red-gate.com/products/sql-development/sql-source-control/entrypage/sql-server-source-control-basics

Integrate an application or a service with Visual Studio Online - MSDN Guest Post

On friday was published on MSDN Italy my second Guest post in which I talk about how is possible and easy to integrate our applications or services with Visual Studio Online using the new REST APIs and the Service Hooks.

To read the whole article (available only in italan) just clik on this link:

Integrare un’applicazione o un servizio con Visual Studio Online

Easily migrate from Team Foundation Server to Visual Studio Online - MSDN Guest Post

Today was published on MSDN Italy my Guest post in which I explain how to migrate from a Team Foundation Server (the normal on-premises installation scenario) to its corresponding on-cloud version Visual Studio Online and which are the reasons that could push to do so.

To read the articlae (available only in italan) just clik on this link:

Migrare facilmente da Team Foundation Server a Visual Studio Online

Azure Web Sites Deployment: how does it work?

Azure Web Sites supports continuous deployment from source code control and repository tools like BitBucket, CodePlex, Dropbox, Git, GitHub, Mercurial, and TFS/VSO. You can use these tools to maintain the content and code for your web site, and then quickly and easily push changes to your site when you want.

Supported Deployment types

Pushing local files to Azure by using Local Git allows you to manually push updates from a local project to your Azure Web Site, while deploying from BitBucket, CodePlex, Dropbox, GitHub, or Mercurial results in a continuous deployment process where Azure will pull in the most recent updates from your project.

While both methods result in your project being deployed to an Azure Web Site, continuous deployment is useful when you have multiple people working on a project and want to ensure that the latest version is always published regardless of who made the most recent update. Continuous deployment is also useful if you are using one of the above mentioned tools as the central repository for your application.

On the net there are plenty of articles explaining how to deploy an Azure WebSite (i.e. http://azure.microsoft.com/en-us/documentation/articles/web-sites-deploy/) or how to implement Continuous Deployment strategies (i. e. http://azure.microsoft.com/en-us/documentation/articles/web-sites-publish-source-control/).

But how does it work behind the scenes?

Well, the answer is "Kudu".

Kudu is the engine behind deployments in Azure Web Sites, but it can also run outside of Azure.

It has a somewhat unusual architecture, in the sense that it is a single-tenant rather than multi-tenant service. What this means is that each Azure Web Site has its own instance of the Kudu service, completely distinct from the Kudu service sites used for other Azure sites.

It stays active in background and "watches" for checkins, commits, new files, completed builds and so on. When it detects something, KuduSync starts and do the "dirty work".

It's a great tool, because:

• it’s an open source project available on GitHub (https://github.com/projectkudu/kudu)
• it's automatically installed on all Windows Azure Web Sites
• it can use a custom deployment script

But the most important thing (imho) is this:

The deployment is created in your website’s folder structure and the new deployment is copied to your site’s root, leaving old deployments intact.

This means you can "rollback" to any deploy you've done in the past. This, for me, it's a killer feature!

It's also possible to have access to the Kudu web dashboard, using an url like "https://your_website_name.scm.azurewebsites.net/" and your deployment credentials or your Azure service admin credentials.

Kudu Dashboard

In the Kudu dashboard you can find a lot of useful informations about your website's environment together with a set of tools to manage your website and, last but not least, a complete set of REST APIs. There is also the possibility to manage WebSites extensions.

There is also a great video where David Ebbo and Scott Guthrie explain how Kudu works: http://channel9.msdn.com/Shows/Azure-Friday/What-is-Kudu-Azure-Web-Sites-Deployment-with-David-Ebbo

Visual Studio Online now supports Azure Active Directory

Yesterday the Microsoft's vsalm team began deployment of the sprint 68 work.

The biggest thing in the announcement is the next step in the rollout of Azure Active Directory (AAD) support in VS Online.  They started this journey back in May with the very first flicker of AAD support at the Build conference.  Then they added more support at TechEd but they've stay pretty quiet about it because, until this week, there was no way to convert and existing account to AAD.  With this deployment they’ve enabled it.  Officially it’s in preview and you have to ask to get access to do it but they’re accepting all requests so it’s nothing more than a speed bump to keep too big a rush from happening all at once.  With these last set of changes, you can:

• Associate your OrgID (AAD/AD credentials) with your MSDN subscription, if you have one, and use that to grant your VSO license
• Create a new account bound to an AAD tenant
• Bind an existing account to an AAD tenant
• Unbind an account from an AAD tenant
• Log in with either a Microsoft Account or and OrgID (AAD only or synchronized from you on prem Active Directory) giving you single sign-on with your corporate credentials, Office 365, etc.

To see all the details about AD support and other things included in the update, read the original post on MSCD by Brian Harry.

Visual Studio Online licenses will change (in better)

Through the fall and spring, Visual Studio Online transitioned from Preview to General Availability.  That process included changes to branding, the SLA, the announcement of pricing, the end of the early adopter program and more.

Now, the VSO/TFS team has decided to roll out these 2 major licensing changes in the next couple of months:

• any VS Online account will be able to have an unlimited number of “Stakeholder” users with access to the a subset of functionality, at no charge.
• the Visual Studio Online Advanced plan will include access to all of the Test hub functionalities 

The team is working hard to implement these licensing changes now and the expectation is that they’ve got about 2 sprints of work to do to get it all finished.  That would put the effective date somewhere in the neighborhood of mid-August.

In general, the team goal is to keep the licensing for VS Online and Team Foundation Server as “parallel” as they can – to limit how confusing it could be.  As a result, they will be evolving the current “Work Item Web Access” TFS CAL exemption (currently known as “Limited” users in TFS) to match the “Stakeholder” capabilities.  That will result in significantly more functionality available to TFS users without CALs.  The hope is to get that change made for Team Foundation Server 2013 Update 4.


Here you can find the original announcement by Brian Harry:
http://blogs.msdn.com/b/bharry/archive/2014/07/09/upcoming-vs-online-licensing-changes.aspx

Delete work items from TFS or VSO

Have you ever created a bunch of work items that you decided later that you had to delete. Well I have… especially as a user of the TFS Integration Platform. And when things go wrong there they can really go wrong.

Now while you can put stuff into the “removed” state it is still hanging around cluttering up the place. The only way out of the box to remove items is to give the ID for each work item that you want to delete and execute the command line for each one:

witadmin destroywi /collection:CollectionURL /id:id [/noprompt]

Well that’s just great unless you have a couple of thousand things to delete. 

So I've written a little bit of code to do it for me; in this example I created a small console program but you can use the same code in any kind of project.

using Microsoft.TeamFoundation.Client;
using Microsoft.TeamFoundation.WorkItemTracking.Client;

[...]

TfsTeamProjectCollection tpc = new TfsTeamProjectCollection(new Uri("http://your_tfs_url:8080/tfs/CollectionName"));
WorkItemStore store = tpc.GetService();

string query = @"SELECT [System.Id] FROM WorkItems WHERE [System.TeamProject] = 'projectName'  AND  [System.AreaPath] UNDER 'projectName\_TOBEDELETED' ORDER BY [System.Id]";

WorkItemCollection wis = store.Query(query);
var wisIds = wis.Select( wi => wi.Id);

Console.WriteLine(string.Format("DESTROY {0} work items (they really can't be resurrected): y/n?", wis.Count));
ConsoleKeyInfo cki = Console.ReadKey();
Console.WriteLine();

if (cki.Key.ToString().ToLower() == "y")
{
 try
 {
  Console.WriteLine("Deleting....");
  var items = store.DestroyWorkItems(wisIds.ToArray());
  Console.WriteLine("DONE");
  foreach (var item in items)
  {
   Console.WriteLine(item.ToString());
  }
 }
 catch (Exception ex)
 {
  [...]
 }

}

Console.WriteLine("Finished");

The first thing that you may notice is that I search for items in a specific area path. I use _TOBEDELETED as it is obvious what is going to happen to things that end up there. Although I did work with a user who complained that all his files had gone missing. When asked where he kept them he pointed at the recycle bin on his desktop!

Anyhow, just in case you made a mistake it will let you know how many work items that you are deleting. It’s a simple check but I have had it say "100000" work items... AS you can imagine I very carefully terminated the program (never trust the 'no' option).

Work Item Query Language in URL with TFS2013

As many of you surely already know, it's possible to wuery work items in TFS sending a direct url to the server.

In TFS 2008/2010 the url syntax was:

http://<ServerAddress>:8080/tfs/<TPC Name>/q.aspx?pname=<Project>&wiql=<WIQL>

But in TFS 2012/2013 it doesn't work. Indeed, they have changed the url format to the following:

http://<ServerAddress>:8080/tfs/<TPC Name>/<Project>/_workitems#_a=query&wiql=<WIQL>

Where:
TPC Name  is the name of the project collection
Project is the name of the project you want to query against
WIQL is the query written in the "Work Item Query Language"

Visual Studio Online (VSO) vs Team Foundation Server (TFS)

This blog post compare the current feature set of Microsoft's hosted TFS solution – Visual Studio Online (VSO) and the on-premises Team Foundation Server product.

Feature Comparison

	TFS	VSO
Work Items, Version Control, & Build	Yes	Yes
Agile Product/Project Management	Yes	Yes
Test Case Management	Yes	Yes
Heterogeneous Development (Eclipse, Git, ...)	Yes	Yes
Ease of Installation and Setup	+/-	++
Collaborate with anyone, from anywhere	+/-	++
Data stays inside your network	Yes	No
Process Template & Work Item Customization	Yes	No
SharePoint Integration	Yes	No
Data Warehouse & Reporting	Yes	No
CodeLens Support	Yes	No
Cloud Load Testing	No	Yes
Application Insights	No	Yes
Always running the latest version of TFS	No	Yes

Some other limitations of VSO (currently):

• No Data Export (there are plans to make it available for a short time period)
• No Data Import (if you want to move from on-premises TFS to VSO)
• No Integration with Active Directory (users sign in using Microsoft Accounts)
• No choice of geographic location (data stored in data center in Chicago)

Delete a project from Team Foundation Service

Since the "Team Foundation Service" hasn't an administrative console, it's not possible to use it to delete a hosted project.

So to delete a team project from one Team Foundation Service collection you have to use the "tfsdeleteproject.exe" command line tool:

tfsdeleteproject /collection:https://<your collection>.VisualStudio.com/DefaultCollection <"Project Name">

For further information, see: http://social.msdn.microsoft.com/Forums/en-US/TFService/thread/81997146-a64f-43fb-9952-57d71542cd11