error MSB3202

Question

I'm having trouble building a team build.  I am able to define a team build just fine, and when I try to run it, the log files seem to suggest that it can find the source files just fine.  But I end up with a lot of errors.

My solution uses Enterprise Library 2005, so here is one of the errors that reference it (so, I don't think it is custom code related):

error MSB3202: The project file "..\..\..\..\..\..\Program Files\Microsoft Enterprise Library January 2006\src\Data\Data.csproj" was not found

My team build has the file in its local source, the error occur when it tries to compile.

TIA.

jdn

Answer 1

Jdn

Build process is not able to find Data.csproj file under your build directory.

Can you verify if the following file is present under $(BuildLocation)\$(TeamProject)\$(BuildType)\Sources folder and the relative path of the data.csproj file is correct with respect to corresponding SLN file?

 Moreover can you try doing desktop build and see if the error repros?

Manish

Answer 2

No, the path isn't correct, but that's part of the point.  Why is it looking for something in program files?  That's the path on the local machine, but why would it keep that information when it is checked into VSTS?  It does this for every file, btw.

All of the sources are under the sources folder on the build machine as required.

What do you mean by a desktop build?  I can build the solution in Visual Studio 2005, if that's what you mean.

Answer 3

Answers

1) Team build does not make any modifications to your sln or csproj files. In team build the basic unit of build is sln (rather than csproj). In your case it looks like your sln has project to project references and the relative paths are not with respect to sln file. Can you change the relative path of data.csproj file? It should be relative to sln file.

2) Since you have all the sources, sln, csproj files on the build machine, your workspace is proper.

3) Yes, by desktop build, I mean, can you build the same solution under vs2005 without getting any errors. In your case since all the sources are present, things should work just fine. 

Hope it helps.

Answer 4

Well, I can try that, but it is massively inconvenient.

Enterprise Library is from Microsoft Patterns and Practices and has a normal default installation path, with already created solutions, unit test solutions, etc.  Are you saying the only way I can include them in the build is to manually copy the source files under my solution file location and recreate all the various solutions?

I guess I can understand why it is necessary, but still....I'll let you know how it goes.

Answer 5

HELP!!!!

To simplify things, I decided to ignore Enterprise Library for now.

I created a brand new solution and then created new projects underneath it, then imported in existing items.  All of this worked fine.  I can now do a build and it will build the class libraries in my solution.

My solution contains about 8 class libraries, and all of these have been added into VSTS just fine.  However, I also have about 5 web sites.  When I add these to the solution that is in source control, it doesn't add the web sites themselves. 

So, for instance, I add a local web site from IIS called Sandbox, which previously was in the old VSTS solution that was giving problems.  In the old VSTS solution, it was visible in Source Control Explorer, but it won't show up at all in the new VSTS solution.

How the heck do I get VSTS to see projects that I add to my solution?  I would think it would do it automatically, but it doesn't.

Answer 6

Related to this problem:

If I try to add the previously existing sites, I can load it into the solution but I get the following error:

TF10121: The path '' is not found or not supported. Type or select a different path.

I googled the error code, but all I got back was a Transformer action figure for sale.

jdn

Answer 7

 

jdn

Please have a look at the following post by anu -

http://blogs.msdn.com/anutthara/archive/2005/12/27/507525.aspx 

The post enumerates in the web projects issue. It also talks about the way to resolve it and how to get the web projects to build using team build.  

Regards

 

Answer 8

My application uses nested web sites, so I can't use file system projects.  But simply creating web site projects (using the updated code from Microsoft) running under IIS seemed to cause problems.  What I ended up doing was creating them as file system projects, which got them into Team System okay, and then converting them in the property pages to run under IIS to run them normally.

So, now I can build absolutely everything in my own projects, and everything in Enterprise Library, except for two Enterprise Library projects (which is where all this started).  I get the following two errors:

Project: Security.Configuration.Design.csproj, Compilation errors and warningsC:\WINNT\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets(3089,13): error MSB3073: The command "copy "d:\build\Code\Full-Debug\Code\Full-Debug\Sources\Utility\Enterprise Library\src\Security\Configuration\Design\Tests\*.config" "d:\build\Code\Full-Debug\Code\Full-Debug\Binaries\Debug\" > nul" exited with code 1.

Project: ExceptionHandling.Logging.Configuration.Design.csproj, Compilation errors and warningsC:\WINNT\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets(1616,9): error MSB3554: Cannot write to the output file "obj\Debug\Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.Configuration.Design.Properties.Resources.resources". The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters

