Using TFS Build Extensions 2010 Azure in TFS Build Process Templates

Question

I'm attempting to use the community TFS Build Extensions Azure activities to deploy to Azure as part of a TFS Build.

I've added activities from TfsBuildExtensions.Activities.dll and TfsBuildExtensions.Activities.Azure.dll and I'm able to any activity from TfsBuildExtensions onto my build process and they work properly

The problems start when I drag an activity from TfsBuildExtensions-Azure. The activity's title in the Gui display remains blank except for the generic activity icon. The properties pane shows that the properties for this activity cannot be edited. Finally, upon saving this build process template, it fails with the following error:

System.IO.FileNotFoundException: Could not load file or assembly 'ServiceManagement, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
File name: 'ServiceManagement, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
   at System.Signature.GetSignature(SignatureStruct& signature, Void* pCorSig, Int32 cCorSig, RuntimeFieldHandleInternal fieldHandle, IRuntimeMethodInfo methodHandle, RuntimeType declaringType)
   at System.Signature..ctor(IRuntimeMethodInfo methodHandle, RuntimeType declaringType)

What am I doing wrong or what reference am I missing?

Answer 1

I downloaded the source of the project and found that there is a reference to a ServiceManagement.dll in the project file, and the dll can be found in their source control.

Downloading the dll from their source, and adding it to the project references has resolved the issue.

I found a reference on MSDN Blogs to a ServiceManagement.dll that revolves around deployment to azure, but it seems the original sources for the dll have disappeared.

Answer 2

Idea- confirm that you are using .NET 4.0 Framework target and not .NET 4.0 Client Profile. Sometimes the latter causes seemingly 'obvious' assemblies to fail to load because they have dependencies that are not in client profile.

Not a solution per se, but for another way of going about debugging, you might want to turn on fusion logging and use Fusion Log Viewer to view assembly binding errors. At least that will tell you where the runtime is looking for these assemblies that it isn't finding.

Here are some clear instructions from Scott Hanselman on how to do this: http://www.hanselman.com/blog/BackToBasicsUsingFusionLogViewerToDebugObscureLoaderErrors.aspx