Friday, March 18, 2011

Visual Studio Setup project is on its last breath!


I was reading Buck Hodges’ blog this morning and came across an interesting piece of information: The age old Visual Studio setup project (vdproj) is coming to an end. After Visual Studio 2010 it will no longer be supported.

Personally I’ve been expecting that something would be happening around the installer experience in Visual Studio for a while now. There was quite a bit of excitement about the inclusion of WiX in VS2010. But alas, this was not to be.

Now don’t get me wrong, I have worked with WiX for a while now and it is immensely powerful. In fact a number of Microsoft’s applications are shipped using a WiX based installer, but there is nothing quite like the Visual Studio setup wizard for creating a quick and easy installer for the small, simple apps. I suppose this is where the “InstallShield 2010 Limited Edition” project support in VS2010 comes from (I must admit though, I have not really taken a good hard look at the InstallShield project yet).

I also need to say that some of the changes in WiX 3.5 (including assembly harvesting) do make it easier to deploy large projects, and you have some free, and commercial, WiX editors (I use WiXEdit) to help out.

It will be interesting to see how the support for WiX grows after the default Visual Studio setup project dies. I would recommend that now is a good time to  start looking closer at the installation technology that you are going to be choosing going forward (Microsoft has put up a nice comparison between the Visual Studio Setup, InstallShield and WiX as a guide).

Wednesday, March 16, 2011

Upgrade Visual SourceSafe today!


If you do not already know Visual SourceSafe’s mainstream support is coming to an end July 2012. This means that if you are still using SourceSafe after this date and you have a serious problem, too bad! (unless you are willing to pay for the extended support.)

So if you have not already though about upgrading, it is probably advisable to start looking at options.

Over the last couple of week I’ve noticed a bigger push from Microsoft to upgrade with pricing specials and more information around migrating to Team Foundation Server 2010 (being the de-facto Microsoft upgrade path).

If you have not yet looked at your options, do take a look at the following resources:

That said, if you happen to be in South Africa and would like more information or advice feel free to give us a shout

Tuesday, March 8, 2011

Visual Studio 2010 SP1 released


Very unceremoniously Microsoft has announced that the Visual Studio 2010 Service Pack 1 will be available today (8th March ) for download for MSDN Subscribers, and will be generally available for download on March 10th, 2011.

This brings with it some very exiting bits (in addition to fixing some very annoying bugs). Some of my personnel favourites include:

  1. IIS Express Support (still need to install it separately though)
  2. Silverlight 4 tools are included
  3. Performance wizard for Silverlight (to profile Silverlight apps)
  4. Unit Testing under .Net 3.5 (previously they all ran under .Net 4)
  5. Initial HTML 5 support

On TFS SP1 most of the changes were focussed to allow the Team Foundation Server 2010 and Project Server Integration Feature Pack, in addition to a fairly large number of bug fixes outlined here by Brian Harry.

Oh and while we’re at it, don't forget about the Team Foundation 2010 Power Tools March 2011 release Smile

Thursday, January 20, 2011

A new year…

Somehow, somewhere we have entered into a new year and 2010 has drawn to a close!

After all the hype and expectation of 2010 I think a lot of people are a bit disappointed and/or let down, especially with the “global financial crisis” and the SA 2010 soccer world cup not delivering all that was promised and expected for the local economy.

For Team Foundation Consulting I must admit, it is has been going a bit better than I expected. It is about 6 months down the line and I was surprised at the interest that we were getting during the end of the year – a period  I though would be pretty dead for a young business like this, and then in January things are also starting to look good.

None-the-less it is now time to bed down how to grow this business in 2011 into a viable operation. And first on my list of things is still to “spread the word” and create awareness. At the moment we are looking at some online advertising options (more on that in another post).

There is also still a lot that needs to be done with regards to standardising past and existing engagements with a bunch of ideas that I have, into formal outlines and marketable “products”. I do find that in some cases it is easier to give people a standard, yet relevant “product” as apposed to asking them to “compose” one that will suit them. This should also enable me to start advertising approximate costs on the site, which should make people more inclined to contact us if they have an idea of what the charges could be.

I’m sure that this will be an interesting year for us, especially with the end of mainstream support for Visual Source Safe in sight and Team Foundation Server being the logical upgrade.

So to everybody that may be reading this, I wish you all the best in the new year!!!

See you around! Smile

Tuesday, November 23, 2010

TFS Security Overview

