a trace of thought on...BizTalk Server, Team Foundation Server, Windows Mobile, etc. RSS 2.0
 Wednesday, February 27, 2008

Minor update to the BizTalk naming conventions here.  The big thing is that for a long while now I’ve thought physical send/receive ports should be named with just a plainly-worded phrase that will be as transparent as possible to operations staff.  (Whereas, back in the days of BizTalk 2004, you wanted something brief enough to fit in a HAT column…)

Wednesday, February 27, 2008 4:55:46 PM (Central Standard Time, UTC-06:00)  #    Comments [0] -
BizTalk Insights

Team Foundation Server 2008 provides the ability to specify a “remote” Sql Server Analysis server as well as a remote Sql Server Reporting server.  Normally, your Analysis Server is located with the data tier, and the Reporting Server is located on the application tier.  (Of course, everything can be collapsed on a single physical tier as well.)

However, by editing the “msiproperty.ini” file within the “AT” directory of your installation media, you can customize this.  The relevant keys are VSTF_RS_SERVER (reporting) and VSTF_AS_INSTANCE (analysis).  See the Team Foundation 2008 installation guide for details.

What you should know, however, is that apparently Reporting Server instances are not really supported.  If you attempt to specify an instance name in the VSTF_RS_SERVER property, the installation will fail.  This property needs to refer to a server name only.  TFS 2008 apparently expects the instance name to match the data tier instance name (a strange assumption.)  If that doesn’t work, it tries the default instance.  (After that, it will try the first instance it finds…so you might see “WARNING: Selecting the first instance name of…” in the installation log.)

According to this, you won’t see a change in this behavior with TFS 2008 SP1…

I have a few clients that would like to see TFS make use of an enterprise Reporting Services infrastructure (rather than spinning up a new reporting server…)  If you do as well, this is something to keep in mind.

Wednesday, February 27, 2008 10:13:10 AM (Central Standard Time, UTC-06:00)  #    Comments [2] -
Team System
 Thursday, February 21, 2008

Update: Slides from the talk we gave are available here.

I’ll be doing a talk with Geof Lory about Team Foundation Server and Application Lifecycle Management (ALM) at TechFuse this coming Tuesday (February 26th, 2008)…

Looks like a great event all in all for those in the Twin Cities!

TechFuse

Thursday, February 21, 2008 5:09:30 PM (Central Standard Time, UTC-06:00)  #    Comments [0] -
Team System
 Friday, February 15, 2008

So, I should have moved the BizTalk Deployment Framework to CodePlex long ago, but better late than never.  Find it here.

A few small items:

  • Better support for 64 bit platforms in scripting operations
  • Support for using the 64 bit isapi extension for http adapter
  • A "startApplicationOnDeploy" property you can use to control whether your application immediately starts after deploying
  • Bug fixes for the lightweight "Update Orchs/Comps" tool menu item
  • Automatic creation of "ProjectPath" sso config item – that lets you know where your developer workspace or server installation directory resides.
  • Better support for pre-processing bindings on developer workstations

But the cool item is integration of Tom Abraham’s improved “SettingsFileGenerator” – see here.  It moves the process of generating individual environment setting files from a VB macro inside of the SettingsFileGenerator.xls spreadsheet to an external command-line tool.

It also allows you to use the Excel XML format for the SettingsFileGenerator spreadsheet.  The Excel XML format allows for the ability to do standard diff/merge activities, a big improvement…

The way we’ve intergated this tool into the deployment framework allows you to treat the individual settings files as "transient" - they will get auto-generated by the deployment process now on the fly, and do not need to be version controlled or manually generated after spreadsheet edits. 

Enjoy!

Friday, February 15, 2008 4:40:24 PM (Central Standard Time, UTC-06:00)  #    Comments [0] -
Deployment Framework
 Thursday, February 14, 2008

TFS Deployer is a great tool that allows you to automate application deployments.  It does so by acting as a service that listens for “Build Quality” change events dispatched by TFS – and then kicking off a PowerShell script that is appropriate for the server and the build type.

I’ve had very good luck making use of TFS Deployer with a few clients to facilitate unattended deployments of BizTalk applications.  I’ll have more to say about the “BizTalk” piece of that in coming months, in collaboration with my good colleague Dave Comfort.  Suffice to say that if you’re using the Deployment Framework – but would like a one-click solution for deploying to multi-server environments, you will want to watch this space.

In the mean time, if you are making use of TFS Deployer already, you might find it helpful to share some slightly more formal documentation with your operations staff, etc.  You can certainly glean what you need to from here and here, but I believe you’ll find this consolidated resource a help.

(p.s. – keep an eye on the future of the TFS Deployer project here.)

Thursday, February 14, 2008 10:02:55 AM (Central Standard Time, UTC-06:00)  #    Comments [0] -
Team System
 Wednesday, February 13, 2008

“Error creating UDDI entries... Error 285023” – are you getting this while attempting to get the ESB Guidance up and running? 

If your event log has an entry containing “UDDI_ERROR_AUTHTOKENREQUIRED_NOTOKENPUBLISHATTEMPT” chances are you have anonymous authentication enabled for your UDDI virtual directory.  Turn it off, and try again.  If this isn’t the issue (or you are having other UDDI issues while installing the ESB Guidance) try cranking up logging to “verbose” for the UDDI service itself.  (See Administrative tools, UDDI Services, properties on your machine.)  There is generally enough context in there to troubleshoot…

 

Wednesday, February 13, 2008 9:42:33 AM (Central Standard Time, UTC-06:00)  #    Comments [0] -
General
 Friday, January 25, 2008

I’ve had a few folks ask recently about the presentation I did for MDC 2007 on release management and branching strategies with Team Foundation Server.  The PDF was available on the conference site, but not the PowerPoint, so here it is.

