Eric Matz

For those of you that build MSIs to package your applications, you'll quickly find that MSBuild does not support this, so the TFS Build Server cannot build your vdproj setup projects.  Anutthara Bharadwaj has a good post with the workaround for this.  Pay attention to the part about needing Visual Studio installed on the build server - if you're like me and you installed the Team Explorer client on your server to test things out, you might be fooled into thinking VS is already installed.  I felt pretty dumb when I figured that out, but at least I'm admitting to it!

Since Mickey Gousset raised a good point in his comment on my previous TFS post, I've been looking into this further.  I was going to post my findings from the current licensing white paper, but Chris Menegay basically said what I was thinking.

“Anyone editing data will require a CAL“  What exactly does that mean?  I hope they add clarification for (and exclude) API usage.  At TechEd '05 they showed a demo of Team System's collaboration capabilities.  In it, they talked about how easy it would be to have a "Feature Request" Work Item entered by an end-user via some interface (like a web portal or Outlook add-in) and have it go all the way through the development life cycle.  So...if I create that custom Work Item and enable a portion of my website to allow users to enter Feature Requests, do I need a CAL for each person?  I hope not...no way would I be able to determine how many to buy, nor would it be cost effective.

My biggest concern is all the people internally that need to be able to enter/change Work Items.  They are not technical, so a very simplied interface is critical.  I've started looking at Team Plain, and I think it will do the trick as long as I can limit it to just Work Items.  However, I'm not sure my management will approve when I tell them it will cost $499 a pop to allow people to enter bugs via a web application.  They will tell me it's cheaper to leave the current system in place, even though it is pretty lousy and doesn't integrate well at all.

TFS is a fantastic product.  I can't remember the last 1.0 release of anything that has impressed me so much.  The source control aspects alone are probably sufficient for me to justify the spending, but I want to sell them on the Work Item tracking.  If Microsoft adds the ability to manage Work Items via the TFS SharePoint Portal and does not require a CAL for each user, THIS WILL BE A SLAM DUNK!

Synchronizing your machine keys is a great way to provide a single-sign-on experience when using ASP.NET Forms Authentication.  This tells ASP.NET a specific key to use when encrypting/decrypting the ticket, and when multiple servers or applications use the same keys, they will accept the ticket generated by the inital login.

When I tried adding a 2.0 application to the mix, it did not work.  The solution took some digging, but was pretty simple.  ASP.NET 2.0 allows you to specify a decryption attribute in the machineKey config element.  ASP.NET 1.x did not let you specify it - Triple DES was used by default.  However, ASP.NET 2.0 uses DES by default - specifying DES as the decryption algorithm resolved the issue.

One of the key things I feel is missing from Team Foundation Server is access to managing certain things, specifically Work Items, from a web-based interface.  In fact, Team Foundtion Server is going to be a hard-sell to my management if this capability is not there.  I have a large number of users who will need to be able to enter bugs, and it would be nice if they could do so from a web-based interface - ideally, the SharePoint portal site for the Team Project.  I'd prefer not to have to buy a CAL and install the VS Team Explorer on all those machines; and while developing this myself sounds fun, I really don't have the time.  I read somewhere (having trouble finding the blog post) that this feature was planned, but would not make it into V1.0.

I may not have to worry.  One company is already working on a product to address this need.  Take a look at TeamPlain if you're in the same boat as I am.  I really wish they'd implement this as Web Parts so they could be integrated into the SharePoint portal, but I'll take what I can get.  I'll post more thoughts once I get ahold of the beta version.

Two of my favorite utilities (which happen to be written in C#)...

Ruler: http://www.sliver.com/dotnet/Ruler/

Cropper: http://blogs.geekdojo.net/brian/articles/Cropper.aspx

I've been working on getting the various web applications that make up our system migrated to the 2.0 framework and VS 2005.  Class libraries seemed to convert with little or no effort.  Most of our we service projects also seemed to convert into the new Web Site project format with little effort.  The front-end project, however, has proven to be a major effort.  I found that I can get the job done much faster by using the new Web Application Project format, the beta of which was released just recently.  While the new project format is much more dynamic and offers a lot of advantages, I'm afraid getting to that format is going to be a major challenge with large projects where a lot of liberty has been taken and the “make the conversion process easier by avoiding these items“ list hasn't exactly been followed.

Get the info here http://webproject.scottgu.com/

I'm not certain that I will go this route when the time comes to change horses.  I may revisit the default conversion process after I've addressed some of the issues that may make conversion easier.  My goal this past week has just been to get everything to 2005 as quickly as possible for some proof-of-concept testing with Team Foundation Server.  Thanks to Scott Guthrie and his team - mission accomplished.

Nice surprise this morning!  I think it's safe to say I won't be sleeping much this weekend.

I just want to say for the record that the last five minutes of Ingo Rammer's session this afternoon might have been the most valuable of my entire week.  My team is deploying a new system next month with Web Services making up a number of components.  Obviously, we have not done any load testing of this system yet because it most definitely will not scale - at least not the way ASP.NET is configured by default.

In the machine.config, you'll find the following element:

<connectionManagement>
   <add address="*" maxconnection="2"/>
</connectionManagement>

This limits the number of concurrent connections to 2 for a single IP address - not a major issue for a web server (one server, thousands of clients).  For a web services server that serves up functionality to the web server, however, it is a HUGE issue (one server, ONE client, two max concurrent connections).  As Ingo put it, that quad processor web server with 25 threads per processor that can serve 100 simultaneous clients now gets throttled to two.  Ouch.  Well, it's easy to fix.  Just add this to the Web Service's web.config inside <system.net>:

 

<connectionManagement>

   <add address="my.web.server.ip" maxconnection="100"/>
   <add address="*" maxconnection="2"/>
</connectionManagement>

 

So, kudos to Ingo for saving me a lot of pain!  The entire session was fantastic - lots of great tips and tricks for tracking down scalability issues that I'm sure will come in quite handy.  Bravo!

Well, I've been a .NETophile for over two years now - about time I jumped on the blog bandwagon...and about time I made it to Tech-Ed!  I spent the evening trying to sift through all those sessions and figure out which ones look the best.  Then I went to work on the laptop.  I finally busted open that 3.6 gig ISO that I've had in my temp folder for awhile, so now I'm all set to go with VS.NET 2005.  I'd love to play around, but right now it's 1am and those two human alarm clocks (aka kids) are going off at 7am whether I like it or not.  More to come...