TFS security can be an interesting beast to work with from an administration point of view.
Not only do you have to manage the permissions assignments in 3 different places (TFS, SharePoint and Reporting Services), but the TFS security model takes on a very layered approach, where different permissions apply on different “levels”.

Most of the groups discussed below are configured and maintained in TFS, so where possible you would probably want to create Active Directory Groups and have these assigned to the correct TFS, SharePoint and Reporting Services groups. This allows you to assign and remove users from a single point (AD) and then this applies across the board.

Additionally TFS rights can be either “Allowed”, “Denied” or “Unset”. Unset means they are neither denied or allowed and means that the inheritance of that right from another group takes precedence. Also note that “Deny” takes precedence in most cases.

If you appear in two groups, one group allowing a feature and in another group that feature is denied, you will have that feature denied. The only exception is if you exist in an administrators group (“Project Administrators”, “Project Collection Administrators” or “Team Foundation Administrator”), the deny is overridden by the rights assignment in the administration group for the associated level.

Administration Console
This level is really assigned to individuals who are responsible for the administration of TFS itself. You cannot assign groups into this role (only users) and assigning this actually modifies rights on the physical aspects such the databases, SharePoint etc.
I would recommend that you limit the amount of users in this group to administrators responsible for TFS maintenance and high level configuration.
TFS Admin Console Assignment

Server Level Permissions
Focussed more at operational aspects of TFS on a server level and not specific to a project collections. These groups can only be modified from within the TFS Administration Console.
The default groups created at this level are:
  • SharePoint Web Application Services
  • Team Foundation Administrators
  • Team Foundation Service Accounts
  • Team Foundation Valid Users
  • Work Item Only View Users
This is where you assign permissions such as being able to create or delete project collections. The “Team Foundation Valid Users” and “Team Foundation Service Accounts” groups cannot be added to directly. The “Valid Users” group is an aggregated list of all the Server Level Permissions as well as the individual Project Collection “Valid Users” groups’ and merely assigns access to the TFS Web portal and viewing instance related information. The “Work Item Only View Users” is a group where you would typically assign project managers or the likes, that is only able to create and manage work items from the web portal, in other words you do not see build information and source code browser etc..
Permissions available on this level include:
  • Administer Warehouse
  • Create team project collection
  • Delete Team project collection
  • Edit instance-level information
  • Make requests on behalf of others
  • Use full Web Access features
  • View instance-level information

Collection Level Permissions
These are specific to the project collection. The reason for having this level is to segregate project collections from each other, providing something of a contained “eco-system” for each project collection. These can be modified from the TFS Administration Console as well as directly through Team Explorer.
The default groups created at this level are:
  • Project Collection Administrators
  • Project Collection Build Administrators
  • Project Collection Build Service Accounts
  • Project Collection Proxy Service Accounts
  • Project Collection Service Accounts
  • Project Collection Test Service Accounts
  • Project Collection Valid Users Collection 
As you can probably deduce from the names – these are still very much administration related groups, but as mentioned previously contained to a project collection.
Permissions available on this level include:
  • Administer shelved changes
  • Administer workspaces
  • Alter trace settings
  • Create a workspace
  • Create new projects
  • Delete team project
  • Edit collection-level information
  • Make requests on behalf of others
  • Manage build resources
  • Manage process template
  • Manage test controllers
  • Manage work item link types
  • Trigger Events
  • Use build resources
  • View build resources
  • View collection-level information
  • View system synchronization information
Project Level Permissions
This level is specific to a project and can only be managed through Team Explorer. This is also where things become interesting… setting permissions on this level, you need to consider the Build, Area’s, Iterations and Version Control, as each exhibits its own set of permissions. So to draw a comprehensive security model on this level you would need to draw together all the required permissions and then allocated the appropriate permissions in each of these functional areas. Once again if you have a large number of teams working on different projects, Active Directory Groups are definitely the way to go.
The number of default groups are small and include merely:
  • Builders
  • Contributors
  • Project Administrators
  • Readers
Areas and Iterations:
To my mind these are ways of grouping work. They are very similar in structure with only the permissions between the two differing. I quite like the description of having Areas denote the “logical, physical, or functional” grouping vs. Iterations that denote the time based grouping.
Right click on the project name in Team Explorer and select “Team Project Settings” then “Areas and Iterations”. This will display the dialog for managing the Areas and Iterations. At the bottom of the dialog next to the “Close” button you will find the “Security” button.
The permissions can be set at each node of the hierarchy and the permissions set at the lower nodes override the inherited permissions.
Permissions include:
  • Create and order child nodes
  • Delete this node
  • Edit this node
  • Edit work items in this node
  • Manage test plans
  • View this node
  • View work items in this node
