TFS Online - Deleting projects (TFSPreview.com)

Deleting Projects from TFS Online (TFSPreview.com)

After using the online hosted version of Team Foundation Server (TFS) and enjoying the high availability for some time, i recently needed to delete a project. One thing missing right now from the GUI is the menu item that performs a 'delete project'. We should always take care when performing deletes of our projects but sometimes it becomes necessary, especially when learning or playing around with new platforms and features.

TFS has had a number of command line tools for some time which can usually perform the widest range of services (and quite often get called by the GUI commands). One such tool is TFSDeleteProject.exe, and it enables deletes of projects.

It took me a couple of attempts to get the command line syntax right so i thought i would share it here. It's useful to recognise that the hosted version of TFS is actually creating a single default collection to host your projects named "DefaultCollection" and your command line parameters need to include a reference to it as well as shown below:

typing /? into the command line window produces: TFSDeleteProject [/q] [/force] [/excludewss] /collection:URL TeamProjectName which translates to:

tfsdeleteproject /collection:assemblysoft.tfspreview.com/DefaultCollection/ projectX

You will be presented with a login dialog to authenticate and you must be have permissions to delete (This can be set online), but if you are the creator, you most likely already do. The command line console will then show the following:

When the need arises to complete an action in TFS not obvious from the GUI menu, find the command line tool and use from the VS2012 command shell.

Checkout some other musings via my blazor.net and azure blog here carlrandall.net

Windows Azure Storage Emulator failed to install

CodeProject Windows Azure Storage Emulator failed to install When attempting to install a new version of the Azure Storage Emulator either as a separate installation package or automatically as part of an Azure SDK update, you may run into an error message which states the storage emulator has failed to install. This can occur using the Web Platform Installer (WebPI), NuGet Package Manager or when performing the install manually. Below is the message received using the WebPI. Storage Emulator Background (optional reading) The windows azure storage emulator executable lives under the Microsoft SDKs directory as shown below: Configuration If we take a quick look inside the WAStorageEmulator.exe.config file we can see each of the storage services pointing to local service endpoints. <StorageEmulatorConfig> <services> <service name=" Blob " url="http://127.0.0.1:10000/"/> <service

Azure Devops - Pull Request Merge Conflicts

Before a Git pull request can complete, any conflicts with the target branch must be resolved. Out of the box, at the time of writing this article, Azure DevOps requires this to be resolved locally. Following best practices to not allow direct commits to our release/master branches further exasperates the problem as we need to effectively clone the branch or go with a rebase approach, both of which break the natural flow of resolving the conflicts as part of the pull request. With this extension, from the Microsoft DevLabs team via the Marketplace, you can resolve these conflicts online, as part of the pull request process, instead of being forced to break flow and resolve locally. Online Experience After adding the extension the new conflicts tab is visible which enables conflict resolution in the familiar side by side review page as shown below: Really nice extension, which should make resolving merge conflicts a much more straightforward part of the DevOps

Azure DevOps Authorisation

Managing whether an identity has access to a given service, feature, function, object, or method in Azure DevOps comes down to authorisation. Fortunately, by default, the DevOps permissions are set in such a way to enable you to focus on the job at hand, DevOps. Loosely translated this means 'don't get in my way'. My experience is that the Azure DevOps team have done a good job at this, enabling you to crack on developing, building, testing and releasing without much hindrance. Working with relaxed permissions is great when you are the owner and possibly either a one man band or small team but as soon as we need to consider larger teams, varying roles with approvals and degrees of access, authorisation becomes a real concern. I was recently involved in a project utilising offshore developers where trust was a concern and a number of specific teams handling specific roles needed to come together to approve a set of pipelines. This article is a pick of findings a

.Net Development, Azure, DevOps, Ideas and Life...

Search This Blog