Old news...but very cool if you didnt already know....Team Foundation Server Power Tools v1.2 was released.

The Microsoft Visual Studio 2005 Team Foundation Server Power Tool (formerly known as Power Toys) is a set of enhancements, tools and command-line utilities that improve the Team Foundation Server user experience. This release includes two new command-line tools for the developer and three non-command line tools: a process template editor, a set of custom check-in policies, and a test tools build task:

• Team Foundation Server Power Tool Commands (tfpt.exe) - A command-line tool with enhanced functionality for Team Foundation Version Control with graphical user interfaces for some commands.
• Process Template Editor - A tool integrated with Visual Studio for authoring custom work item types and some of the associated process template components.
• Check-In Policy Pack - A set of handy check-in policies to address needs customers have expressed.
• Test Tools Build Task - A tool that allows running unit tests by simply specifying the DLLs, or by specifying a file name pattern in TfsBuild.proj, instead of using .vsmdi files to specify tests to run.

I was a little bummed that the check-in policy pack didn't have any of the policies which I had requested (laughs)(especially since I posted on sending all of your comments). With that aside I couldnt have been happier with this release of the Process Template Editor. The integration with visual studio, the form control, and the validations were a great upgrade in this release. Note: You must first install the Domain-Specific Language Tools for Visual Studio 2005 in order for the Process Template Editor to appear in the Team Menu.

Here are a few screenshots of some of the process template editor features:

Screen - Editing the Process Template

Screen - Editing a work item type

Screen - Previewing the work item control

Screen - Work Item workflow

In the end, I couldn't be happier because this release came at the perfect time for me. I am steadily working on my Master's Project and alot my project will require me to customize the MSF for Agile process template, work items, and reports. Currently, my tentative title is "Customizing Team Foundation Server Process Templates for Software Quality Improvements". I know its quite a mouthfull, but I figured it would be a great way to learn the ins-and-outs of TFS and how to apply some of my MSE Master's knowledge to Microsoft's latest and greatest.

I found yet another post at the Vertigo Team System blog which once again warns of the dangers of using the vs2005 website approach rather than the Web Application Projects. I do feel like I've been beating a dead horse about this, but I thought this was worth mentioning because it made its recommendations specifically from the Team System point of view. The author listed a reason, which I had never thought of, to choose the WAP over the Website:

it's impossible to check in code analysis rules on Web Site projects, because the code analysis rules are stored entirely on the client!

Overall, I just can't wait for the VS2005 SP1 to come out so that we can put all of this nonsense behind us and avoid having to sell the idea of using a project add-in rather than the VS2005 standard approach. What a mess this all was.

I've spent some time in the last couple of months getting cozy again with DotNetNuke (I've been working very slowly on a side project for a few months now). I used to work with DNN back in the 3.0 days but it has been almost a year now so when I downloaded the latest version, and fired up VS2005 I was overwhelmingly dissapointed with the fact that DNN 4 (ASP.NET 2.0) version uses the VS2005 website model as appossed to the VS2005 Web Application Project model. After searching around for a Web Application Version I came across this post by Shaun Walker (Mr. DotNetNuke) stating the following:

So if we now shift our focus to the DotNetNuke web application framework, even though we identified some serious deficiencies in ASP.NET 2.0, we were still able to release DotNetNuke 4.0 on November 7, 2005 with full support for VS2005. In addition we were able to provide backward compatibility for modules created in VS2003/ASP.NET 1.1 ( from a RUN-TIME perspective ). We did this by reorganizing our project structure to conform to the VS2005 Web Project model. This involved a lot of time and effort but it also paid dividends by providing a number of new project benefits including support for the new Express development tools and support for some new RAD development concepts. However, one thing which we were not able to provide ( due to the limitations in VS2005 ) was a simple method for migrating the development environment for a DotNetNuke Module which was developed as a VS2003 web project and built/deployed as a private assembly.