Note the work item permissions here. This allows you to “group” work items in the project and only allow certain users to “see” certain work items. This comes in handy when you subscribe to having a single project containing a number or individual projects.
  • Create and order child nodes
  • Delete this node
  • Edit this node
  • View this node
These permissions are specific to the build infrastructure that TFS provides. In Team Explorer under the appropriate project right click on the “Build” node and select “Security”.
Permissions available here are:
  • View builds
  • Edit build quality
  • Retain indefinitely
  • Delete builds
  • Manage build qualities
  • Destroy builds
  • Update build information
  • Queue build
  • Manage build queue
  • Stop builds
  • View build definition
  • Edit build definition
  • Delete build definition
  • Override check-in validation by build

Source Control
The version control repository where all files are checked into. Open the source control window by double clicking on “Source Control” node under the appropriate project. You should see the source control layout that looks similar to a folder structure. Right click on any of the “folders” select “Properties”. The dialog that is displayed will have a “Security” tab on. Note that if you have a folder marked as a branch the dialog looks different and the security functionality is under the “Permissions” tab. Similar to the Areas and Iterations the inherited permissions are overwritten.
Permissions available here are:
  • Read
  • Check out
  • Check in
  • Label
  • Lock
  • Revise other user's changes
  • Unlock other user's changes
  • Undo other user's changes
  • Administer labels
  • Manage permissions
  • Check in other user's changes
  • Merge
  • Manage branch

The TFS security model does give you a lot of flexibility, but it is not always that easy to navigate and manage. I have come across very few instances where there was a need to create additional groups within TFS, the default groups that are created are adequate for most deployments. If the need does arise to create custom groups, you should be aware of all the various aspects that it may encompass.

Friday, October 29, 2010

TFS on Windows Azure

Big news if you following Microsoft PDC 2010 is that Mr TFS : Brian Harry did a demo on how they took TFS 2010 and modified it to run on Windows Azure.

This is obviously concerning from a competition point of view if you are hosting TFS, as Microsoft is most likely going to have TFS as an subscription service on Azure.

That aside, it is interesting to see the effort involved in “porting” a large scale application to Windows Azure and the caveats that you have to address to have something running successfully.

On the plus side they made some improvements to TFS itself, which makes more sense for it to run “in the cloud”. One of the major changes in my mind is that fact that they changed the Build Controller to have a client as opposed to a peer relationship.

I always hated the cyclical relationship between TFS and the Build Controllers. Working in distributed teams it was a mission setting up continuous integration and then with limited access to the TFS Build servers, we would either have to commute to the office to fix a build issue or, what tended to happen more often, you live with a broken build for a couple of weeks until someone went in to the office that could fix it.

I really hope that we will see these changes becoming available in the mainstream application.

Monday, October 25, 2010

Is competition bad?


Being a very young, niche service provider in South Africa, I’m very concerned about competition. I heard about a fairly well known American company doing TFS and Visual Studio consulting and training, busy establishing a presence in South Africa: you know that sinking sensation that a person gets?!

Not long after this I was speaking to Paul Hacker who hosts TFS, and noticed that there was yet another company that has just started hosting TFS in the States. I forwarded him the details and we got to chatting around the subject of competition.

Between our discussion and reflecting on my actions after I heard about the competition coming into this country, I have concluded that:

Competition is not always that bad.

Sure it gives you less of a market and it means that you need to start working even harder for business, but primarily I think you should take a step back and re-evaluate yourself, your market proposition and your target market.

You could decide to redesign your offering to be more applicable, or have a more focussed approach to your existing market, or even address those tasks that you had on your backlog that suddenly becomes top priority because your competitor is doing it..

Either way you would need to streamline your business and have a more focussed vision, ensuring an environment where the “customer wins” .

Another option is to consider an alliance or partnership of sorts. One of my friends who runs his own successful business told me that “A competitor is not always a competitor”. You could leverage each other and learn from each other to enhance your own portfolio and strengthen your own brand.

Even though I’m still very wary of competition, that sinking feeling has subsided. I have redesigned my offerings, focussing on, and better structuring areas that were a bit neglected. All in all I think creating a more holistic offering.

BTW: I actually met and had a chat with the president of “the competition” and it turns out he is not such a bad person after all Winking smile