Team System

SharePoint 2007 custom Workflow Debugging Quirk with Visual Studio 2008

Bill Sheldon — Fri, 07 Mar 2008 10:54:00 GMT

So I noticed an issue the other day. I have a custom SharePoint 2007 workflow as part of some work I'm doing on an Office Business Application (OBA). Now if you were at the Office Developers Conference (ODC) in San Jose this year you saw Jay Schmelzer demonstrate how you could with Visual Studio 2008 start up the debugger on a SharePoint State Workflow project and have Visual Studio automatically update and deploy the files associated with your workflow. It's a great capability and very powerful when it comes to working with SharePoint workflow projects.

However, I recently ran into a problem every time I went to debug my workflow the deployment step failed and the debugger failed to start. It took a little while but I soon realized that the problem was related to two of the files the workflow.xml and the feature.xml files being marked read only in the deployment directory. It was only a short time after that till I realized that the problem was related to the fact that I had finally bound my development environment to our Team Foundation Server (TFS).

It turns out that when Visual Studio deploys the files associated with the workflow it leaves the file attributes unchanged from your development directory. This is an issue because in working with TFS and not having these files checked out they are marked as read only. The first time you deploy no problem, the old version wasn't read only... but the second time the deploy fails. Once you check the files out - even though you aren't planning to edit them, Visual Studio will deploy writable copies again. However, you'll first have to access that directory on your system and manually reset the files to not be read only.

Team Explorer 2008 Install Error

Bill Sheldon — Fri, 23 Nov 2007 13:02:00 GMT

Once I installed Visual Studio 2008 it was time to add the Team Explorer for Visual Studio 2008. The Team Explorer aka Team Foundation Client is found on the Team Foundation Server installation DVD.

So I took the .ISO file which I downloaded from MSDN and copied the TFC folder which contains the Team Explorer installation onto an actual DVD. This gave me a copy of just the Team Foundation Client 2008 which I could install onto my development machines.

I put the DVD into my Vista/Office 2007 machine and kicked off the install. The install ran and after things were going I moved onto another machine. When next I checked I found that the installation had failed. So I reported the failure via the automated process that the install package provided and tried again. The install failed again - which left me... concerned.

So I took the DVD out of my Vista machine and moved to my Windows XP / Office 2003 machine and ran the installation. While that was running I started searching the web for any known installation errors with Team Explorer 2008. I finally found a note in the Microsoft MSDN Forums that mentioned someone else was having an install problem and found that it went away when they used the install from a DVD which had all of the TFS products, as opposed to a CD with only the TFC folder.

Now what was interesting is I found this as my Team Explorer install on Windows XP with Office 2003 completed successfully. In other words on an XP machine running Office 2003 you only need the TFC directory to install Team Explorer.

So I went to my .ISO file and burned a DVD of the entire image this time and put it into the Vista/Office 2007 machine. I must admit I really like the updated install package for the TFS product, having the different product options available is a nice way of handling the different install packages. At any rate I clicked on the Team Foundation Client and started the install. The first and subsequent screens to start the installation looked just like the stand-alone DVD's and the install started with the same packages. However, in this case the installation ran to completion.

Thus if you are using Windows XP with Office 2003 you can install a standalone installation package for Team Explorer however, if you are running Vista or Office 2007 and you get an installation error - then make sure you get a copy of the full Team Foundation Server (TFS) DVD and run the install from that media.

Team Build and the TFSServices Account

Bill Sheldon — Sat, 05 Aug 2006 20:55:00 GMT

So the time has come... you installed TFS and have the basic installation running and then, one day you realize you need to install Team Build separately from the baseline TFS install. So you go back to the install CD and open the build directory and do the Team Build install. No worries until you get to that screen that asks you for the account to use. Of course the documentation says - use the TFSServices account, but it's been months since you installed that and you can't possibly remember the complex never to be used again password you used.

So think about it and figure - look I'll change the password on the TFS Services account and just update the associated services. So you do that, you install Team Build and everything is looking good. No worries, you even install Visual Studio so you have a compiler available for Team Build to actually use for builds. Then you install SQL Server SP1, and restart the computer.

The computer comes back on line and - TFS is dead. The web sites all say service unavailable - and by all I mean both your WSS project sites and the WSS administration site. Your connection via Team Explorer both remote and local is also unavailable. Oh crap now what!

