In the series the following parts have been published
- Part 1: Introduction
- Part 2: Add arguments and variables
- Part 3: Use more complex arguments
- Part 4: Create your own activity
- Part 5: Increase AssemblyVersion
- Part 6: Use custom type for an argument
- Part 7: How is the custom assembly found
- Part 8: Send information to the build log
- Part 9: Impersonate activities (run under other credentials)
- Part 10: Include Version Number in the Build Number
- Part 11: Speed up opening my build process template
- Part 12: How to debug my custom activities
- Part 13: Get control over the Build Output
- Part 14: Execute a PowerShell script
- Part 15: Fail a build based on the exit code of a console application
- Part 16: Specify the relative reference path
The solution that is created in the parts 4 till 6 uses an assembly that contains the custom activities, the custom types and the custom editors. When another person edits a build definition based on the modified Build Process Template, that person was able to use the custom types and editors. I wondered how Visual Studio was able to find the correct assembly.
I figured out that it looks in the following locations
- The “version control path to custom assemblies” that is specified in the build controller the build uses
- The GAC
- The Visual Studio probing path
If the assembly can still not be found, try to reopen Visual Studio. This will ensure that the assembly is reloaded.
Version control path to custom assemblies
When you edit the build definition, you specify the controller you want to use.
In this build controller, you can set the Version Control path that contains the assemblies that are used by the Build Process Template. You can see the information of the build controller by right clicking on the Builds node in the Team Explorer window. Select then Manage Build Controllers.
A dialog pops up with all the build controllers and its agents
Select the controller you use in the build definition, and click on Properties
Over here you can specify the path where the assemblies live in Source Control you want to use when someone Edits a build definition.
The Visual Studio probing path (or GAC)
If you don’t want to specify the assembly via the Version Control path in the build controller, you can also make it available by installing it in the GAC or in one of the Visual Studio probing path.
You can find the probing paths of Visual Studio by editing the devenv.exe.config file. You can find this file at C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE (or C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE for 32 bits machines)
By default this config contains the following directories (relative to the C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE directory):
- PublicAssemblies
- PrivateAssemblies
- CommonExtensions\Microsoft\TemplateProviders
- PrivateAssemblies\DataCollectors
- PrivateAssemblies\DataCollectors\x86
- CommonExtensions\Microsoft\Editor
- CommonExtensions\Platform\Debugger
UPDATE 31-8-2010: Thanks to venkateswar who provided the following solution for a common problem in http://social.msdn.microsoft.com/Forums/en-US/tfsbuild/thread/2b24609d-fc8f-4908-bdc5-6986d5e53ecc/
"TF21509:An error occured while initializing a build definition \CustomBuildTasks\BuildName:Cannot create
unknown type '{clr-namepace:NamespaceName,asembly=AssemblyName}Activityname'."
You can solve this by adding the attribute [BuildActivity(HostEnvironmentOption.All)] at class level.
[BuildActivity(HostEnvironmentOption.All)]
public sealed class CustomActivity : CodeActivity
See more info on this at http://www.ewaldhofman.nl/post/2010/04/29/Customize-Team-Build-2010-e28093-Part-4-Create-your-own-activity.aspx (step 10)
UPDATE 30-9-2010: Thanks to Sven Hubert who was so kind to share his solution.
If your custom assembly uses a dependent assembly (reference) which is needed to run activities, they will not get deployed properly. If this is the case you will get “unknown type” errors on build definition initialization.
To work around this issue, add a fake CodeActivity to your dependent assembly with the following class scoped attribute:
[Microsoft.TeamFoundation.Build.Client.BuildActivity(Microsoft.TeamFoundation.Build.Client.HostEnvironmentOption.All)]
Public sealed class FakeActivity : CodeActivity
You can download the full solution at BuildProcess.zip. It will include the sources of every part and will continue to evolve.
Subscribe