The lack of a decent migration strategy for early adopters of the DotNetNuke web application framework has created some confusion and frustration within the community. Although we were able to provide detailed tutorials and samples on how to create modules in DNN4, there is no simple method to convert an existing DNN3 module to DNN4. Luckily, developers have understood that the limitation is mainly related to the changes which Microsoft made in VS2005, an issue which is largely out of our hands. However with the recent announcements by Microsoft regarding the availability of the Web Application Projects, there is a large group of developers who think that their migration problems have been solved. Unfortunately, these conclusions are based more on marketing propaganda rather than fact.

Recently, we have spent some time analyzing the Web Application Project model to determine its potential benefit to DotNetNuke. Almost immediately we ran into some serious technical challenges which we had not anticipated. It turns out that from a development perspective the two web project models are incompatible with one another. This means that within the same web project, you can only use one model or the other - not both. On the surface this may not seem like a big a deal but from a product development perspective, it certainly has an impact on the ways in which your developer audience will be able to use your application. Before we dig into the technical details, let's consider the high level business cases of the two project models:

1. Web Site Projects ( WSP ) - supported out-of-the-box in VS2005. Can be leveraged by ALL product SKUs from Express to Enterprise. Provides RAD development and deployment.

2. Web Application Projects ( WAP ) - supported as a separate download from the Microsoft site ( will be included as a fully supported model in VS2005 SP1 *official release date unspecified* ). Can only be leveraged in higher level SKUs - Standard Edition and above ( no support for Express Editions ).

As you can see, the developer tool support aspect of Web Application Projects is sorely lacking. This is unfortunate as the changes made in DotNetNuke 4.0 to support the Express tools resulted in a massive benefit to our community. It completely eliminated the barrier of entry for developers by providing a rich set of development tools at absolutely no cost. And the Web Site Project model used in DotNetNuke 4.0 provides a RAD development environment which satisfies the needs for 90% of the developer community. For the other 10%, a free development environment is not a critical requirement; therefore, the Web Application Project model is a viable alternative. So why can't we have one DotNetNuke code base which supports both Web Site Projects and Web Application Projects simutaneously - providing the maximum flexibility and benefit to all stakeholders? Here is where we dive into the technical details...

1. WSP uses the app_code folder for dynamic compilation. If you switch a project to use WAP and do not remove the app_code folder, you will get "double" compilation - as ASP.NET 2.0 will automatically compile anything in app_code whether there is a WAP project file present or not. So basically you will end up with assemblies that have namespace clashes in the /bin.

2. All user interface files ( ie. *.aspx, *.ascx ) have a different syntax in WAP than they do in WSP. WAP projects use the old "CodeBehind=" attribute and must have an associated *.designer file for each user interface file. WSP projects use the new code-beside model which does not require "CodeBehind=". You can not have a mixture of these 2 types within the same development solution. In order to support WAP for the DNN core, we would need to convert every user interface file to use the WAP syntax - producing a completely different code base ( one that no longer supports WSP ).

3. WAP has different settings in web.config than WSP, since they use totally different compilation models.

As a result of the technical issues noted above, we can not have a single DotNetNuke code base which supports both we project models. And since we feel that the Web Site Projects satisfy the needs of the majority of the developer community,

WE WILL NOT CONVERT DOTNETNUKE TO A WEB APPLICATION PROJECT

The first thing that I would like to say is that I understand that this is in now way an issue which DotNetNuke has created. This is a simple product of a new shift towards a lesser solution.