The first error MAY be system related (permissions, in particular), but the second isn't something I can do much about.  So, what do I do?  I need VSTS to be able to build my solution (scheduled on a nightly basis, and then with CI, but I can't do either until I can get it to build properly once).

jdn

Answer 9

Wow, that's a long file name.  To deal with this, you'll need to shorten the path.  The message here doesn't show the full output path that it's trying to use.  You'll need to shorten whatever part of it you control.

Buck

Answer 10

Well, yes, that is one possibility.  Two points, however, leap to mind:

1) Enterprise Library is a 3rd party (in this case, Microsoft) product and I don't feel it is a good practice to start changing source code in a 3rd party product unless there is a good reason to.  Which leads to:

2) Visual Studio itself is perfectly able to compile this code.  Why can't Visual Studio Team System?  I can understand that environmental differences could make it possible for a local build to work and a team build to fail, but this sort of error (path length) is pretty much inexcusable.  What is the technical reason why it fails in the one case and not the other?

The more I work with it, the more that VSTS is an incredibly poorly designed piece of software.  It should NOT be this difficult to get a perfectly working solution to build.  Tie that with the lack of obvious functionality (out of the box scheduled builds, for instance), and it's pretty clear this thing is half-baked at best.

Any other ideas of how to fix the two remaining errors?

jdn

Answer 11

You'll need to choose a shorter path to use for the directory used by Team Build.  I don't know what path you are using, but the difference is that it is longer than the path used for the solution when you are using it in VS.

Buck

Answer 12

Why (besides "because" as an answer)?

Why does it work in Visual Studio and not in Team System (again, this is the Microsoft Enterprise Library code...I haven't done anything to it, other than to move the source code because VSTS can't handle it otherwise).

It is NOT LONGER than the path I use in VS.  It is the same path.  Or, at least, I haven't done anything to change it between VS and VSTS.   The code builds perfectly in Visual Studio 2005, but errors in VSTS.  I don't do ANY transformations between the two, at least not explicitly. 

jdn

Answer 13

Okay, so I went through the entire Enterprise Library and changed the namespace from "Microsoft.Practices.EnterpriseLibrary" to "MPEL" everywhere (including renaming the dll config files for the unit tests, renaming the outputted assembly name and default namespace, and everywhere in the source files).

This got rid of all errors except for the remaining one:

Project: Security.Configuration.Design.csproj, Compilation errors and warnings

C:\WINNT\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets(3089,13): error MSB3073: The command "copy "d:\build\Code\Full-Debug\Code\Full-Debug\Sources\Utility\Enterprise Library\src\Security\Configuration\Design\Tests\*.config" "d:\build\Code\Full-Debug\Code\Full-Debug\Binaries\Debug\" > nul" exited with code 1.

I have no idea what else to do or where this copy command comes from and I have no idea what this error is telling me. 

 

Answer 14

Resolved.

The project for that Enterprise Library has a directory in its path that is not included in the project itself (I have no idea why).  It has a post-build event that copies config files from that non-included directory to another.  Since the build server didn't know that directory existed (since it wasn't part of the checked-in project), it bombed on the post-build event.

Now, the fact that the team build took 30 minutes, when it takes 2 minutes locally is a problem, but I'll put that in another thread.

jdn

Answer 15

1) Why things work in VS IDe but not in team build?

 

Answer-

Note that team build creates/assumes a particular folder structure before starting the build. For example it will get the sources under a common root folder specified by property “SolutionRoot”. 

 

The folder structure created under team build is different from the one created under VS IDE environement. The rational is that your VS builds a single sln at a time but in teambuild you can build multiple slns.  

2) what to do when you encounter scenario like "Path" too long and you do not want to change the namespaces or names of your assemblies

Answer -

Override the SolutionRoot folder. It is possible in team build gets the sources and build the sources under a specific folder. You need to edit your tfsbuild.proj file and override the SolutionRoot and BinariesRoot property i.e. something like (where your specific folder is d:\temp) -  

<SolutionRoot Condition="'$(IsDesktopBuild)'!='true' ">d:\temp\Sources</SolutionRoot>

<BinariesRoot Condition="'$(IsDesktopBuild)'!='true' ">d:\temp\Binaries</BinariesRoot>

Now your path will be shorter because the length if SolutionRoot is less.

 

Answer 16

Thanks.  That's good information to know.

Answer 17

dear manish,

I understand your solution to make path short, tell me wat if

- my project path is still longer other then the solution/binary route?
- my local build folder contains more then one build output and i want to maintain some hierarchy in it?

regards
faraz

