Sometimes a file gets locked in TFS, and for whatever reason, you need to unlock it. You can use the tf command line utility to accomplish this.

tf lock /lock:none $/Project/AnyFile.extension /workspace:ComputerName;User /s:http://TfsServer.Com:8080

Server

Today I tackled upgrading my development server from BizTalk 2006 (Developer Edition) to R2 (Developer Edition). You can read my previous post on installing R2 on a clean machine. Detailed instructions (for all supported install scenarios) can be downloaded from Microsoft Downloads (See below for another link).

Upgrading was extremely easy, and I encountered no errors or warnings. I used the same cab file I downloaded for my clean install, since it was the same platform (Windows Server 2003 32 bit). You need to stop all BizTalk related services, and IIS (this is detailed in the instructions) during the install, and then restart them after the upgrade is finished. There wasn't even a reboot required.

One thing I'd like to point out, is that upon first glance, it looks like you are still running BizTalk 2006. The banner in the admin console doesn't mention R2, there is no new group in start/programs, even though the upgrade process lists an unistall step of BizTalk 2006 and an install of R2, there is no R2 program listed in Add/Remove programs, and the 2006 is still listed. Re-Running the R2 installer gives you options to repair, modify or remove, so the installer seems to think everything is correctly installed.

Not quite convinced I decided to look into this further. There is a registry key, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BizTalk Server\, which lists versions. I had a sub key for 3.0 and 3.5_Migrated. On my clean install, there is no 3.5_Mirgrated key, the admin console, and Add/Remove programs all list 2006 (not R2), so I guess that's just the way it is. If you are in the admin console and go to Help\About Microsoft BizTalk Server Administration, it lists version 3.6.1404 (compared to version 3.5.1602 before the upgrade). I guess I had an expectation that it would say R2 somewhere.

Another gotcha, is that the new WCF adapters are not installed by default. After the upgrade process, you have to re-run the installer and choose modify. Then you can add the WCF adapters, both under the BizTalk runtime, and admin tool. That goes for any optional component. If it wasn't installed before the upgrade, you have to go in and add it after the fact.

Workstation

Figured now was as good as time as ever to upgrade my workstation (development components) as well. The link I posted above didn't have a guide for installing on Vista, but a quick search found another page on Microsoft Downloads that did have a Vista Guide. I wasn't planning on reading the guide, but I couldn't get the install process to even start under Vista, so figured some trickery might be involved.

The first thing I did was find the redistributable components for Vista, so I could start downloading those while reading the install guide. The link to the components in including in the Technical Appendix in the install guide, and at the time of this post, the direct link is: http://go.microsoft.com/fwlink/?LinkId=81432, and weigh in around 30MB.

Since I just want the development tools, I skipped to page 21 in the guide, which are where the install instructions start. There was no special steps listed for Vista. I ended up rebooting my computer, and still couldn't get it to start (clicking install BizTalk from the setup screen didn't seem to kick off the msi process). I tried running the msi directly, and got the expected error saying to run setup. So I went back to setup, and this time it worked, weird.

After I actually got the installer running, everything after that was as easy as the server upgrade. I could have appreciated support for VS 2008, but 2005 isn't all that bad. The only time I would notice a difference is if I am working on a class library instead of a BizTalk artifact.

Rant

I don't like anti-virus software, and I like real time virus scanning even more. It's like trying to fix a paper cut with brain surgery. There are plenty of guidelines out there for how you can configure your computer, and how you can be a smarter user and avoid virus, spyware etc. Those are mainly for workstations and home PCs, but what about servers?

My take on servers is, you shouldn't be doing anything that compromises the security of a server, and that includes browsing the web, using a standard or admin account. So if you cut out browsing, don't install warez, what's left? I know, I know, what about things like Code Red? When Code Red first hit, it didn't matter if you anti-virus installed or not, the attack was so new that your only defense was to pull your web server off line until you got it patched. A virus from last year, should never find it's way onto your server if you are careful, leaving zero-day exploits and black market hacks, that AV isn't going to catch it right away anyway. About the only thing AV software is good for, is finding that bot net Trojan your Mom gets when she installs Super Happy Smiley emoticons for email. 

