Installed the TFS 2010 build service and when trying to start the tfsbuildservicehost I get the following errror (this is on a Windows Server 2008, patched and updated, and we are not using SQLite). This is happening twice for the build controller, the build agent and the build service.
TFSBuildServiceHost
Service 'MVC Build Agent' had an
exception: Exception Message: Problem
with loading custom assemblies: API
restriction: The assembly
'file:///C:\Users\Administrator\AppData\Local\Temp\BuildAgent\1\Utilities\Elmah\lib\x64\System.Data.SQLite.DLL'
has already loaded from a different
location. It cannot be loaded from a
new location within the same
appdomain. (type Exception)
I have had similar problem:)
Go to your controller definition in tfs and in build controller properties and set version control path to custom assemblies and add there location to your
"Elmah\lib\x64\System.Data.SQLite.DLL" from your tfs project.
in format of :
$/Elmah/lib
this should solve your problem
I don't know what the 'MVC Build Agent' is, but it's not a component of Team Foundation Server. Sounds like you have a custom assembly that's failing to load. Check the build controller properties to see where it's looking for its custom assemblies. You'll need to either (a) check-in the dependencies required by this custom assembly, or (b) change/remove the custom assembly path for the build controller so it no longer tries to load it.
Related
What do I do if I want one TFS 2012 build controller to have access to two versions of the same custom build process assembly (one for each of my branches)?
I have one build process template per branch, and one build definition per branch. Each branch has it's own custom build process assembly, but they all have the same assembly name and namespace (e.g. Company.Build.Activities.dll). (I realize I could make all of this go away by having different names for each branch's assembly, e.g. Company.Build.Activities.Dev.dll and Company.Build.Activities.Com.dll)
My build controller points to one location for "Version control path to custom assemblies" ($/Build/ForTFS). I tried putting the two assemblies under different subfolders, but the build process causes an error:
TF215097: An error occurred while initializing a build for build definition \Company\Dev_BuildDef:
Exception Message: Cannot set unknown member 'Company.Build.Activities.LastActivity.CustomFolderPath'. (type XamlObjectWriterException)
It seems that it's using the wrong copy of the assembly (CustomFolderPath is only defined in one assembly, not the other).
I think I could resolve this if I could specify the path or required assembly version in the template xaml, but I am not sure I can do that. I have read posts that suggest that you can add a reference to the specific assembly version in the Visual Studio project you are using to edit the template. But that didn't seem to work for me, and how would the build process definition know about that project's references... it only points to the template file itself, not the project.
Any suggestions? Am I approaching this wrong?
You cant have different assemblies loaded between different branches. You would need to run different controllers and use separate folders.
Steps:
Open build definition "test1" which points to build controller "controller1" on "builder1" machine, then click "Process" tab
Open build definition "test2" which points to build controller "controller2" on "builder2" machine, then click "Process" tab
Error is: Team Foundation Error Access to the path {path}is denied:
Noteworthy: I also get errors in output window, for example:
Summary: There were 0 failures, 6 errors and 0 warnings loading custom activities and services.
Error: Could not load file or assembly 'Microsoft.TeamFoundation.VersionControl.Client, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Error: API restriction: The assembly 'file:///C:\Users\{!REDACTED!}\AppData\Local\Temp\VSTFSBuild\df2044d9-c8bb-4666-9c93-513e149cd3e0\Microsoft.TeamFoundation.Build.Client.dll' has already loaded from a different location. It cannot be loaded from a new location within the same appdomain.
I have not proven the two errors are associated (I also get similar API restriction errors ANY time I load process parameters), however they could be.
The reason I have this two-controller setup is because controller1 uses a path to my custom activities ie $/Process/Dev and controller2 uses path $/Process/Production. It helps me test my changes in isolation.
So the question is: Is there something I am missing with regards to Microsoft's support for using more than one build controller (on separate machines) pointing to the same TFS instance?
Or, I'm open to different ideas on how to test my changes to my custom activities without forcing all of my builds to point to the changes.
I would suggest that your BuildTasks.dll is different in both locations. i would either update the dll to the latest version in whatever location is wrong or point both controllers to the same dll, you could also ensure that the dll has different version numbers if you want to maintain different source locations. Multiple controllers are supported and work well normally.
As a short term fix, clear cache between opening different build definitions so the 2 different dll's don't clash with each other
The reason I have this two-controller setup is because controller1
uses a path to my custom activities ie $/Process/Dev and controller2
uses path $/Process/Production. It helps me test my changes in
isolation.
it's not clear which machine your opening the Build Definitions on but I'll assume it's your development machine, I always place my buildtasks.dll in the public folder of Visual Studio when I'm developing.
When creating Custom Build Activities for TFS 2010/2012 it results in assembly (dll) files which can be used in build definitions.
When developing locally you place the assembly in the GAC or Visual Studio probing folder. For the build controller you place the assembly in source control (TFS) and tell the controller where to look.
All fine and working nicely.
The thing is that other developers (quite a lot) on other machines will need this assembly also when starting new builds. How do you deploy new versions of this assembly?
Assemblies are retrieved from TFS source control location defined for controller to tmp folder for Visual Studio and loaded into scope when opening build definition for edit (and probably when you open queue dialog).
You need assemblies in GAC (or VS private assemblies folder) if you are editing template itself, adding xaml template to activity project allows you to bypass GAC but will mess up namespace imports in xaml resulting in errors in tfs.
Another caveat is that if your activity assembly is using another library assembly this 2nd dll may not be picked up correctly - workaround is to add a fake empty activity to library.
I need some assistance with developing custom activities for TFS build. I have followed the steps in blog post Customize Team Build 2010 – Part 7: How is the custom assembly found?.
I have created a custom activity built into a DLL file and used in build template. I want to set it up in the TFS build now, but I have run into some issues. In the blog it suggests that the custom activities DLL file be referenced via the build controller. However, this is an issue for me. I work in a company where there are numerous projects and all use the same build controller. Therefore I don't have the permissions to make the change suggested in configuring the version control path to the custom activity.
Is there are another option open to me? Is there another way I can reference the custom activities? In the build template maybe?
You need to get that assembly onto the build server (build agent server assuming the activity is only used within the Run On Agent activity).
The most convenient option is to simply check it into the TFS folder that the build controller is pointing to for build assemblies, and the controller will automatically push it out to all build servers.
Alternatively, if you have direct access to the Build Agent Server(s) you can manually install the assembly onto the server into the GAC.
I have my custom continous build that log an error for my tfs service host.
Service 'Default Agent - basv-tfs-001' had an exception: Exception
Message: Problem with loading custom assemblies: API restriction: The
assembly
'file:///C:\Windows\ServiceProfiles\NetworkService\AppData\Local\ProjectBranchDevelopment\BuildAgent\2\ReportViewer.ProcessingObjectModel\Microsoft.ReportViewer.ProcessingObjectModel.dll'
has already loaded from a different location. It cannot be loaded from
a new location within the same appdomain. (type Exception)
I have found i have the same dll saved in 2 locations in my repository.
can i hide it from build?
Edit the workspace in your build definition. Add a reference to the folder containing one of the dll's and change "active" to "cloaked" that will stop TFS getting that folder during the build
I've seen this in tests where it's defaulted to using **test.dll (or similar), to get round this I changed it to just test.dll, since it was (as the error suggests) finding it in multiple locations.
So whatever is attempting to resolve your DLL is probably doing something similar. Not a solution I know by may help you track down the offending code :)