Friday, January 25, 2008 11:13:48 AM (Central Standard Time, UTC-06:00)  #    Comments [0] -
Team System
 Wednesday, January 16, 2008

1/9/2009: I recently updated this tool to delegate the work to "tfpt.exe" (the TFS power tool) when obtaining individual changesets.  This works much better in conjunction with rename/delete activity.

I was working with a shop recently that wanted to be able to do very fine-grained deployments (of a web application) into production.  They were pretty far into their Team Foundation Server adoption, and wanted to be able to deploy the files contained in the changeset(s) that were tied to a particular work item. 

So, for instance, to close a particular bug work item, three changesets might be checked in (each associated with that work item.)  Each of these changesets might comprise multiple files.  When preparing to stage the fix, the client wanted to simply say “go get work item 1237” and have the right thing happen (i.e. all files retrieved, preserving folder structure) – even without a workspace defined.

They were happy to let me share the solution with you, so you can download it here.  You’ll have to build it yourself, pointing at the correct TFS assemblies.

It is a command line utility – the command line help is as follows:

GetCSForWI v1.0.0.0
Copyright 2007

Retrieves files associated with changesets or changesets
that have been associated with a particular work item.

Usage: GetCSForWI.exe [@argfile] <tfsServer> [/changeset:<changesetNumber>]
       [/workitem:<workitemNumber>] [/path:<localFolder>] [/help|?|h] [/version|v]


@argfile                      Read arguments from a file.
tfsServer                     TFS Server name
/changeset <changesetNumber>  Changeset number to retrieve
/workitem <workitemNumber>    Workitem number to retrieve changesets for
/path <localFolder>           Local folder to copy to (after getting to
                              workspace)
/help                         Show usage.
/version                      Show version.

Wednesday, January 16, 2008 12:57:43 PM (Central Standard Time, UTC-06:00)  #    Comments [1] -
Team System
 Thursday, January 10, 2008

A few folks have discussed the topic of building BizTalk solutions with TFS, namely here and here.  As most have surmised in the time since TFS originally shipped, you have to build BizTalk solutions with “devenv.exe” if you are going to use Team Build, by overriding the “AfterCompile” target.  This is because there is no “standalone” xlang compiler (at least not that you & I can use) – it instead loads in-process to the IDE.

Your steps will be something like the following:

  • Do a “developer tools only” install of BizTalk on your build server.  No need to install the BizTalk services or databases, etc. (unless you intend to deploy & run post-deployment tests on the build machine.)  Note that since you need to install Team System Dev or Test to run post-build unit tests anyway, you aren’t really installing that many more “bits” on your build server (if you are skipping the BizTalk runtime/database infrastructure.)
  • Comment out the line in your TFSBuild.proj file that looks like this: <SolutionToBuild Include="$(SolutionRoot)\path\MySolution.sln" />
  • Create an AfterCompile target that looks something like this:
  <Target Name="AfterCompile">
 
  <!--Call DevEnv to build the BizTalk Solution-->
  <Exec Command="&quot;C:\%programfiles%\Microsoft Visual Studio 8\Common7\IDE\devenv&quot; &quot;$(SolutionRoot)\BizTalk\Dev\MyBizTalk.sln&quot; /Build &quot;$(BuildFlavor)|$(BuildPlatform)&quot;"/>

  <!-- Create a drop location -- >
  <MakeDir
   Directories="$(DropLocation)\$(BuildNumber)\$(BuildFlavor)"
   Condition="!Exists('$(BinariesRoot)\$(BuildFlavor)')" />

    <!-- Do whatever work you would like here - assemble binaries, build an MSI via WiX, etc. and
         place the outputs in the drop location. -->

 </Target>

What isn’t immediately obvious is that if you want to execute unit tests as part of your build process (i.e. tests that don’t require your BizTalk solution to be deployed…think build verification) then the DevEnv method of building can cause you trouble.  The testing portion of the build process expects your binaries to land in the “Binaries” folder — a peer of Sources, BuildType, and TestResults in your build location.

Therefore…you will want to add something like this at the end of your AfterCompile target:

    <!-- Get our build outputs into the "binaries" folder to facilitate unit testing. -->
    <MakeDir Directories="$(OutDir)"/>
    <CreateItem Include="$(SolutionRoot)\**\*.dll" >
      <Output ItemName="FilesToCopy" TaskParameter="Include" />
    </CreateItem>
    <Copy
          SourceFiles="@(FilesToCopy)"
          DestinationFolder="$(OutDir)"
          ContinueOnError="true" />

 

With this in place, the unit testing portion of the build process can execute as if you hadn’t resorted to calling devenv.exe…

Update: Are you getting an error like this: “The specified configuration and platform ('Debug/Any CPU') is not defined.” — right at the point that test results are supposed to be published?  I don’t entirely understand this, except to say that something in the core TFS targets is apparently responsible for populating the Platform_Flavors table in the TfsBuild database.  This step might not happen if you take over compiling by calling devenv.exe.  Take a look in that table to see if the platform/flavor you are trying to use is listed there…

Thursday, January 10, 2008 3:07:02 PM (Central Standard Time, UTC-06:00)  #    Comments [3] -
BizTalk Insights | Team System
Archive
<February 2008>
SunMonTueWedThuFriSat
272829303112
3456789
10111213141516
17181920212223
2425262728291
2345678
About the author:

Scott Colestock lives, writes, and works as an independent consultant in the Twin Cities (Minneapolis, Minnesota) area.

© Copyright 2009
Scott Colestock
Sign In
All Content © 2009, Scott Colestock
DasBlog theme 'Business' created by Christoph De Baene (delarou)