I know I'm not going to win the argument for not having any anti-virus installed, but let's at least be intelligent about it ok? If you call yourself an IT administrator, Network Administrator, etc, now is the time to earn that title. Anyone can carpet bomb a network with an enterprise anti-virus package. The AV makers even make it easy to auto deploy their poorly written, resource hogging craplets via auto install software and group policy.

A true administrator will take the time to come up with a comprehensive approach to computer and network defense, including the intelligent installation and configuration of AV software. I found an excellent document on folders and files you should seriously consider exempting from real time, and even on demand scans.

Yeah, yeah, I know, just run Linux on the desktop and use a LAMP stack for your servers.

My task (well one of them) for the week was to update one of our Custom BizTalk adapters. Be sure to read my post on how to Install a custom BizTalk Adapter for some background information.

One of the changes I needed to make (which I had been putting off), was changing the namespace. Namespaces are case sensitive in the world of BizTalk. So if you change the namespace, you have to update the registry entry for the adapter with the new case sensitive namespace. Also, it seems like you need to uninstall the adapter from BizTalk in order to use the new assembly, since the TypeName changed.

In order to do this, I used the BizTalk admin tool to delete the adapter (BizTalk Group\Platform Settings\Adapters), update the registry, then re-add the adapter. If you are making calls to resource files where you are specifying the type name, be sure to update the string you are passing in as those calls will now fail. Even better, you should have a single string constant that defines the type name so you only have to make this change once.

Once the namespace change was finished, further changes to the assembly, only required me to copy over the existing assembly and restart the host process. Exceptions in adapters, at least our custom adapter, would cause the host process to keep restarting, so I ended up disabling the windows service for the host process after restarting/starting it, just to keep down on the repetitive errors.

Robust and proper error handling is a must in custom BizTalk artifacts. I find that writing errors to the event log works the best, and to include a domain specific error message, error code, and Exception.ToString(). The error codes are nice because you can go back in search for them in the code. They also are easily referenced in tech support and trouble shooting documentation.

In my specific case, a custom adapter which used the BizTalk PollTask mechanism, uncaught exceptions are written to the event log with the full stack trace. This means, that you don't need to catch general exceptions (and static code analysis says we shouldn't). Starting from exceptions thrown by PollTask, I added specific catch blocks to log specific information useful for trouble shooting, and re-threw the exception using "throw;" which re-throws the original exception. This causes the adapter to error out, and to be honest I do not know if this is the best way to handle things. It results in the host process restarting as mentioned above. When the out of the box adapters have errors, like the File adapter not having permissions to the specified folder, the adapter is eventually shut down.

Found some more information on TFS 2008 RTM from bharry's blog on MSDN. Most important to me and my team, is that the RTM media is not available for volume license customers until sometime in January. However, you could upgrade to the RTM Trial, and then add in your PID (Product ID) in January when it's finally available. The trial is good for 90 days, and bharry assures his readers that PID's for volume license customers will be available before then, and if not to contact him directly.

Upgrading to RTM sounds like something I will probably do around Christmas, as it's usually a slow week anyway. This would give me until the end of March to get my PID, which is probably close to when the beta we are currently running would be expiring anyway. Speaking of upgrading, it sounds like the process outlined by ScottGu which I talk about in my previous post, also apply to TFS.  There is a link script on bharry's post, which is supposed to help with the process. I will try to use the script for when I update my primary workstation, and will report back on how well it works.

Note: While I didn't have any problems, I would recommend keeping the iso for Beta 2 around until you are confident you got everything removed. Sometimes software needs to get something from the original installer to uninstall.

In case you have been living under a rock this week, VS 2008 RTM was released. I don't expect to see much difference between Beta 2 and RTM, given how solid of a product Beta 2 was. ScottGu has a post on the recommended steps to uninstall Beta2 and install the RTM version. It sounds like you could install on the top of Beta 2, but I prefer to put forth the extra effort to get a "clean" install, or at least as clean as I can get without wiping my machine (is this another example of where moving to virtual platform would make sense?).