Answer 18

Okay, something about this doesn't make sense, in terms of point #1, and making projects relative to the solution file.

What if I have a common project or set of projects (utility projects, third party projects, etc.)?  To have to copy these to each solution is not only cumbersome, but bad practice.  I should be able to have the same project used by multiple solutions (as you can guess, I'm working in such a situation now).

How can I do this with team system?

jdn

Answer 19

 

Faraz

1) You have no choice except to shorten the names. I guess you will get the same problem when you will try building it in VS - IDE.

2) Please refer my blog post for the solution/workaround - http://blogs.msdn.com/manishagarwal/archive/2006/03/24/559693.aspx

Hope it solves your problem

 

 

Answer 20

 

By making sure in your build scripts (csproj files, sln files) that the paths are proper. Team build will not do any validation for the paths.

 

Answer 21

I don't understand your answer.

Suppose my solution has a path of d:\code\solution1

Inside that solution I have a lot of projects like:

d:\code\solution\1project1

d:\code\solution1\project2

I also have a project like:

d:code\common\project1

How do I reference d:\code\common\project1 in solution d:\code\solution1

 

Answer 22

 

JDN,

Please refer the following blog posts that enumerate more about project to project references in team build. It talks about the scenario you have mentioned above.

Note that the post also talks about working with multiple team projects (sources code exist on different team projects) but you can ignore the details since in your scenario everything is under same team project.

https://blogs.msdn.com/manishagarwal/archive/2005/09/26/473943.aspx

https://blogs.msdn.com/manishagarwal/archive/2005/09/27/474273.aspx

https://blogs.msdn.com/manishagarwal/archive/2005/09/28/474769.aspx

http://blogs.msdn.com/manishagarwal/archive/2005/12/22/506635.aspx

 

Hope it helps

Answer 23

I get the TF10121 error under the following circumstances:

1. Create a new project in the solution

2. Check whole solution in

3. Remove project from solution

4. Remove it from source control tree

5. Check in changes

6. Remove physical project folder

7. Add a new project in to the solution with the same name (and folder)

8. Check in

 

TF10121 occurs upon check in at stage 8. It's as if TFS keeps a record of the deleted folder name forever. So adding a new project to 'overwrite' one that was previously removed and deleted does not work. If you create the project with a slightly different name (and hence folder), it works fine.

Just thought that might help somebody...

Best wishes,

Sigol.

Answer 24

Line 3089 in Microsoft.Common.targets is the following:

<Exec WorkingDirectory="$(OutDir)" Command="$(PostBuildEvent)" />

So - this means that Security.Configuration.Design.csproj has a command-line associated with the PostBuildEvent that is, apparently, failing.  (The Pre- and PostBuildEvent command-lines associated with projects can be viewed in Visual Studio via Project -> Properties - see the Build Events tab)  My guess would be that the specified directory doesn't exist. 

Hope this helps point you in the right direction.

-Aaron

Answer 25

 

Ok I've been having possibly related, but different problems with TFS 2008 but here are some ideas that might be worth considering.

First of all if this 3rd party enterprise software is not being modified can't you compile the source locally and add the dlls to the bin folder of the projects that use it?

Some other things I've found is that team build will only have visibility of sourcecode that falls within the workspace defined for the build definition in question. I understand this can be checked in workspaces.xml in TFS 2005, but on TFS 2008 this is found in the TfsBuild database in the dbo.tbl_WorkspaceMapping table. Make sure the path defined is low enough to encapsulate all your source code including referenced projects.

The structure I had was as follows.

 

d:\
    Source\
               main\
                       solution1\
                                     S1project1
                                     S1project2
                       solution2\
                                     S2project1
                                     S1project1   <---This is a reference to project1 in solution1

 

The problem I had is that the build definition for building solution2.sln created a workspace of $source\main\solution2 and I was getting errors like the one below when trying to do team builds

C:\Temp\main\solution2\Sources\solution2.sln(0,0): error MSB3202: The project file "..\solution1\S1project1\S1project1.csproj" was not found.

I needed to modify the workspace for this build definition (there is mention of the workspace in the buildlog.txt as it calls it something like "BUILDSERVERNAME_12" where BUILDSERVERNAME is the name of the server you are running the team builds on, and 12 is the WorkspaceId) in the database from $source\main\solution2 to $source\main and therefore when the sourcecode is pulled down by teambuild it gets solution1 as well as solution2 files in the same workspace and the relative paths work as they are still contained within said workspace.

 

It's pretty obvious but I was unaware of it at the time, so hope this helps someone else.