Reference Problem Building Visual Studio Solution from Subversion

Hi All.

I am fairly new with TeamCity, however, I am professional software developer and rather experienced with Visual Studio, C#, .NET, CLR etc. which makes this the problem described below even more strange, so far. The good thing is that computer/software problems normally have a logical solution and hope you guys can give me some insight to this. Alright, here it goes...

In the root of my E drive I have a folder in which my main workspace lives (E:\My Main). I am using Subversion and I have started using TeamCity a short while back. I have several build configurations up and running, but seem to have a problem with a specific configuration. My build folder (E:\My Builds) is sibling folder to my workspace in order to debug this issue. If I build this specific problematic build configuration it fails, and if I open the solution file (.sln) from within the build folder it also fails. The problem seen has to do with references to two of the referenced projects it seems. These projects are referenced dynamically from the application project, and there is nothing wrong with the references, however, when building through Visual Studio the application does not know the types in the two projects mentioned. To me this is really strange, since everything - as far as I can see - is as in my main workspace.

To summarize I have two apprarantly similar folders E:\My Builds and E:\My Main, one which is manually checked out, and one which is checked out through TeamCity and Subversion Folders in the two workspaces are on the same depth, however, the mentioned .sln builds in one, but not the other. So what does TeamCity or MSBuild change in the build folder which mess up the build?

Alright, say my main workspace has some dirty stuff in the folders, now I do a clean manual checkout to E:\My Workspace, and notice that this folder name is longer than the two others. I now open the solution file from within this new clean workspace and try to build the solution using Visual Studio, and it actually builds with no problems. Therefore, I assumed that the path lengths was not the problem, however, when I tried to move the two problematic projects to a shorter path, then it actually builded in all three folders. See this thread in which I was suggested this step...

http://youtrack.jetbrains.net/issue/TW-17569?query=commenter%3A+me

Moreover, I have other build configurations currently running on the TeamCity server, which references the same two projects, and these build configurations results in successful builds, so the context in which these two projects are build are also in play, I assume, and therefore not directly to do with path lengths.

I tried to view differences on the folders and project files but found no differences except from files named format in the subversion folder .svn, and then it seems like either TeamCity og MSBuild creates files named [solution file name].metaproj and [solution file name].metaproj.sln, and during build also two files named [solution file name].teamcity and [solution file name].teamcity.msbuild.tcargs. I tried to remove the metaproj files from the build folder, and then build using Visual Studio, but this did not seem to make any difference.

To me it is not not a solution to change the folder structure in order to make TeamCity work. This due to the fact that my repository is vast and organized with strict rules, but also due to the fact that the root cause of the problem is not found, which spanws instability in the setup.

I really appreciate any help or comments to this annoying and so far strange problem, thanks,

Jacob.

10 comments
Comment actions Permalink

Hello,

Thank  you for feedback!

Could you please check if TeamCity checkouts yout project with externals enabled ( if you use it). You may find the setting in Administraction | VCS Roots | name of your root | Externals support

As workaround, please try adding configuration parameter 'teamcity.msbuild.generateWrappingScript' with value 'false' and run build once again.

0
Comment actions Permalink

Hi Eugene.

Thank you for answering my somewhat long question/problem.

Unfortunately, none of the two suggestions provided any change. Regarding the first suggestion I selected "Full support (load changes and checkout)" but it did not change anything. Then I tried setting the  teamcity.msbuild.generateWrappingScript to false and builded again. The same errors as previous are still appearing, i.e. missing knowledge about classes that it should be able to know.

Best regards,

Jacob.

0
Comment actions Permalink

Hi.

Now I have managed to get the build working, however, personally I have not learned why yet.

First of all the folders mentioned in my original post are actually on the form...

E:\[my namespace/company name] Build

E:\[my namespace/company name] Main

E:\[my namespace/company name] Workspace

... but for simplicity I took out the namespace/company name. The original description still applies, however I tried to delete all contents in the "E:\[my namespace/company name] Build" folder, and checked it all out again manually to this folder. The problematic solution file was opened in Visual Studio 2010 and an attempt to build the solution was done. It did not build even though I checked it out manually. Then I changed the name on the folder to "E:\[my namespace/company name] Builds" and then did the same procedure. Well, oddly it actually builded. Then I tried to go back to the "E:\[my namespace/company name] Build"-name, and did it again. The setup was consistent and thus did not build again. This was all done manually with my Subversion client and Visual Studio 2010.