Of course the first step was to obtain VS 2008 Team Suite from MSDN, which was a bit of a challenge earlier in the week. I'm assuming everyone was trying to get their hands on it, and unless Microsoft is cheap when it comes to bandwidth (doubtful), it goes to show how much people wanted this as soon as it was released. ScottGu had a previous post about where to get all the bits (including the 3.5 redistributable), and I found this post which led me to the stand alone download for Team Explorer.

Next, I followed the recommended uninstall order. I'm glad that I don't install things I know I will never use, less things to uninstall. The names provided in Scott's post are word for word as they show up in Add/Remove programs, so feel free to sort by name. Even with detailed instructions, I still managed to screw up. .Net Framework 3.5 looks very similar to .Net Compact Framework 3.5, and I ended up uninstalling the full framework first. Not on the list, is Team Explorer, and Visual Studio itself. I opted to uninstall Team Explorer first, and the process froze on me.

A "quick" reboot seemed to fix the problem. I proceeded with uninstalling Team Explorer, and the two entries for Visual Studio. I also rebooted again as per Scott's recommendation, and then began the install process, starting with Team Suite, and then Team Explorer and a few more reboots and I was done.

Update:

I came across a script which is supposed to help with the uninstall of the Beta Bits.

Today I made my first attempt at installing (clean install) BizTalk 2006 R2 on our development server. I started out by reviewing the documentation for installing on Windows Server 2003 in a single server configuration. You can find this documentation by clicking the link on the initial install screen for BizTalk. This will take you to Microsoft to get the latest version of the documentation. I also picked up the multi server deployment (production environment), and Vista (development workstation).  The first part of the documentation is more of reference material. Starting on page 38 it switches to detailed installation instructions for each piece that needs to be installed, starting with Windows Server itself.

Installation Wizard

1. Click thru until you get to Select Components. There are obviously the required core components. I also selected items which I thought we might need in the future, but didn't impact the amount of pre-requisite software I needed to install. There is a very nice matrix in the install document that outlines what needs to be installed for each feature. Based on that I selected:

• Documentation
• Server Runtime
• BizTalk EDI/AS2 Runtime (Possible Future Need)
• WCF
• Portal Components
• BAM (Possible future use)
• Human Workflow Web Service (Possible Future Use)
• Administration Tools
• WCF
• Additional Software
• SSO Admin
• SSO Master Server
• BAM Client

I also had to change the install path from C:\ to E:\ to comply with IT standards.

Clicking next brings you to a screen where you select how you want certain pre-requisites (redistributables) downloaded and installed. Choosing the download option (not auto install), takes you to the MS downloads site and cancels the installation. The cab file I needed to download was 102MB, and will be needed for a couple of other installations, so downloading it separate was a good idea.

2. After downloading and coping the cab file to the server, I restarted the installation, re-selected my components, and then chose the option to install redistributables from the cab file. I opted to provide my password for automatic login after reboots. I've copied and pasted the summary of items to be installed that is displayed before you click install.

Prerequisites

The following component(s) will be installed automatically on this computer:

• - Microsoft SQL XML 3.0 Service Pack 3
• - Microsoft Office Web Components
• - Microsoft ADO MD.Net 8.0
• - Microsoft ADO MD.Net 8.0 Patch
• - Microsoft ADO MD.Net 9.0
• - Setup runtime files
• - Enterprise Single Sign-On Server
• - Enterprise Single Sign-On Administration
• - Microsoft Primary Interoperability Assemblies 2005
• - Microsoft Document Explorer 2005

Microsoft BizTalk Server 2006 Components

The following components will be installed:

• - Documentation
• - Server Runtime
• - BizTalk EDI/AS2 Runtime
• - Windows Communication Foundation Adapter
• - Portal Components
• - Business Activity Monitoring
• - Human Workflow Web Service
• - Administration Tools
• - Windows Communication Foundation Administration Tools
• - Additional Software
• - Enterprise Single Sign-On Administration Module
• - Enterprise Single Sign-On Master Secret Server
• - BAM Client