Well when I hit this point I then went looking in the event log. The application log wasn't too helpful - it was able to tell me that the problem was related to TFSService connecting to SQL Server, but that was about it. After a few permission enhancements and protocols being turned on still nothing. Then I jumped over to the System log. Here we had something useful - the error message on the event: "A failure was encountered while launching the process serving application pool 'TFSWSS'. The application pool has been disabled." ahh now this points me to something useful. Off I go to the IIS Manager into my app pools and there they are the two app pools that use TFSServices as their runtime context (TFSWSS and TFS AppPool). Update the password, restart the app pools and all is good with the world again. Note that the 'TFS Admin' app pool doesn't use the TFSServices account. At any rate in case you run into a similar scenario remember - don't panic - dig the event logs the clues are probably found there.

Team System Presentation Slides

Bill Sheldon — Thu, 13 Jul 2006 09:02:00 GMT

For those who have attended one of my recent presentations on Visual Studio Team System and Scrum, I have uploaded my slides. Hopefully you found the presentations helpful and will be able to better understand all of what goes into Team System (Team Suite and Team Foundation Server) and how you can leverage these tools in your organization to improve your project success. As I note - Team System isn't about technology it's about the business of software and having the tools to be successful.

TeamSystemandScrumOverview.pps (2.3 MB)

VSS & TFS - Coexistence on the client

Bill Sheldon — Mon, 12 Jun 2006 09:33:00 GMT

One of the things which will occur for certain developers is a need to be able to connect to both TFS and VSS from the same development PC. This may occur as a company transitions from VSS to TFS or for consultants when you move from working with company A who is using TFS to company B who is not.

In my case I went from having been configured for TFS to needing to install VSS for a client. Once I installed VSS, my ability to connect to TFS source control seemed to disappear.

Both the VSS and Team Explorer clients can be installed on you machine. However, you have to make a choice between which server side source control data store you will use. To do this from within Visual Studio go to the Tools menu and select "Options..." In the Options window select "Source Control" from the list of areas for customization and you can go from there, as shown in the screen shot below:

Scrum Process for TFS

Bill Sheldon — Fri, 31 Mar 2006 23:51:00 GMT

Conchango - apparently a British company has worked with (or has some relationship with Ken Schwaber) and they have released an add-in to the release version of TFS which applies the SCRUM principals to the Agile methodology in TFS. So when you install TFS you'll find you get two process templates by default, after installing this freely available add-in you'll find you have a third template with it's own custom documentation. My only complaint is Ken's picture - nothing personal Ken but I don't find you attractive enough to really want to see you picture all over the place :-)

You can find the link for the free (with registration) download here: http://www.scrumforteamsystem.com/en/default.aspx

Hat tip to Rob Caron's blog for this info: http://blogs.msdn.com/robcaron/

Security and Static Analysis

Bill Sheldon — Thu, 17 Nov 2005 17:48:00 GMT

One of my least favorite errors when I first ran Static Code Analsysis was this security warning:

CA2209 : Microsoft.Usage : No valid permission requests were found for assembly 'IKRulz'. You should always specify the minimum security permissions using SecurityAction.RequestMinimum.

So what is the solution to this warning, and where in the heck do I set these permissions. Well under .NET 2.0 you need an application manifiest (app.manifiest) file as part of your project settings. The application manifest basically tells the CLR what type of security your application expects to need, so for example if your application requires full trust your app.manifest will look something like:

xml version="1.0" encoding="utf-8"?>
<asmv1:assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<applicationRequestMinimum>
<defaultAssemblyRequest permissionSetReference="Custom" />
<PermissionSet class="System.Security.PermissionSet" version="1" Unrestricted="true" ID="Custom" SameSite="site" />
applicationRequestMinimum>
security>
trustInfo>
asmv1:assembly>

Which is of course a totally simple thing to figure out right? OK, so does this mean you need to start going to all your app files and adding what are best described as some somewhat obscure XML properties to define your apps security settings. Well no not under Visual Studio 2005. With VIsual Studio 2005 you can simply go to your project properties and there on the edit pane is a right hand panel for Security, as you can see below:

Now that you are on the security pane you can choose to enable your ClickOnce security settings. This will generate your App.Manifest automatically.

But wait there's more. As you'll probably see in every demo with Visual Studio 2005 it is possible to mark your assembly as having less then full rights. The key to this is the "Calculate Permissions" button you see above. This button compiles your code and using reflection determines what permission level your code actually needs. In my case the code references local files system files, and therefore requires full trust. However, the ClickOnce options allow you to determine that on the fly and have Visual Studio 2005 automatically determine whether your application will meet your deployment model.

GlobalSuppressions.cs

Bill Sheldon — Wed, 16 Nov 2005 09:34:00 GMT

