Wednesday, June 24, 2009

ClickOnce and Team Systems Summary

Had a new, simple ClickOnce App to add to Team Systems, so I'd thought it a good time to summarize what I've learned from previous posts.

1. Log into the build machine as the tfsbuild user.
2. Open the solution from source control in Visual Studio and publish. This sets up the ClickOnce publish key. This step can be circumvented with the use of MAGE or MAGEUI, but who wants to go through all that when this works.
3. Copy a Team Build project from a previous ClickOnce build project (or use some kind of template, or something).
- Set up your landing page
- If the ClickOnce project references a separate project within the solution, be sure to define both the SolutionToBuild and SolutionToPublish tags. (Otherwise, just the SolutionToPublish is needed).
- Define the Application Title, Support URL, Company, ClickOnceURL, and any other application and deployment-specific properties.
- Modify App.config settings in the AfterGet target override. Also, obtain Version definition in the AfterGet.
- In the AfterDropBuild target override, copy all files from the drop folder to the deployment folder(s).

This pretty much summarizes what works for me.

I promised to go through each tag to explain everything. I did stumple onto http://msdn.microsoft.com/en-us/magazine/dd458792.aspx today, which appears to be a terrific tutorial. I wish I had found it a few weeks (or even months) ago. Because of how good this link is, I'm going to supply only the Cliff Notes version.

In detail, the meaning of each tag in a Team Systems Build project:

<Project
Defines the project.
Attributes:
DefaultTargets - Ignored by Team Systems 2008. This is only used by MSBuild if run directly. Team Systems Build always uses only EndToEndIteration. This attribute defines which target MSBuild should use as its main entry point.

<Import
Specifies include projects files, which are used to define extension tasks.
Attributes:
Project - Defines the project file to import.

<RunCodeAnalysis
Defines whether or not the build will run Code Analysis.

<RunTest
<MetaDataFile
<TestList
Enables/disables the running of tests. Personally, I think this is a great feature to have, but unfortunately, it's often quite difficult to put together adequate tests in a system that integrates with user interaction and separate systems, such as the OpenVMS systems my shop uses.

<Message
Adds a message to the build log
Attributes:
Text - the message.

<ItemGroup

<PropertyGroup

<SolutionToBuild
Defines the solution file that should be compiled.

<SolutionToPublish
Defines the solution file that is to be published.

<ConfigurationToBuild
Defines whether the soution should be built for Debug or Release and for what kind of CPU.

<Target
Overridable point that MSBuild runs.
Attributes:
Name - the name of the target.

<UsingTask
Defines a custom task.
Attributes:
Assembly File - Defines the dll that includes the custom task.
TaskName - Defines the task name, which must be qualified with the full namespace.

<Custom tag
Any custom task defined in a DLL that is specified in a <UsingTask tag. I'll go into detail in a future post as to how to create your own custom tasks.

<Copy
Task to copy file(s)

<CreateProperty
Creates a property

<CreateItem
Creates an ItemList.


http://msdn.microsoft.com/en-us/magazine/dd150090.aspx is a good article on Team Build 2008. If you haven't already figured it out, I'm using Team Build 2008.

This pretty much covers all I care about.

TODO: detail about custom tasks.
TODO: supply nice template Build Projects--One for a ClickOnce application, and one for a web application. I've still got a bit of refining on my current project file in that my task to copy the files from the drop folder to the web cluster for final deployment copies too much and clutters things up (it doesn't really hurt anything, but it's really not right). So I've got to take a little to configure an "Exclude" attribute correctly. Once I've got that done, I should be able to set up a template file.

Russ

No comments:

Post a Comment