Without losing all hope, I kept searching around on Google (after all this was posted last May of this year '06). I found a great article @ haacked.com describing how he created a C# Web Application from scratch and reconstructed a solution to run DNN in the new Project format. In addition, a zip download was provided so that you could could get a jump start on all of his hard work.

Im not quite sure how I feel about moving away from the standard DNN download. Ill probably stick to the stupid website model, just because upgrades will be much easier, but I think its great that someone has actually "fixed" this problem that the new VS2005 website model started.

If any reader has any additional info regarding this subject, your comments would be greatly appreciated.

Just a reminder of a few up-and-coming webcasts.

Visual Studio Team Foundation Server HOW TO: Plan for, Install, and Configure

Thursday, November 16, 2006 2:00 PM Central Time (US & Canada)

Visual Studio 2005 and MSDN - a procurement perspective

Thursday, October 26, 2006 2:00 PM Eastern Time (US & Canada)

Momentum Webcast: Best Practices for Source Code Management with Visual Studio 2005 Team Foundation Server (Level 100)

Thursday, November 30, 2006 11:00 AM Pacific Time (US & Canada)

MSDN Webcast: Introduction to Microsoft Visual Studio 2005 Team Edition for Database (Level 200)

Monday, November 20, 2006 10:00 AM Pacific Time (US & Canada)

Visual Studio Team System Demo

Thursday, November 02, 2006 2:00 PM Central Time (US & Canada)

Visual Studio Team System Demo

Thursday, November 30, 2006 2:00 PM Central Time (US & Canada)

October 24th and 25th 2006 will go down as the most annoying days that I have had (for the better part of my software development life). Anyone who has seen this CS0433 error after converting a VS2005 website to a Web Application Project will feel my pain.

Here are the following events which had occurred:

1. A VS2005 website was created and a small number of pages, controls, sitemaps, etc were added.
2. A decision in the department was made to use the VS2005 Web Application Project for .Net 2.0 websites.
3. Our group downloaded and installed the WAP Add-In (Download Here)
4. I removed all of the VSS bindings (we are still waiting to receive our full Team Foundation Server edition)
5. I followed steps to Upgrade a VS2005 Web Site Project to VS2005 Web Application Project tutorial.
6. Everything went smoothly except that it was kind of a pain to add the namespaces to all of the source files. Nonetheless, I was happy because I was out of the horrific WebSite method of developing web applications. The application built correctly and I added to a separate project in VSS.

Everything seemed to be going great until I fired up the debugger and ran my application.

This is the error which I would stare in the face for the next 8 hours

Compilation Error

Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.
Compiler Error Message: CS0433: The type 'AgencyPro.UserControl_NavTree' exists in both 'c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\3f88d5c8\5840425e\assembly\dl3\e396fa14\0b806043_51f8c601\AgencyPro.DLL' and 'c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\3f88d5c8\5840425e\App_Web_navtree.ascx.78d7338a.aftov38w.dll'

Better yet here is the actual screen so that you can have the image burned into your mind.

I did a search on Google and it turned out that tons of people had faced this similar issue. However, I was completely unable to find anything which directly gave me a fix.

Initially I thought this issue was caused for several different reasons.

1. Maybe I needed to add the default namespace to all of the files in the project? - I did this and the issue continued.
2. Maybe it was because I had the reserved directory App_Code in the project? - I removed this and the problem was still there.
3. Maybe I needed to create an entire new project and add all of the files to that again? - I did this and the issue continued.

The obvious answer was that this error was being caused by the new ASP.NET compilation methods where a dll is generated for each of the pages (so lame in my opinion), but it was all a matter of trying to figure out how to override this behavior. After searching around in the web.config documentation, I felt stumped and due to the difficulty with generating a search phase which would turn up any real answers I was lacking documentation.

At this point I was getting a little desperate and frustrated but I knew that if I created the project from scratch and added all of the files from scratch as well, then this issue would go away. In fact, the only solutions that I had found for this issue had been describing doing just this. So, I gave up, and rebuilt everything from scratch (meaning copying and pasting all of the code into brand new files) but I still had to know what the fix was.

A buddy of mine @ work (Bruce Hoang) came over to my desk and told me to check out this article at DevX. Yes! All of my questions were answered.

Solution:

1. Remove the App_Code directory from the project.
2. Change the CodeFile attribute to CodeBehind on your .aspx, .ascx, .master, etc. pages.

Main Cause

1. I followed all of the recommended steps in the VS Web Site to VS WAP conversion but now in hindsite I think that the issue was caused by the fact that my files were still ReadOnly from VSS. Therefore when I ran the conversion, it was not able to change the CodeFile attribute to the CodeBehind  attribute on all of the pages.

Above -  The Attribute that stole my time!

For an in depth article on ASP.NET 2.0 compilation and deployment issues I would recommend this as a must read.

"Changes are not allowed while code is running or if the option 'Break all processes when one process breaks' is disabled. The option can be enabled in Tools, Options, Debugging."

If you're like me and you've had to work with a number of different installs of VS2005 then you have probably seen prompt before. You tend to see this annoying pop-up message while you're in debugger mode and you try and modify any of the source files. All that you will need to do is to uncheck the "Enable Edit and Continue" option in Tools > Options > Debugging > Edit and Continue.

If anyone has any more info about this issue please, please leave a comment.

I recently read an interesting post on Rob Caron's blog which referenced the importance of static code analysis. I agree with both Rob Caron and David Falkenstein that taking the extra time to run tools like this can help ensure the quality of the software product.

Recently, I have submitted my proposal for my Software Engineering Master's Project at California State University of Fullerton. The project in brief, will discuss how Team Foundation Server can be used/customized to promote quality control within a project such that it can remain within statistical control. One of the sub-points in my proposal summary was the fact that Team System could support static code analysis and that with each project (or each iteration if one were that ambitious), that rules could be modified based upon the possible issues which may been found responsible during root cause analysis on the Bugs which QA found. As a result there is a need to easily customize rules and deploy them to client machines. At last, I found a great resource on how to build custom rules with the Team System Static Code Analysis tool (FxCop). The FxCop Blog is a great resource.

While searching the weblog I found this great post in the FAQ section. It is a great reference for creating new rules and registering them with the Static Code Analysis tool in VSTS. Simply follow the steps listed and make sure to read some of the information which I have provided below.

The post contains an zip file containing the sample source required to build a custom rule which checks member prefixes. The entry is a little outdated, thus you should take the following into consideration.

• The directory where the rule dlls should be dropped has changed since the post was written and is now located at C:\Program Files\Microsoft Visual Studio 8\Team Tools\Static Analysis Tools\FxCop\Rules
• You only need to copy the .dll into the directory listed above. The other files are not required to register the rule. (The xml file is an embedded resource)
• More FxCop FAQ can be found on this Microsoft Forums post
• Screenshots 

Screenshot: Drop the built dll into the following directory.

Screenshot: Code Analysis enabled with Samples rules enabled

Screenshot: Code Analysis warnings when Building the Solution

There was a recent TFS Version Control Blog post which asked the community for feedback regarding TFS Version Control Check-In policies. The feedback questions were as follows:

1. Would you like us to release a check-in policy pack together with some best practices and ship that out of band?
2. If we do decide to do this then the next question becomes which policies are customers writing themselves that we can standardize and put in the pack?
3. Which policies would customers like to see as examples?

Please visit reply to the post so that we can hopefully convince the TFS Version Control team to release a some standard check-in policies.

The TFS Version Control Blog is ran by Mario Rodriguez who is a program manager on TFS Version Control. Keep that in mind when you post your feedback comments. I know that I would personally love to see a standard check-in policy pack which would handle the most common policies. Due to the fact that these policies are assigned on the server, but need to be enforced on the client, has been somewhat of an issue for myself. Out of curiosity...Is there any standard approach to making these policies. I do understand that we need to override the methods from the PolicyBase class, but is there a recommended way to deploy these policies to all of the clients?

It appears the channel9 will be adding an additional VSTS tag for all Visual Studio Team System releated content.

We recently started tagging new Visual Studio Team System-related content on Channel 9 with a VSTS tag to make them easier to discover. I also just finished tagging all of the older Team System-related content as well. There were several great videos out there, including some that I had never even seen before!

Brian Keller's blog post provides some examples of some videos which can already be found on Channel9. Samples included Application Designer Videos, Code Profiler and Source Control Management. Also there are a few videos which are related to TFS third parties and Microsoft Research Project tools.

View all VSTS tagged content @ channel9.msdn.com

One of my most favorite features with TFS Version Control and Team Foundation Power Toys has to offer is Annotate. With annotate every single line of source code labeled with:

1. The user who made the last changes on each individual line of code
2. The changeset associated with the annotated section
3. The date of the changeset
4. A right click menu which gives you acces to - the changeset details, the history of the file, and the ability to annotate an the previous changeset version.

TFS Annotate Screenshot

Click here to download the latest version of TFS Power Toys

Brain Harry gives us an insight into a few of the changes that we should expect in the next refinement of Annotate.

I stumbled across a very startling blog post by Paul Wilson while reading my feeds today. It turns out that VS2003 will not be supported in Vista and VS2005 is not yet completely supported. I guess I was naive in assuming that both would work fine on the new OS but apparently there are going to be some issues. Im not sure how this will effect my move from XP @ home, but Im absolutely positive that most of our offices are not going to make the switch in a quite a long time.

Check out Paul's blog post

It is interesting to read all of the heated comments in reference to his post.

One of the things that I have noticed about LLBLGen Pro Version 2.0 is that, post installation, the LLBLGenProDataSource control is not added to your control. In my opnion one of the most important additions to the second version for LLBL is the fact that it supports the ObjectDataSource control model, but the control is only useful in your organization if people use it in development.

The following is a summary of how to add the DataSource control to your Toolbox:

1 .Right click toolbar and choose items. (Loading the choose items dialog may take a few moments)

2. On the choose items dialog click Browse

3.Locate the SD.LLBLGen.Pro.ORMSupportClasses.NET20.dll and select open.

4. The choose items list has now been updated.

Sort the list by name and check the box next to LLBLGenProDataSource. (note both of the Datasources will select automatically).

Select OK and view the new items on your toolbar.

It turns out that we have installed the TFS Workgroup edition which translates to the fact that we can have a maximum of 5 registered users on our TFS environment. I guess I should have done a little more research into the licensing issues involved with our MSDN subscriptions but it was such an interesting opportunity to:
1. Install TFS and get it up and running with all of its individual components.
2. Convince our department that a move toward this technology would be a step in the right direction.
3. Gain access to a pilot project which would be used as both a model for future projects and a platform for learning all of the ins-and-outs of using TFS throughout the entire lifecycle of a software product.

From here, we are going to have to look at the different licensing options and choose the best option for out team. The one biggest concern that I have is that the workgroup edition will not be updateable.

More info:

Don't Install Team Foundation Server Workgroup Edition!!!
MSDN Subscriptions Chart
Rick LaPlante's WebLog Post
Eric Hammersley's WebLog Post
Rob Caron's WebLog Post
Team System Licensing Whitepaper
How to upgrade TFS Workgroup Edition

Here is an older post from Scott Guthrie with several tips, tricks, recipes, and gotchas regarding ASP.NET 2.0. Topics include:

• User Interface
• Data
• Security
• Visual Studio
• Deployment
• Performance

Click here to check it out.

Team Foudation Power Toys is a great collection of tools which are freely available for TFS.

Great features include:

• Annotate - IDE supported feature which allows you to view who last changed the contents of the your project's source files. Never will you have to wonder who is responsible for that ridiculous defect which you were forced to fix.
• TreeDiff - IDE supported feature which allows you to compare the difference in content between two different folders (ie. your local working folders and the server folders).
• And many more
  

Download Team Foundation Power Toys @ http://go.microsoft.com/?linkid=5431080

More details can be found @

• http://blogs.msdn.com/bharry/archive/2006/09/07/74...
• http://blogs.msdn.com/csell/archive/2006/06/21/641...

There are a number of great features in Microsofts Team System Suit and Team Foundation Server components. Of course there are the obvious advantages for the automated, process level, toolset which we gain with the integration of the numerous Microsoft components (Sql Server, Reporting Services, Sharepoint Services, Visual Studio 2005), but the customization of the framework is great as well.

The obvious benefits for TFS is can be found from the top down. Upper management has a newfound lookout tower over all of their projects, project management has more control over the project, and the developers have all of the new cool tools without all of the manual work. However, the customization of the TFS work items, policies, and practices, in my opinion, is will be what standardizes its use across all the industry.

That being said, I found some great blog posts on customizing the checkin policies:

Basic overview of customizing checkin-polices from MSDN.
http://msdn2.microsoft.com/en-us/library/ms181281....

Marcel de Vries has a great post describing an overview of the building a new policy.
http://blogs.infosupport.com/marcelv/pages/CustomP...

Some code samples from another post.
http://blogs.infosupport.com/marcelv/pages/CustomP...

And yet another .zip containing the source and solution for a comment required policy.
http://blogs.vertigosoftware.com/teamsystem/archiv...