Changing the scope of the AssignedTo field in TFS 2010 Work Items

This post is related to changes for Team Foundation Server 2010 but a similar process can also be followed for TFS 2008.

For so long I’ve been meaning to sort out the list of names that appear in the AssignedTo dropdown list when creating work items. This evening I’ve been making some changes to our work item Status workflow following some positive feedback from the QA team and so finally got around to fixing this.

By default it will show all of the Active Directory users that have access to the project. That unfortunately includes all of the system administrators and service accounts, TFS related or otherwise that will be imposed upon you through group policy.

What we need is the ability to restrict this list to only those people pertinent to the project. At the simplest level that would be those people within the TFS Project Contributors group. In a future post I’ll look at filtering this list further based on additional attributes of the work item. For example, subsequent to setting the status to Triaged, you may only want to assign to members of the development team. For now let’s keep it simple.

I’m going to assume you’re comfortable with the TFS Power Tools (available as an Extension in VS 2010) as it’s through the Process Editor available in this extension that we’ll be making our change.

You have a couple of choices here. You can either edit the Work Item Template against a Process Template or as I’m doing directly for now, against the WIT for an existing project.

Select the Work Item Type from the appropriate project in the dialog that pops up and you’ll be presented with the Work Item Editor screen thus:

Double click Assigned To and select the Rules tab on the dialog

You won’t have ALLOWEDVALUES in your list. It’s the setup of this rule that filters the list of displayed names.

Click New and enter the name of the TFS group you want to restrict the list to.

In our case I’m restricting to the Contributors group for the current project. Note the highlighted [project] should be as is and not substituted for your own project name.

Close down all the dialogs and save the template (either import if you exported or just save). If you did this against an existing project go in and create a Work Item of the modified type and hopefully you’ll see a much cleaner list. If your AD is setup correctly it’ll pull in Full Name otherwise you’ll get just the login name.

I hope this is of some use and please don’t be afraid to get stuck into modifying your process templates and work items. Whilst it’s always a good idea to start with the OOB template never be afraid to modify it to suit your own needs. Especially if in our case it helps in getting some real usage out of TFS

Summary

You can restrict the names that appear in the AssignedTo list by adding an ALLOWEDVALUES rule to the attribute within the Work Item Template.

NuGet Version Control Workflow

With the release of NuGet 1.6 we now get the ability to control the importing of dependent packages at build time through the injection of a custom .target file into each project within the Visual Studio solution. This may seem unusual for teams that use Team Foundation Server for version control as we typically like to see those binaries included as part of the check-in process into the usual lib/dependencies/third-party (delete as appropriate) folder.

So why have the NuGet team done this? Well mainly for the DVCS teams as their repositories can grow quite large with all these binary check-ins causing merges to take significant amounts of time. But even if you don’t use a DVCS such as Git or Mercurial simply having this option available to us for any version control workflow is simply awesome in my opinion. I think I’ll be checking out how it works for comparison on an upcoming small project.

For now if you want to use the “source control free” workflow you can enable it at the solution level.

 

NuGet just continues to get better and better and with one of the Project Leads Phil Haack now working at GitHub I’m even more excited to see where the product goes. Further information on this new feature is available on the NuGet docs site here.

Delete orphaned branches in TFS 2010

I recently found myself in a situation in our TFS Source Control where I wanted to convert a main folder into a branch. However I was presented with an error message telling me that I couldn’t do this as a branch already existed below this folder. It turns out that a branch had previously been created incorrectly and then subsequently deleted. However, if you delete a branch its relationship remains and prevents you from branching its current parent.

I found the following blog post provided me with the answer. But more usefully it showed me the ‘show deleted items’ checkbox that gives you a much better historical view IMO of the Source Control structure. Maybe this should be the default view with the option to turn it off rather than on?

AppFabric and WAS 1 Windows Service 0

We recently received a proposal from a supplier for their integration into our backend stock control system. A requirement of the solution is asynchronous communication in both directions so MSMQ was recommended as expected. However, I was surprised to see the implementation their side for processing messages was a Windows Service. The platform is entirely Windows Server 2008 and .NET 4.0 so the choice of a Windows Service which carries with it all of the responsibilities of appropriate application management is in my opinion the wrong choice.

The “better” solution in the absence of a full Service Bus (Biztalk etc) would be implemented using Windows Activation Service (WAS) hosted WCF/WF Services enriched by AppFabric. This feature set provides so many functional and operational benefits; I struggle to see where a valid use case exists for implementing any messaging solution via a Windows Service. That’s a broad statement that can’t hold true for all requirements but I believe architecturally when the discussion turns to a Windows Service we should be asking the question “Why shouldn’t we do this in IIS/WAS and AppFabric?” rather than “Why should we?”

Below are some of the benefits (not just limited to message queuing) of WAS and AppFabric you can leverage without writing a line of additional code

1. Leverage common deployment practices through MSDeploy
2. WAS alone (via the IIS Process Model) will provide significantly enhanced Process Management through built in and easily configurable:

• Recycling
• Throttling
• Security
• Scalability (shared worker process where appropriate)

 

1. AppFabric will provide (again through easy configuration):

• IIS Management Console integration giving visibility into configurable searchable metrics via the AppFabric dashboard.
• Workflow Persistence including idle time management
• Caching Services (additional install)
• Configurable Service Auto Start (requires Server 2008 R2)
• WCF Endpoint Management
• Easy configuration of WCF/WF Event Tracing
• Easier integration of custom monitoring services (i.e. a custom system reporting website)
• Pluggable tracking/tracing profiles
• Easier integration for reporting into SCOM (additional install pack)

Significantly, AppFabric Server will also provide you with a head start (albeit a small one) into the runtime framework of Azure AppFabric as the two offerings begin to converge over the next few years.

I hope this post has proven useful to someone looking at delivering application services that might otherwise have considered a Windows Service to be their only option. AppFabric is available through the Web Platform Installer and further information on Windows Server AppFabric can be found here.

Options for Mobile Application Development

This post is based on my interest recently in current mobile development offerings. Not the specifics of implementation but more around what options are available to us as developers. In this post I won’t be going to go into any specifics as I’m just putting this post out there as a starter for where my current thinking lies. Over the next few months I’m hoping to expand on this with more specifics on the choices available.

In an entirely fictitious scenario let’s imagine our Business User proclaims “We need an app!” This invariably leads to a conversation with the development/design team along the lines of:

Dev/Design: “App? What kind of app?”

Business User: “An iPhone app of course! What else could I possibly mean!?”

Dev/Design: “Maybe…

An iPhone app

An Android app

A Windows Phone 7 app

A Blackberry app

A web app published on the app store/marketplace, i.e Appcelerator or PhoneGap

A mobile version of our current content site

A mobile version for a specific new product offering”

Skip ahead 12 months…a Windows 8 Metro style app

Business User: “Ah…”

As a developer (.NET in particular) we’ve now got a plethora or choices at our disposal for the provision of a mobile offering. The technology and platform choices we make are broader than that for our typical LOB applications. Whilst it’s ultimately down to the client’s time and budgetary constraints, in the mobile world it’s rarely an option for us to target a specific platform.

We need to consider the two ends of the mobile spectrum – given limitless time and budget we’ll write native apps for each platform and excel at providing a compelling experience on each device. Whilst at the other end of the spectrum we’ll provide a modicum of time to prettify our content/services for the most common mobile platform. For now let’s ignore the psychology of an app on the App Store / Marketplace, there has to be a middle ground for those of us that aren’t writing the next Angry Birds but do understand the significance of mobile going forward and therefore want to embrace it.

Given the above I think it’s valuable for us as LOB developers to have a clear understanding of our options for getting the job done when mobile isn’t (currently) our core target. I believe these options lie in the capabilities of CSS3 and HTML5 and when a need for accessing device features such as the camera or accelerometer arise we can extend this through the use of frameworks such as PhoneGap, Appcelerator and to some degree MonoTouch. Having just confirmed the link to PhoneGap for this post I can’t help but feel disappointment at learning of their acquisition by Adobe. Good luck!

If you’re just dipping your toes into the mobile waters I’d also highly recommend looking at what are commonly known as Web Apps. These are typically mobile versions of a current desktop content/service offering but served up in a very mobile centric way through frameworks such as jQuery Mobile. These tend to go beyond that which can be achieved with a mobile skinning of existing content.

I produced this quick and fairly flippant flowchart whilst thinking about this post and figured I’d add it here. Some of these technologies can of course be intermixed in your mobile solution. For example, jQuery Mobile can work quite nicely with the PhoneGap and Appcelerator frameworks.

 

Forget the Spec it’s the revenge of the Shiv

Are you about to embark on a new website (re)design? Do yourself a favour and embrace HTML5.

“But I need to support older browsers and this HTML5 stuff won’t be getting a ratified spec until 2022. That’s no use for me! Damn you IE6!”

This is a common misconception of HTML5 and whilst there are many features that are still experimental, a lot are now fully supported in all of the modern and older browsers.

When it comes to your markup, if you’re still using the div tag for anything other than a styling placeholder you’re doing it wro…in a less than ideal way. HTML5 introduces a significant number of more semantic tags such as <header>, <section>, <article> and <footer> to name a few, but where you’ll run into problems is in styling these tags or even getting them to display within old IE.

Older versions of IE will at best fail to style these elements or worse still simply not display them at all. However, this problem is easily overcome with what’s known as a shiv. Essentially you can add all of the new HTML5 elements to the DOM within older versions of IE simply by calling document.createElement(“insert html5 tag name here”). Older versions of IE will now happily applying your CSS to these tags for which it previously knew nothing. Sure, you need javascript enabled for this to work but we have to draw the line somewhere.

