Build fail gated check-in TFS 2013

0
votes

I'm new to TFS and I'm having trouble setting up a gated check-in on TFS 2013. The solution I'm trying to check in builds correctly on my local machine (ie. there's nothing wrong with the code) but I can't get it to pass the gated check-in build for some reason. I've tried changing the working folders but I encounter the same errors every time I try checking in.

This error appears:

"C:\Builds\1\Shade\Gated check-in\src\Shade\Shade.2013.sln.metaproj: The project file "C:\Builds\1\Shade\Gated check-in\src\Shade\Credit.Common\trunk\Credit.Common\Credit.Common.csproj" was not found

My Working folders are as follows:

Source Control Folder: $/Credit.Common (Active) Build Agent Folder: $(SourceDir)\Credit.Common Source Control Folder: $/Credit.Common/Drops (Cloaked)
Source Control Folder: $/Shade (Active) Build Agent Folder: $(SourceDir)\Shade
Source Control Folder: $/Shade/Drops (Cloaked)

1
tfsvisual-studio-2013checkin
There's no way we could help you based only on the information you posted. If you think the problem is "gated check-in", then change the build definition to "manual" and try again. – John Saunders
I would recommend going into the build folder on the build tier and open the project there. You should be able to find the problem by doing that. From what you have said it sounds like a workspace issue. I don't believe this is realted to gated checkins. – Mike Cheel
What have you tried? Go to the build machine and attempt to compile there to see if everything is ok. Check if "C:\Builds\1\Shade\Gated check-in\src\Shade\Credit.Common\trunk\Credit.Common\Credit.Common.csproj" exists. – allen
What does your local workspace mapping look like? – Chris Patterson

1 Answers

0
votes

looks like your common.csproj is part of a solution, which is not part of the same workspace the solution is in. thus the path to the project within the .sln probably has a few ....\ in it. I'd suggest removing that common project from the solution, and building it separately. You can build multiple solutions/projects in the same build definition. If credit.common project is actually shared in multiple different clients, you might want to consider managing it's version separately anyway instead of building/compiling a new "common" dll every time a consumer of it builds.

just a suggestion.