Delete orphaned branches in TFS 2010

Standard

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?

Advertisements

AppFabric and WAS 1 Windows Service 0

Standard

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

Standard

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.

 

<

p style=”text-align:center;”>

Forget the Spec it’s the revenge of the Shiv

Standard

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.