3. No reboots were required, and no errors were reported. By default, when you finish the install, you are taken to the Configuration Wizard.

Configuration Wizard

1. The first thing you have to do is select your configuration type from either Basic or Custom, with the main difference being what service accounts are used for what services. I chose basic, which sets up all of the services to use the same account.

On page 55 of the instructions, it states that the specified user account will be granted the necessary permissions, including SQL permissions. I went ahead and created a local machine account that belonged to the users (not power users) group. I then specified this account in the configuration wizard and clicked Configure.

2. A summary of the configuration about to be performed pops up. I did a quick review, and then clicked next. I then sat, with my fingers crossed as the progress bar ticked by, hoping everything configured correctly. I didn't want to find out what graphic is displayed for an error (on success a green check box is displayed next to each section that is configured). The EDI/AS2 runtime took the longest to configure. I might not install that next time.

3. Everything completed successfully, except there was one warning with SSO. I have a feeling it is a note to back up the SSO secret. Another possibility is that I am running the SSO service with a local, and not a domain account.

Backup SSO Secret

1. Start/Programs/Microsoft Enterprise Single Sign-On
2. Expand Enterprise Single Sign-on
3. Right Click System and choose backup secret
4. Choose a path, and enter a password.
5. Make sure to write down your password and backup the file that was created. I store all my passwords on this nature using KeePass. I also can attach the actual backup file to the password entry in KeePass. If you have problems coping the file, check the NTFS permissions on the file.

Simple Test - CBR

1. Pre-Conditions: Event logs were clear of errors and warnings at this point. I did a quick inspection of services to verify the ones I was aware of, were running.

• BizTalk Service BizTalk Group : BizTalkServerApplication
• Enterprise Single Sign-On Service
• SQL Server (MSSQLSERVER)
• SQL Server Agent (MSSQLSERVER) - Change startup from manual to automatic

2. Reboot and check event logs for errors on startup. I also took this opportunity to snapshot the VM so that I could clean out my CBR test.

3. I created a simple CBR scheme, using 2 local folders, 1 send and 1 receive port. The exact implementation details are outside the scope of this post.

What's Next

Next up, is the upgrade of a BizTalk 2006 install to 2006 R2, so check back for a write up of how that goes.

Microsoft, breaking from it's usual secrecy around the next version of Windows, has released some material on Channel 8 about work being done on the Kernel. Referred to as WinMin, the Kernel weighs in at just 25MB and is supposed to be used in a a variety of Windows products, desktop, server, and small form factor. The video posted, consists of Eric Traut giving a presentation with an integrated power point deck.

The presentation is primarily on Microsoft's hypervisor and vitalization. The comments on Windows 7 don't come until 44 minutes into the video.

Other interesting notes

• Vista and Windows Server 2008 are the first versions of windows that are Vitalization aware
• Admits that upgrading the OS is painful at best. Vista actually installs a new OS and tries to pull settings from XP. Could Windows 7 actually allow you to reinstall the OS without reinstalling?
• Admits it's embarrassing that there are un-installer products.
• Demos of Windows 1 and 2
• WinMin
  • 25MB Kernal
  • 40MB of memory, 7MB free.
  • HTTP Server? I hope that's for demo's only.

The "scheduled" release date is 2010, which is 2-3 years out (simple math FTW). I point out the 2-3 year time frame, because I think it's significant for a couple of reasons. First, how many things got cut from Vista in the 2-3 years leading up to it (WinFS anyone?). Second, how much of what we are hearing today, will make it to the final product? Third, will I still be blogging in 2010, such that I can look back on this post and comment on it when Windows 7 gets released.

I have read comments that Vista is like WinME, and agree somewhat. Not that Vista is as bad as WinME, but that I am expecting (hoping) the next version of windows to be everything Vista was supposed to be, and then more. Along the same lines, people always seem to think that WinXP was so great, but they were comparing it to WinME. I switched to an NT based operating system with Windows 2000 and never looked back. I had a few games that wouldn't run, but there were work around's available. When XP was released, it wasn't as big of a deal for me.

