Brian Keller has provided the opportunity for you to submit any Team Foundation Server questions for his upcoming Visual Studio Team System Channel 9 interview with Brian Harry. If you recall, Brian Harry recently posted about the roadmap for TFS, and in the interview he has agreed to take some questions. I submitted a question regarding TFS's inability to track requirements and if it will be released in subsequent versions...lots of people have been asking this.

Check out already-recorded VSTS Channel 9 videos

One of the common gripes about Team Foundation Server is that fact that it doesn't support out-of-the-box continuous integration. Well Im sure the team had their reasons to exlude this feature in the first release, but hopefully we will get this in a future release. Until, then we will to come up with something on our own. Ben Waldron addresses these concerns in his Agile Development MSDN article on TFS and Continuous Integration.

Brian Harry's latest post lays out the roadmap for Team Foundation Server.

When I think about the TFS roadmap, I think about 3 different categories of things:

Servicing – These are Hot fixes, Service Packs, etc that fix bugs and add new capabilities to versions that have already shipped (today, that means TFS 2005)

Out of Band releases – We call them Power Tools (used to be Power Toys).  These are add-on tools/utilities that enhance the value of already shipped products without actually modifying them directly.

Major releases – These are the big new releases.  The next one is called Visual Studio “Orcas”.  In parallel, we are also actively developing for the release after Orcas, which I’ll describe at a high level.

...........

Please check out his post for a more specifics.

Last month I posted on Mario Rodriguez's blog post in which he was requesting community feedback regarding TFS Version Control Check-In policies. As a result of the feedback which was received, the TFS Version Control team is going to be releasing a Control Check-In Policy Pack.

In his latest post the current goals of the pack of policies are described:

Check-in policy granularity: there is one already in Code Gallery and what we will do is package this, change some of the UI and take out some of the complexity

Work-Item Associations: This is a very cool one that I hope many of you will find useful. You get to specify a query and if the associated work items by the developer are not part of the query results the check-in is blocked. This is very useful when it comes to making sure that check-ins are always associated with approved bugs.

Banned files: this policy allows you to specify a file extension or a regular expression in order to keep files that you don’t want out of version control. This is usually used for dll’s, build artifacts, or some website files that are automatically generated.

Check-in Comments: this policy gets shipped as part of the SDK. It looks at the check-in comments and makes sure it is not blank.

Here is the situation:

You need to deploy a new version of your ASP.NET application but the application is running and consequently the .dll's are unable to be deleted because they are "being used by another process". What you would normally do is remote into that machine and kill the ASP.NET worker process (or take the application offline in IIS) so that the .dlls could be released. Only then could you delete the existing files and copy over the new application.

The problem: What if you do not have access to remote into the server and cannot kill the ASP.NET worker process or to take down the application in IIS. How in the world could you deploy these files if you cannot take the application offline in order to release the .dlls from memory?

The solution: ASP.NET 2.0 introduced the feature where you could place a file called app_offline.htm in the root directory of the application, and this would take the app offline. As a result, the runtime files are released and you are able to update your application as well as to provide a .htm page with description of the problem. This is a tremendous help.

Thanks to Sasha for his help finding this feature and if you would like additional information you can check out Scott Guthrie's post on App_offline.htm.

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 found this list of top 30 software engineering mistakes at DotNetKicks.

# 20. No understand the deployment or hardware the software is to be installed on.  Ohhhh it's for a Macintosh... lol.  Well hopefully not that bad, but you get the point.

I found myself asking....why the hell would anyone want to write software for a mac....which interestingly enough...is not in the list of top 30 software engineering mistakes. Enough of my anti-mac rants.

This is a little late, considering the fact that .NET 3.0 (NetFX) was released a few days ago, but I still think it is worth noting. The release of .NET 3.0 doesnt really have any profound impact on me, however some parts of my company have begun integrating Windows Workflow Foundation into our new and existing projects. I'm almost positive at this point that I will not be able to get my hands on any projects which utitlize any of these new seperate features, however I am installing .NET 3.0 as we speak and am looking forward to learning about all of the new features.

Download .NET 3.0 Here

Just in case someone didn't yet know what were the new features in the 3.0 version of the framework, here is an entry @ Developer Zen which provides an overview using demos.

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.