error MSB3202
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
[668 byte] By [
jdn] at [2007-12-22]
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
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.
jdn at 2007-8-30 >
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.
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.
jdn at 2007-8-30 >
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.
jdn at 2007-8-30 >
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
jdn at 2007-8-30 >
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
jdn at 2007-8-30 >
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
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
jdn at 2007-8-30 >
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
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
jdn at 2007-8-30 >
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.
jdn at 2007-8-30 >
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
jdn at 2007-8-30 >