So one of the new features I've found with Static Code Analysis in Visual Studio 2005 is that it allows you to suppress messages. As I blogged earlier, the typical behavior is for the tool to add a line to your source file to suppress a warning that you find to be unnecessary. So I was playing with the Namespace related rules which allow you to try and keep variables named appropriately and it flagged the namespace name I used. I have an acronym as my Namespace and that meant it’s all capitals which of course the rule didn’t like. So I decided to ignore the warning, only this time since the warning occurs across several files instead of adding a line to each file which referenced the namespace the Static Analysis tool created a new source file called GlobalSuppressions.cs and added the suppression line to that file. Here are the contents of this new source file in my project:

[assembly: System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Naming", "CA1705:LongAcronymsShouldBePascalCased", Scope = "namespace", Target = "IKRulz")]

As you can see the only thing in the file is the declaration to create an exception for that rule, but in theory I could add other rules to this file if I found the same message in several locations in my code allowing me to limit the number of times I needed to exclude a particular message. Of course I could also just avoid running certain rules, but that’s a different discussion.

Static Code Analysis Exceptions: Implementing Suppression

Bill Sheldon — Fri, 11 Nov 2005 13:32:00 GMT

When working with the Team System Static Code Analyzer there are times when the tool will throw out an issue that isn’t something you are going to resolve. Of course when you first run the code analyzer it’s not uncommon to have a list of literally hundreds of potential issues. As I’ve discussed in the past, the best solution when this list is long is to use the configuration settings to limit the areas of focus to things like performance and security and then move on to other areas.

However, as you are processing your potential issues, the fact is that some of those items won’t be issues. It’s very possible that the tool might warn about code which in fact in the limited context where it is used is implemented correctly. As such it’s important to be able to make those issues disappear from the overall list. In fact let me provide some sample code:

private void stackButton_Click(object sender, System.EventArgs e)

{

foreach (ToolStripItem item in this.stackStrip.Items)

{

if (item != sender && item is ToolStripButton)

{

((ToolStripButton)item).Checked = false;

}

So if you take the method above you’ll see that it is referencing an untyped collection of items, and by reviewing the ‘if’ statement we can tell that it is looking for one of multiple possible types in that collection and then casting and using objects of that type. Pretty straightforward and in the context of what it does I don’t see a better way of handling what it’s doing (you are welcome to educate me in the comments section…)

When I run this code through static analysis what I get is the following performance related warning:

CA1800 : Microsoft.Performance : 'item', a local, is cast to type 'System.Windows.Forms.ToolStripButton' multiple times in method StackView.stackButton_Click(Object, EventArgs):Void. Cache the result of the 'as' operator or direct cast in order to eliminate the redundant castclass instruction.

However if you look at the code the fact the casting from a functional standpoint is done only one. There’s no real redundancy of the casting instructions and no reason to cache the results. So what should we do, well we should indicate in the code that this condition has been reviewed and isn’t something we want to be warned about. Right clicking the error in the error list I select the “Suppress Message(s)” option from the context menu and the current warning is shown with a strike-through font. On subsequent builds/checks the error is not displayed.

Which begs the question of how does Team System implement this rule exception? The answer is that it adds an attribute to my source code. This attribute is actually a method call which tells the code analysis engine to ignore one or more rules in the scope of the current method call. Below is the instance of the SuppressMessage call attribute for this example message.

[System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Performance", "CA1800:DoNotCastUnnecessarily")]

This call allows the code analysis to recognize which message has been suppressed in future runs, and because it’s part of the source code the suppression is checked into source safe and easily recognized by others looking at the code. In addition to the SuppressMessage method there is a SuppressMessageAttribute method which has the following signature:
[global::System.Diagnostics.CodeAnalysis.SuppressMessageAttribute("Microsoft.Performance", "CA1811:AvoidUncalledPrivateCode")]

This example of that call is for a different message generated by migrating code from the Beta versions of VS2005 to the release version… in this case I want more time to investigate the implications of making the change suggested by the message to ensure that I eventually do this I can add a task to my TFS project, but that’s a story for another post.

Changes to the TFS Configuration Service

Bill Sheldon — Thu, 10 Nov 2005 16:10:00 GMT

Back with Beta 2 it was found that Microsoft had set the refresh rate for the reports and data warehouse at 2 minutes. The appropriate setting to avoid having your CPU thrash is about an hour. As I explained in my May 2005 article this issue is more fully explained here: http://blogs.msdn.com/buckh/archive/2005/04/19/409886.aspx.

The Beta 3 Refresh of TFSMicrosoft resolved this issue. In order to verify this I went to the service. Note, under Beta 3 Refresh the controller service has moved slightly to this url: http://localhost:8080/Warehouse/v1.0/warehousecontroller.asmx. Once at this url you need to access the 'GetNextInterval' method which accepts an integer. Pass a 1 or 0 or whatever, and the service will return your servers updated interval value. My experience is the current default is 3600 which is the correct value.