I'm still running XP at home, and Vista at work on my laptop I got back in March. At home, I recently reformatted, and after running Vista for 6 months, didn't see any benefit, especially since I only had 2 GB ram (no need to go 64bit, and yes I realize there is a 64 bit XP), and do DX10 video card. Just over a month later, I'm running 4GB of ram (for no other reason then I got an extra 2GB on the cheap), and I had to go get a new video card (8800GT) to play COD4 at acceptable frame rates and resolutions. Nuts.

With the LAN party this weekend, I don't have enough time to rebuild in time. Then again, it's the type of late night challenge I wouldn't mind. I'm thinking I might just image my system drive and give it a go. I still have all my notes (what to install), from the last time I rebuilt, and the idea of doing a VM based setup with my 4GBs of ram is an option.  

References:

• CNet
• Tech Republic
• Channel 8

As a follow up to my last post, I wanted to post a quick note about a change in the location of AL.exe (assembly linker), in .Net 3.5.

I was attempting to use TFS Build to build a project that was 100% VS 2005 (basically the solution was still a VS 2005 solution), but I was getting an error stating that al.exe could not be found in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727, and that I either needed to pass the path in to MSBuild, or, install the SDK. Not wanting to install an older SKD, I opted for the path option, but then I needed to determine the path. I figured a newer version of al.exe must be installed somewhere with .Net 3.5, and sure enough, it's under C:\Program Files\Microsoft SDKs\Windows\v6.0a\Bin.

I checked out the TFSBuild.rsp file and added the following line:

/p:ALToolPath="C:\Program Files\Microsoft SDKs\Windows\v6.0a\Bin"

Checked it back in, and it worked.  

With our migration to VS 2008 (Beta 2) complete, the next task was to formally adopt an automate build process, and we chose Team Build as the software to drive that process. Previously I had setup CC.Net, as I had used it at a prior job so I was familiar with out. However, there was never a buy in from the whole team, so no one except me really cared when the build broke, or how to go about fixing it.

As part of our migration plan, we have gotten buy in from the entire team (IS) on an automated build process, so for at least a the development and testing level we will have an automated process. The next step after that, is using Team Build to actually automate the deployment to our staging and production environments, such that we can easily deploy small, and large changes in an efficient, consistent, and error free manor.

One of the downsides to development, at least for me, is the task of deploying a change to production. There is usually a lengthy change management process, a number of documented (and un documented) steps needed to do the actual deployment, and then a series of manual tests to run to make sure everything is still working. At a presentation I attended as part of the ARCReady series, the concept of a truly automated build and deployment process was presented, and that concept is what I hope to accomplish (eventually) on my current project.

The first step in achieving my utopia, is to start with a simple build that can be invoked at anytime. I actually have another developer working on setting up the builds for our main project. The project I'm using for this example, is for our smart devices.

To get started, open Visual Studio and select New Build Definition from the Build Menu. This opens up a dialog box with 6 tabs/sections listed on the right, and the tab details on the left. The General, Project File and Build Defaults require information in order to proceed. Workspace, Retention Policy and Trigger all have defaults chosen, but you can change them if so desired. When you are done configuring all of the tabs, click OK.

• General:

Build definition name, an optional description, and a checkbox to enable or disable the build. I named the build "ProjectName - All", and entered a short description of what I hoped to accomplish with the build.

• Workspaces:

You need to select a Source Control Folder, and a Local folder. The defaults are the root of the project in TFS, and a folder defined as $(SourceDir)

• Project File:

Here you select the MSBuild file used to define the build. The default location is $/ProjectRoot/TeamBuildTypes/BuildDefinitionName. If there is no TFSBuild.proj file in the location, you will have the option to created one, which is what I did here.

Choosing to create a new TFSBuild file, bring up a new dialog that will allow you to select a solution in the workspace, 1+ configuration options (i.e. debug or release and target platform), and build options (unit tests, code analysis, etc). I happen to have a solution in this workspace, so I am using it, and chose to build both a debug and release version.

When you are finished with the TFSBuild options, click finsih to return to the Build Definition dialog

• Retention Policy:

