Wednesday 12 November, 2008 (.Net | BizTalk | Ramblings | Team System | Tech Ed 2008 | Visual Studio)
This is my third day at Tech Ed 2008 in Barcelona, the breadth of the technologies and languages that we as .Net developers now need to at least understand and preferably master to some degree is enormous. I believe that developers will need to specialize more explicitly on certain technology areas to remain productive in the future. It has been impossible to master all of Microsoft's products for many years now but up until a year or so ago it was at least conceivable for a developer to master all of the developer technologies that Microsoft had on offer. With the introduction of cloud based services and all the news in .Net, both libraries and new languages I cannot see how any one person will be able to master it all... I want to sum of some of my thoughts on the sessions that I have attended here at Tech Ed on Visual Studio 2010.
Fixing Continuous Integration
CI is a great principle and has moved into the mainstream along with many other agile principles. While Continuous Integration as such has never been broken there has always been a problem with developer discipline. If you check in something that is broken then it will be discovered quickly with CI but if you don't fix the broken code other developers will be less productive if they cannot get the latest code or have their own checkins fail in CI due to previously broken builds. With Visual Studio Team System 2010 Microsoft is introducing a new concept for CI, the gated check. It is not a big change to the CI flow but a very clever use of a shelving, a feature in TFS which I find generally is underutilized. Instead of doing a standard checking in and then running a build on that code, gated checkins shelve the developers changes and then performs a build on the shelveset. If this build is successful then the shelveset is promoted to a proper check in, if the build fails then the check in is not committed to the mainline. The visibility that CI offers is maintained but using gated checkins other developers will never get failing code from other developers which was discoverable! Obviously undiscovered errors can still sneak into the code due to bad or missing tests or incorrect configuration of the build environment but it I believe that this will lower or eliminate the fear of checking in that some developers have. It will also allow you to check in before you go home without the need to wait and see that the CI build completes successfully. If I check in my code 5 minutes before I go home I should ideally wait to see that the build is successful, if it does not then I need to fix that immediately since other developers will be getting that code tomorrow morning when they come in. Using a gated check in I can go home, let the CI build complete on my shelved changes and if the build is successful then everyone can get my changes in the morning, if it fails I can safely wait until the morning before fixing the code and no one else is impacted by my errors.
Reproduction of Errors and Architecture Compilation Failures
Visual Studio 2010 looks like it contains some pretty good testing tools like the ability to record a testers GUI while performing manual tests and also including debugging and tracing info from remote machines. Pretty powerful stuff! It seems Microsoft have their mind set on eliminating the problem of irreproducible errors.
Another interesting feature is the architecture layer diagram which allows you to specify how the different layers in your application may and may not call each other. This is useful for validating that your code follows the intended architecture at compile time instead of detecting it when problems arise. All of these features (and there are more) are great but unfortunately Microsoft still has silly distinctions between different editions of Visual Studio Team System, so many of the cool demo features will probably be marginalized in most organisations due to them not actually having the appropriate edition of Visual Studio.
Thursday 30 October, 2008 (dasBlog | Fixes | Reviews | Team System | Visual Studio | Web)
I have been messing about with some template experiments in dasBlog using Notepad++ and Visual Studio 2008. That is changing the site layout by editing homeTemplate.blogtemplate, dayTemplate.blogtemplate and itemTemplate.blogtemplate for a dasBlog Theme. These files are basically html files with dasBlog specific macros for inserting the blog functionality.
Notepad++
First off I love Notepad++ as a replacement for Notepad. I have had a hard time doing more complex things in Notepad++ due to my addiction to Microsoft's intellisense... Editing the .blogtemplate files is dead simple in Notepad++ since it is very easy to get syntax coloring - you simply choose a language (html) from the language menu and viola everything is color coded. The file that you are editing doesn't need to have the correct extension or even be written in the language you choose. Notepad++ does its best and highlights whatever it can recognize.
There is also an auto completion function that you access by pressing CTRL+space, but this function is really only a text completion function and does not take any notice of the context that you are typing in. It just pops up an alphabetical list of potential text candidates based on the letters that you have already typed. For simple programming tasks this is more than adequate and Notepad++ does have a significantly smaller footprint than Visual Studio, so you can install it on pretty much any computer or server without anyone complaining for quick debugging tasks.
What I really have been missing is proper html intellisense for the .blogtemplate files.
Visual Studio 2008
Obviously Visual Studio does not have support for the .blogtemplate extension. For awhile I hacked my way around it by renaming the files to have a html extension while editing, which sort of works. The main problem is that I keep forgetting to change the extension back before I start testing my changes - so this was causing unnecessary pain... I had a vague memory of configuring something like this before and found these instructions. For the sake of completeness I include them here also:
1. Go to the Tools->Options menu.
2. Pick Text Editor -> File Extension from the tree in the left part of the Options dialog.
3. Type your file extension, .blogtemplate in my case, in the Extension text box.
4. Select the appropriate editor from the Editor dropdown.
5. Click Add and then Ok to close the dialog and re-open your files.
If you cannot see the Text Editor node in the tree view of the Options dialog then you probably need to click on Show all settings in the bottom left hand corner of the dialog...
Using this feature you can set up pretty much any color coding and intellisense support that you like in Visual Studio for file types that Visual Studio lacks support for. All I am missing now is auto completion for dasBlog macros in .blogtemplate files, this seems like a much tougher problem.
Thursday 26 June, 2008 (.Net | Bugs | Fixes | Team System)
We have just had a major Active Directory issue that has affected the Team Foundation Server instance that all the developers at the client that I am working at use. The problem occured when some users where erased in the Active Directory and were subsequently recreated with the same user names. These new user accounts cannot access the Team Foundation Server.
A large part of the problem was solved by just removing users from TFS and then putting them back in again. This recreates all the wiring under the surface in TFS so that the users can access the server but all their existing workspace info, pending checkins and so on are lost locally yet exist in Team Foundation Server with a different Owner under the same user name... The only way to tell them apart is by their SID and that the original account may get suffixed with a number in workspace lists: AD\username:61.
My first thought was to remove all the workspaces and pending checkins and let people manually resynch their projects. When I clicked undo pending change for a bunch of changes in Attrice Sidekicks an unhandled exception popped up: "Object reference not set to an instance of an object". I just can't undo these changes, there is a clue to the problem when I try to unlock a changed file, I get an Unlock error:
Failed to unlock $/Project/Path/file (TF14061: The workspace COMPUTERNAME; AD\username does not exist.)
I can't search for workspaces by username either, even doing a simple TFSSecurtiy /i "ad\username" /server:TFSName for one of the affected accounts returns "Error: The identity cannot be resolved." Since the original accounts have been removed from Active Directory I cannot easily get hold of their SIDs for querying with TFSSecurity. Attempting to delete the workspaces from the command line return the following error:
TF14061: The workspace WORKSPACENAME;AD\username does not exist.
Things seemed pretty messed up... I found some clues as to what was required to get things working again:
http://support.microsoft.com/kb/948679
http://support.microsoft.com/kb/823278
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=454060&SiteID=1
According to the KnowledgeBase articles trying to create a new project while TFS is in this state may result in the following error:
TF30170: the plugin Microsoft.ProjectCreationWizard.WorkItemTracking Failed during task WITS from group WorkItemTracking
Basically Team Foundation Server has a bug that causes deleted accounts to not be resynched correctly and SharePoint doesn't handle recreated user accounts at all - you have to resynch them manually. Unfortunately in addition to this there is a bug in TFS SP1 which prevents TfsAdminUtilI from correcting the SIDS! You get the following error:
ERROR: Could not access database.
In the end I managed to correct all the problems, here are the steps required:
- Contact Microsoft Support and request the hotfix for http://support.microsoft.com/kb/934216
- Install the hotfix...
- Follow the steps in http://support.microsoft.com/kb/948679 to resynch the users SIDs in TFS
- Follow the steps in http://support.microsoft.com/kb/823278 to resynch the users in SharePoint
- Recycle the TFS App Pool to force an update of all users and groups in TFS.
Look out with users who have their workspaces mapped to "c:\documents and settings\" the new user accounts cannot necessarily access their old files there since they now log on with a new account (which just happens to have the same name).
Tuesday 09 January, 2007 (.Net | Team System)
Download the sample code.
I have tried different methods to move work items from one Team Foundation Server to another. The easiest method is doing it with Excel, but the problem is that I also want to keep all the work item history which Excel cannot do.
I found that the Revision property of each work item contains an array of complete copies of the work item as it appears at each revision. So iterating over each revision in order allows us to recreate each version that was saved! By setting the system time to the time of the original revision we can recreate a work item including all its changes, provided that we execute the code on our server so that the date changes are reflected when the work items are saved. An added bonus of iterating over each revision and saving them is that all the state changes are legal so we don't need to figure out how to get our work item to it's final state if we have complicated state transition rules.
If we execute our updates as a different user than the one that made the changes originally then each history entry will be tagged as "Edited by XXX on behalf of YYY". Unfortunately it appears that project reports are not updated with the historic data, all the new work items will be added to the reports the day that you import them.
The following code illustrated how I have copied almost all of the basic data from work items using revisions (unfortunately indentation was lost when I copy/pasted the code):
foreach (Revision r in wi.Revisions)
{
foreach(Field f in r.Fields)
{
if(f.ReferenceName == CoreFieldReferenceNames.ChangedDate)
{
System.Diagnostics.Debug.WriteLine(f.Name + " : "+ f.Value);
//Copy revision date
System.DateTime revDateTime = (System.DateTime)f.Value;
revSysTime.wDay = Convert.ToUInt16(revDateTime.Day);
revSysTime.wHour = Convert.ToUInt16(revDateTime.Hour);
revSysTime.wMilliseconds = Convert.ToUInt16(revDateTime.Millisecond)
revSysTime.wMinute = Convert.ToUInt16(revDateTime.Minute);
revSysTime.wMonth = Convert.ToUInt16(revDateTime.Month);
revSysTime.wSecond = Convert.ToUInt16(revDateTime.Second);
revSysTime.wYear = Convert.ToUInt16(revDateTime.Year);
}
if(f.ReferenceName != CoreFieldReferenceNames.History
&& f.ReferenceName != CoreFieldReferenceNames.WorkItemType
&& f.ReferenceName != CoreFieldReferenceNames.TeamProject
&& f.ReferenceName != CoreFieldReferenceNames.Id
&& f.ReferenceName != CoreFieldReferenceNames.IterationId
&& f.ReferenceName != CoreFieldReferenceNames.IterationPath
&& f.ReferenceName != CoreFieldReferenceNames.AreaId
&& f.ReferenceName != CoreFieldReferenceNames.AreaPath
&& f.ReferenceName != CoreFieldReferenceNames.CreatedBy
)
{
if(!f.IsComputed && f.IsValid)
{
destItem.Fields[f.Name].Value = f.Value;
}
}
}
System.Collections.ArrayList arrl = destItem.Validate();
if(arrl.Count > 0)
{
//Handle validation errors
}
else
{
GetSystemTime(ref currentSysTime);
SysTimeNeedsReset = true;
if(SetSystemTime(ref revSysTime) == 0)
{
throw new ApplicationException("SystemTime was not set!");
}
destItem.Save();
if(SetSystemTime(ref currentSysTime) == 0)
{
throw new ApplicationException("SystemTime was not reset!");
}
SysTimeNeedsReset = false;
}
}
You can download the code to the minimal WinForms app that I have created for copying work items here. The code is provided as-is with no guarantees or support...
Things that are not handled at all are: user mappings if the source and destination server have different users, area and iterations, links and attachments. There may be more things that are missing or don't work that haven't affected my setup.
Tuesday 09 January, 2007 (Team System | Tips)
I have had several discussions with people I work with about where to put your documents when using Team Foundation Server. Obviously there are several places to put documentation depending on what sort of document it is. There are at least three places that make sense to me:
- In the SharePoint Portal
- In the Version Control repository
- As attachments on Work Items
Each of these places has their advantages and disadvantages. I have found two interesting blog posts on one by Jason Barile and one by Jeff Atwood. For me I only use Work Item attachments for documents that have no project-historic value and only cover a single work item. Screen shots for bugs is a classic example. Anything that is scoped to more than a single work item or might be of value for new project members as background material or details of why the system has been built the way it is must be stored somewhere more visible.
The Version Control repository is great for code, but for me I really don't want to see documentation in there for two reasons. All project members might not have Team Explorer installed. That means that anything that is placed under source control is effectively hidden to project members who don't work in Visual Studio. In addition the documents might not be fully visible to project members who do use Visual Studio since generally we map up our Solutions and projects and get the latest version through the IDE integration in the Solution Explorer not by using the Source Control Explorer. So if someone creates a new folder in Source Control that is not part of one of the projects that I am working on then I generally won't see it straight away. The SharePoint Portal has two advantages visibility and accessibility. All the documents are clearly visible in one place (Documents and Lists) and in addition we are not restricted to documents we can also use lists and WebParts to display additional data like reports and external links to help project members understand whats going on in addition to just getting hold of the right documents. Users who want to find information aren't required to have Visual Studio installed and configured they only need a browser to get hold of the documents.
- Use the SharePoint Portal for info that needs high visibility.
- Use the Version Control repository for code.
- Use Work Item attachments for documents that only relate to a single work item.
Thursday 23 November, 2006 (Bugs | Team System)
I have been attempting to run a Team Foundation build server on a separate machine outside our domain. Install and connectivity between the servers was no problem but once we got the build configuration up and tried to perform a build from Team Explorer we got an error:
TF42056: The build service could not connect to the Team Foundation Server: TF30063: You are not authorized to access https://myserver.
I tried all our standard solutions:
- Set https://myserver as local intranet in Internet Explorer security settings.
- Stored username and password in the control panel applet.
- Cached username and password in Team Explorer
The IDE works perfectly but nothing works when we run Team Build, it turns out that this is an unsupported configuration due to the Team Build service not picking up locally configured alternate credentials. It's a known issue in v1 for some of the command line tools. So far there doesn't seem to be a workaround that could fix this, perhaps SP1 will add alternate credential support for all the command line tools.
These MSDN forum threads didn't really help us but might help others with non-domain related issues:
https://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=380144&SiteID=1
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=20644&SiteID=1
UPDATE:
I continued searching for info on this and found http://msdn2.microsoft.com/en-US/library/ms400712(VS.80).aspx#:
The Team Foundation client is in a workgroup instead of a domain, but Team Foundation Server is deployed in a domain. Local user accounts must be created on the Team Foundation client computers. If you do not want to require users to type a user name and password every time that a Team Foundation client must connect to Team Foundation Server, make sure that the local user accounts use the same user name and password as the domain user names. For more information, see Managing Team Foundation Server in a Workgroup.
I couldn't get a local workgroup account set up so that it mapped to a domain account but I attempted a completely local configuration which did work even though my Team Foundation Server is set up in a domain:
- Create a local build user account (tfsbuilder) on the Team Foundation server.
- Add the tfsbuilder account to the Build Service TFS group for your project, this has to be done through Team Explorer on the TFS server since clients can't add local accounts to the TFS server.
- Create a local build user account (tfsbuilder) on the build server.
- Give the tfsbuilder account all required permissions. I'm not sure which they are but I added the user to the Power User group and this works.
- Change the logon account for the Team Build Service to you local tfsbuilder account also giving the user log on as service permission.
- Restart the team Build Service.
- Kick off a build from your client and things should work smoothly!
The same solution should work for all command line tools using the "run as" start method.
Friday 17 November, 2006 (SharePoint | Team System)
I am looking at the steps necessary to move projects between two Team Foundation Servers where both servers have existing projects setup. The lack of information on how to do this on the Internet and forums indicates that this is not something that is easy to accomplish. We have selected the server which we have customized as the target machine and luckily the other server has a default installation of TFS on it so we don’t need to synchronize any of our own customizations.
I found a post on the Team Foundation Server forums which basically says MS will be looking at this but that there is no existing solution.
I also found a listserver mail archive which indicated that source control and work item history may be lost in the transfer.
At the moment I have a couple of working theories depending on what is possible through the extensibility API available at the VSIP site.
The simplest solution
- Manually create the Team Project
- Upload all the documents to SharePoint manually
- Use Work Item Utility, Mark Browns code for work item shallow copy or Excel to copy work items.
- Get the latest version of items in source control, unbind from the server and then check into the new server and rebind.
A complex solution
- Manually create the Team Projects
- Upload all the documents to SharePoint manually
- Adapt Work Item Utility (http://www.gotdotnet.com/codegallery/codegallery.aspx?id=b29d4456-c4ba-474e-a422-0479471776e1) to copy the history of all items if it is possible.
- Develop a tool (or find one on the internet) that gets every version of all the files in source control and checks them in with their original dates to the new server.
The second solution is better because we would like to keep all the history but I have a feeling that it may be difficult, maybe even impossible to keep history. Buck Hodges has posted a source control API sample and I believe that this could be modified to get existing code history and check it in to a different server. For the history to be persisted in the new server the CreationDate of the PendingChange objects that are checked in would need to be modified and the server would have to trust the date in the pending change from the client over its own date (unlikely). The super complex solution is to run the tools on the server and modify them so that the server’s date and time is changed between each check in to get them to occur at the right point in time! Probably a lot of work...
Wednesday 15 November, 2006 (SharePoint | Team System | Reviews)
I got a question from one of my many readers 
wondering why I didn't think that TeamPlain was right for me. Since this is a topic that I was planning on writing about I put together a list of my gripes! Unfortunately I haven't had time to try out Teamprise yet which is a related technology, but if I ever get around to it I will definitely write about it here too.
Don't get me wrong I think that TeamPlain is a great piece of software, I would really like to be able to use it but I have some issues with it. I work as a consultant on smallish custom development projects (2-10 developers) for clients who are usually not that technically savvy. Projects normally range from a couple of weeks to a year or so (although some are a lot longer). We also work quite a lot off-site and on multiple projects in parallel, so having a web and web service based interface to Team Foundation Server is great for us. Best of all most of the features that we as developers need is built into the product more or less out of the box. The value that TeamPlain could offer us is giving our clients, project managers and general executive types easy access to more parts of TFS than they get through SharePoint.
Problems that I see with TeamPlain for us
- When opening documents via TeamPlain they are not opened via SharePoint and cannot be updated to the SharePoint document library. SharePoint is web based also so we could just have connected to the SharePoint site instead.
- Reports can be accessed via SharePoint just as well as with TeamPlain, ok you don't get the nice looking drop-downs with a list of reports. On the other hand the reports are web based so users can connect to the report server instead.
- The integration with Source Control is read-only so it is only useful for non-developer access to source control. We don't want non-development artifacts stored in source control; they should be stored on the SharePoint site or in the wiki, so we have no use of this feature.
- There is no SharePoint integration, so you have to choose if you go in through SharePoint or the TeamPlain entry point. Since we also have a wiki this means we actually have to choose between three entries instead of having one big Project Dashbord with the status of the entire project and quick access to all areas. We have implemented a quick fix for our wiki by putting it inside a WebPart on the SharePoint site, we could do the same with TeamPlain but I don’t believe that this is optimal.
- There is no API for interacting with or modify TeamPlain nor is it possible to use parts of the TeamPlain GUI in other Web Apps or from within SharePoint. The license explicitly prohibits users from modifying TeamPlain.
Features that would make me look at TeamPlain again
- SharePoint integration so I could give users access to the features in TeamPlain that I want through WebParts. Then each Project could customize their views depending on their specific needs.
- Floating user licensing for the lite edition since we only really need the work item editing capabilities for our clients at the moment.
- Some form of feature customization or extensibility, partly just for the sake of it (I am a developer after all) but also because I believe that customizable products will always be more useful.
Wednesday 15 November, 2006 (.Net | SharePoint | Team System)
Unfortunately it will not be possible to upgrade Team Foundation Server to Windows SharePoint Services 3 when it is released, see Jason Bariles blog for more info. This feature will not be added in the upcoming Service Pack (SP1) either. So for the time being we will all just have to make do with WSS 2 features and add any additional functionality that we need through TFS extensibility and custom SharePoint features. 
Thursday 09 November, 2006 (SharePoint | TechEd 2006 | Team System | Scrum | FlexWiki)
I have been working with Visual Studio Team System since the public Beta came out so the possibility of customizing, reconfiguring and extending Team System was not new for me. Unfortunately I am slightly disappointed with the content of this White Board Discussion since I have been looking forward to hearing how others are implementing Team System, I was expecting more information and tips on actually getting management buy-in and best practices for process adoption. We are in the middle of rolling out Team System for our Microsoft development projects so I know that the real value of Team System can only really be realized when you customize your setup. But at the same time it was good to hear that the work that we are doing thinking about how to customize Team System and our Team Foundation Server setup is what others also are thinking about.
Right now the state of our setup is the following:
- Team Foundation Server setup with SSL over multiple dns names. This was no trivial task since there was no official documentation for setting up TFS with SSL when we did this. Now there is a step-by-step guide on MSDN http://msdn2.microsoft.com/en-gb/library/ms242875.aspx. Additionaly you need to “hack” your IIS and TFS configuration if you want it to work. Perhaps I will get back to this in a future post.
- ScrumForTeamSystem (http://www.scrumforteamsystem.com/). Since we have a couple of projects that use Scrum it made sense to have a process template that supports Scrum.
- TeamPlain Web Access (http://www.teamplain.com/). We are still evaluating this and although it works quite well, I am not sure that it is right for our use.
- FlexWiki (http://www.flexwiki.com/). I have come to love Wikis for simplifying and reducing the friction to start writing documentation of our systems. We have integrated FlexWiki into our SharePoint portal sites by simply adding a Page Viewer WebPart with a large height.
- SharePoint hotfix 915746 (http://support.microsoft.com/kb/915746). Without this hotfix you cannot add new Web Parts to you portal sites.
New features that we are looking at implementing:
- Custom Process Templates and work items. We have a project on our Team Foundation Server for Team Foundation Server customization (almost a meta project).
- Implementing some ideas from Trac (http://trac.edgewall.org/). Mainly a changelog WebPart for aggregating a change history for our WorkItems, source code, portal documents, Wiki pages. This could probably be implemented as an RSS aggregator.
- One-stop dashboard in Sharepoint for a quick overview of the state of everything in our project.
- RSS feed for changes to make it easier for developers to participate in different parallel projects.
Technorati tags: TechEd-Developers
Page 1 of 1 in the TeamSystem category
Disclaimer
The opinions expressed herein are my own personal opinions and do not represent
my employer's view in any way.
Sign In