Of course every web developer faces the same challenges with IE and so common libraries for achieving the revenge of the shiv are prolific to say the least. However, if you’re a Microsoft web developer and using ASP.NET MVC 3 with the latest tools update, you already have ALL of this functionality built right into your new projects compliments of the team including the modernizr javascript library. If you haven’t done so already I highly recommend having a read of the modernizr docs. It does far more than help you achieve rounded corners without CSS3 (of course you’ll quickly learn it doesn’t actually do that at all!). If you’re not using ASP.NET MVC no problem, as with all the awesome sauce nowadays you can also get it through NuGet.

BTW apologies for the insanely cheesy title, despite not being an SW fan at all I strangely couldn’t resist.

CRM 4.0 and WCF Data Services

UPDATE: The below post has been sat in my drafts since March 2011. Not sure why I didn’t post it given the title of this site does contain the word musings! Anyway, 6 months on and two projects later I can summarise the Advanced Developer Toolkit as it’s known as follows:

It’s considerably better than Fetch-Xml but still has limitations given that it is essentially talking directly to the Web Services. Make fiddler your best friend and keep a close eye on the queries you’re producing. The expressions the API is building underneath are more than happy to produce pseudo select n+1 and given these are against the web servies this is very bad if you let it get out of control.

Managing the push of entity schema changes made in CRM into the typed entities produced by crmsvcutil can be a pain. However with a suitable build process in place and having setup the deployment of the binary through a corporate NuGet feed I have the deployment workflow setup pretty slick for us now.

The original post I failed to post back in March follows:
I can see a requirement dropping on us in the near future for exposing the contacts in our new CRM 4.0 system to the wider world. The wider world being other divisions within the organisation.

I’m not a CRM expert as we “got a man in” for that bit and one of the other devs on the team picked up the work with him. I am familiar with the plug-in architecture and the WS- based Fetch XML API into CRM having written a replication service from one of our legacy databases.

So, back to the point. We think we’re going to see a need for some querying capability over our CRM data and having had experience of the web services exposed by CRM I immediately decided that pointing the development teams of our other divisions at that API probably wasn’t ideal.

We need options and in this world of LINQ to absolutely everything I decided IQueryable needed to come to my rescue as there must surely be some form of LINQ provider available provided as either open source or better still through Microsoft. A quick Google came up with a project on CodePlex that whilst flagged as deprecated I was pleased to see its reason for deprecation was that Microsoft’s v4.0 of the CRM SDK included a LINQ to CRM Provider. Superb!

Clearing an observableArray in knockoutjs

I recently had the need to remove all items from a multidimensional observable array and discovered that doing this by reinitialising means you need to call ko.applyBindings(…) again. For performance reasons this isn’t something you want to be doing to often. The correct way to do this is call the RemoveAll() method directly on the observableArray itself.

var viewModel = {
    customers: ko.observableArray([]),
    moreprops: ko.observable('whatever');
}

ko.applyBindings(viewModel);

//If we now need to clear down the array (in our case this was to restart a quiz) 
//you do the following
viewModel.customers.removeAll();

//You can now add items back into the array without needing to call applyBindings again.

knockout 1.3.0 shaping up nicely

Although knockout 1.3.0 should be coming out of beta shortly I just wanted to put this post out there to express my delight in having seen the new features.  In particular the containerless control flow (which doesn’t strike me as a particularly intuative feature name) and access to the parent binding contexts.  These features will inevitably result in cleaner markup and hopefully both will result in simpler viewModels in support of list based binding.

However, I’m currently not convinced on the use of the class attribute to declare actions against your observables via jQuery live though.  That doesn’t in my opinion lead to particularly semantic html.  Couldn’t we see an additional data- attribute such as data-action?

More information on 1.3.0 available over on Steven Sanderson’s blog

Managing NuGet at the Visual Studio Solution Level

A particularly useful feature of the NuGet Package Manager extension within Visual Studio 2010 is the ability to manage your packages at the solution level. This can be really useful when you’re creating a new solution containing several projects and you want to share common packages across them all.

With the initial project structure as below let’s say we want to add log4net to both DaxaarInc.BlogSite.Web and DaxaarInc.BlogSite.Data projects.

We can achieve this by selecting Manage NuGet Packages… at the Solution level rather than at the project level.

As you can see below we now get the option to select which projects this package will be installed into. Whichever you choose they will all share the same version of the package held within a shared packages folder. Each project continues to get its own packages.config file so they can diverge on version if you really needed to.

Notice how our packages folder is now stored at the solution level and not at the project level on disk.

Finally, if the existing solution and projects are under TFS Version Control the packages folder is now also added automatically. I’m not sure which release of NuGet this arrived in as I haven’t kicked off a new solution for a few months now but it’s a welcome addition. I’m also unsure if this integration works when you have a different version control provider such as SVN integrated into VS. I’ll maybe give that a try in the near future using AnkhSVN.

 

Hope this proves useful. In an upcoming post I’m going to be looking at the Workflow for creating a new solution structure including setting up in TFS Version Control, Solution structure and creating your own Corporate NuGet Feed for providing an easy install process for your own common libraries.