Here you describe how builds should be retained, and the values you choose is completely dependent on your individual needs. For now, I'm selecting "Keep Latest Only" for Failed, Stopped and Partially Succeeded, and "Keep 5 Latest" for Succeeded.

•  Build Defaults:

You need to specify a default Build Agent (computer running Team Build), and a staging share. I was surprised to see that the Build agent we had already defined in another project, was not available in the drop down list. I recreated it by clicking the New button. I had to sepcifcy a Agent Name, computer name, and working directory (defaulted to $(Temp)\$BuildDefinitionPath)). If you don't want the source downloaded and built from C:\Documents and Settings\TFSServiceAccountName\Local Settings\Temp\Projectname\BuildName, change the working directory here.

Since the team working on this project is a little different, I've setup a different folder/share for this project so that I can assign appropriate share and NTFS rights.

• Trigger:

Finally, you can select when to build. Options include manual (check-ins do not trigger a new build), Build each check-in, Accumulate check-ins until the prior build finishes, build every week on the following days.

For requirements, I am choosing the manual build option.

You new build definition should show up under TFSServer\Proejct\Builds in Team Explorer. Right click on the build and choose Queue New Build. Here you can select the build definition (defaults to the build you right clicked on), Build Agent, drop folder for the build (defaults to the folder you chose under Build Defaults), a queue priority, and option MSBuild command line arguments.

My build started, and downloaded all of the source from the root of the Project, which is somewhat undesirable, as it's not all needed. Also, it would be better if the build kicked off from a specific project within the solution I had selected. However, I'm in a pretty good position right now, I just need to tweak some stuff. When the build fails, a new bug is created, and if you have email alerts setup, you will be notified.

Issues Resolved:

• Limit the amount of source downloaded (don't download the entire tree starting at $/Project

I solved this, at least for now, by going back into the build definition, and editing the workspace mapping. I change the default from $/Project -> $(Source) to $/Project/Folder -> $(Source)\Folder. Not only will this limit the amount of source downloaded, it is also used to

• Reference Paths

There is a section in the TFSBuild.csproj file for specifying reference paths. This is very useful when you have those developers who always add a reference in a nonstandard location and break the build. It is specified in an item group property, as a child of the root <Project> element. In my file, it was inserted at the end. I am going to try to insert this into a .targets file that I can reference from multiple build files.

<ItemGroup>
    <!--  ADDITIONAL REFERENCE PATH
     The list of additional reference paths to use while resolving references. For example:
     
         <AdditionalReferencePath Include="C:\MyFolder\" />
         <AdditionalReferencePath Include="C:\MyFolder2\" />
    -->
  </ItemGroup>

 

• Get a specific version (label)

I should have realized this earlier, but without an option in the Queue Build GUI, my need for building a specific version from a label drops significantly. I wanted QA to be able to build a version from a label, as defined by the dev team, such that the dev team could move on and start developing and checking in without impacting QA. The only "supported" way to get a specific version is to override the CoreGet task (see Ref #8), which means QA would have to check out and modify the TFSBuild.csproj file.

Open Issues:

• Select a specific project in a solution to build from.
• Current work around, is to create a new solution, or modify the solution I've been using to unselect some problem projects.

Miscellaneous:

• Read on Buck's blog that you have to have an interactive session running on the build server to do automated UI tests. He has instructions on how to do this. (See Ref #5)
• Extending the TFSBuild.csproj file. You can define reusable .targets files, which are just MSBuild files, and then import them into the TFSBuild.csproj file using <Import Project="Path\FileName.targets"/>
• You can add tasks based on TF Build targets in either the TFSBuild.csproj file, or your imported .targets. (See Ref #2)
• You can do incremental builds by setting the SkipClean property to true (See Ref #3).
• The .rsp file that is created with the TFSBuild.csproj file is a file that is used to pass command line arguments to MSBuild (See Ref #7).

References:

1. MSDN Documentation
2. Customizable Team Foundation Build Targets
3. How to: Customize the SolutionToBuild Item Group
4. Buck Hodges Blog
5. Buck's basic guide to Team Build 2008
6. Incremental Builds
7. MSBuild command line reference
8. Get a specific version