Alright, now I tried to change the Checkout directory in TeamCity to "E:\[my namespace/company name] Builds", and initiate the build which I have had problems with. After a few minuttes the build succeeded.

I would very much like to know why this is? There are no odd characters in the [my namespace/company name], it is just a seven letter acronym.

Best regards,

Jacob.

0
Comment actions Permalink

Hello,

You issues could be connected with full paths that are written inside your project files.
Could you please check if MSBuild.exe is able to build your solution from the same folder.

Do you run TeamCity builds under the same directory as your devep directory? If so, please conder to split TeamCity checkout directory and development directory.

One more thing to check it to make sure your solution builds with MSBuild from checkout without issues.

Hope this helps

0
Comment actions Permalink

Hi Eugene.

Nope, two different folders. My workspace is in "E:\[my company/namespace name] Main" and the folders I have tried to build in is either "E:\[my company/namespace name] Build", which does not work or "E:\[my company/namespace name] Builds", which work. So it is two different folders on the same drive.

As mentioned previously, the error is consistent in that if I use a folder named "E:\[my company/namespace name] Build", then I cannot build the specific solution, but in all other folders I have tried there is no problem. Actually, I tried to check-out the repository using my Subversion client to the folder "E:\Build", and then tried to build using Visual Studio 2010 again with a theory that it might be the "Build" word which was reserved or something like that, but surprisingly this worked aswell.

How do you suggest that I try to build using MSBuild? Command-line and which options? As far as I know Visual Studio uses MSBuild to do the building.

Actually, when I come to think about it the error can be reproduced completely without being in touch with TeamCity, so it cannot be TeamCity. I have tried in a more structure way to find out some kind of pattern in the folders which does not work and which works. The setup is manual check-out with Subversion client and build using Visual Studio 2010...

E:\Build              Works    

E:\Testaso Build      Fails

E:\Testaso Wooki      Fails

E:\Testaso Workspace  Works

E:\xxxxxxxxxxxx       Works (also tried using MSBuild from command-line)

E:\xxxxxxxxxxxxx      Fails (also tried using MSBuild from command-line)

E:\xxxxxxxxxxxxxx     Works (also tried using MSBuild from command-line)

... so from this I gather...

1. "Build" is not a reserved work in some way.

2. Spaces are not the problem.

3. Path lengths are not the problem.

4. I have not yet found any folder names with a length of 13 characters which works.

How strange is this?

Thanks, best regards,

Jacob.

0
Comment actions Permalink

Try the following commandline:
MSBuild.exe "<path to sln>\solution_file_name.sln" /t:Rebuild /p:Configuration=Release
in the checkout directory of the build configuration.

Does the build work?

Please send me build logs from commandline msubild and from TeamCity.

0
Comment actions Permalink

Hi Again.

Execution using MSBuild is completely consistent with building from within Visual Studio 2010 as expected. Please notice from my last post, that I can reproduce the error without being in touch with TeamCity. That is, TeamCity does not seem to be the problem. The problem seem to have something to do with a very specific path length, and possibly to do with MSBuild. I tried to measure the absolute lengths of the paths for the two problematic projects, which does not seem to be resolved in the solution, and they are about 150 characters long, so not near the limit of 256 character limit in MSBuild.

Best regards,

Jacob.

0
Comment actions Permalink

I found this...

http://social.msdn.microsoft.com/Forums/da-DK/msbuild/thread/f0eb6aed-5854-4678-9546-09c1a7705e30

... which I will investigate in more detail. It seems like my exact problem.

UPDATE: This is my exact problem. Adding the two path lengths as described gives me 259 characters for the two problematic projects, so I read that it is a bug int he Path.GetFullPath method. See more information here...

http://support.microsoft.com/kb/2516078

Thanks Eugene,

Jacob.

Message was edited by: Jacob Hansen

0
Comment actions Permalink

Thank you for details!

0

Please sign in to leave a comment.