I am trying to build a project within teamcity. It will do the checkout of TFS and the files are locally on the build server. If I manually run the build command on the server it works:
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\msbuild.exe C:\TeamCity\buildAgent\work\3446a5bd436eea87\Dev\Dev\project\myproj\myproj.csproj /t:build
Within Teamcity I have a Build step of MSBuild:
the build fie path is: Dev\Dev\project\myproj\myproj.csproj"
working directory left blank
mbuild version: microsoft .net framework 4.0
msbuild toolsversion: 4.0
run platform: X86
targets: I have tried build "build" and left blank
command line params left blank
if I create a command line build task and run the above command line it works. I am not sure what differences there are between the command line and msbuild task within teammcity.
EDIT
I have tried a few variations on the working directory:
The output path in project is set to ..\Build\Tools\myproj\
So I have set the working directory in teamcity to: Dev\Dev\project\Build\Tools\myproj\
This didn't help.
Here is the exact output from teamcity:
Starting: C:\TeamCity\buildAgent\plugins\dotnetPlugin\bin\JetBrains.BuildServer.MsBuildBootstrap.exe /workdir:C:\TeamCity\buildAgent\work\3446a5bd436eea87\Dev\Dev\project\Build\Tools\myproj /msbuildPath:C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
in directory: C:\TeamCity\buildAgent\work\3446a5bd436eea87\Dev\Dev\project\Build\Tools\myproj
Failed to start MSBuild.exe. Illegal characters in path.
System.ArgumentException: Illegal characters in path.
at System.IO.Path.CheckInvalidPathChars(String path)
at System.IO.Path.IsPathRooted(String path)
at JetBrains.TeamCity.Utils.FileUtil.MakeFullPath(String path, String workDir) in c:\BuildAgent\work\c2314fd21f15dc97\src\Utils\src\FileUtil.cs:line 48
at JetBrains.BuildServer.MSBuildBootstrap.RunArgs.get_ProjectFile() in c:\BuildAgent\work\c2314fd21f15dc97\src\MSBuildBootstrap\src\RunArgs.cs:line 156
at JetBrains.BuildServer.MSBuildBootstrap.Impl.MSBuildBootstrapFactory.Create(IClientRunArgs args) in c:\BuildAgent\work\c2314fd21f15dc97\src\MSBuildBootstrap.Core\src\Impl\MSBuildBootstrapFact ory.cs:line 29
at JetBrains.BuildServer.MSBuildBootstrap.Program.Run(String[] _args) in c:\BuildAgent\work\c2314fd21f15dc97\src\MSBuildBootstrap\src\Program.cs:line 67
Try editing the build configuration and remove the quotes from the Build file path option.
If you have:
"Dev\Dev\project\myproj\myproj.csproj"
Just let:
Dev\Dev\project\myproj\myproj.csproj
I hope this help.
In TeamCity, when you are using parameters for your path, or a portion of the path, it is easy to paste in a folder and not notice that it has a New Line or Carriage Return on the end (as I found from painful experience). It could show up in TeamCity as the value for a parameter:
\Folder1\NewlyPastedInFolder
\ExistingFolder\BuildScripts
What looks like a word-wrapped value is actually a parameter with a carriage return in the middle. Check it by editing it, and see if you can delete the character to make it into a single-line value.
This questions seems very similar:
What's the illegal character in this string ? I'm getting MSBUILD : error MSB3095
In addition to this question, take a look at:
What is a dll.refresh file in ASP.Net?
On this question, this answer is of interest:
In an ASP.NET project, adding a file-based reference will add a
.refresh file in the Bin folder. When the project is under source
control, this file is then added to source control. *.dll.refresh
files that litter the bin directory. Every time you add an external
reference, you'll find a dll.refresh file right next to it. These
dll.refresh files are an exception to the rule, and they should go
into source control. Its the only way your web project will know where
its references live.
If you don't have this in source control, it could explain the problem you are seeing. It sounds like the error message is potentially misleading and this is related to a reference not being resolved on the build machine.
With regards to why it works from the command line, is it possible that when you are building from TeamCity it is cleaning the output directory before building? If when you run from the command line binaries have already been output from the partially failed build which are referenced as file references, this would succeed.
To identify if this is the case - if you do a completely clean checkout and then run the MSBuild step from the command line, does it still succeed?
I ran into this error message from TeamCity and it turned out that a space in the solution file was causing it (the solution file referenced in the Visual Studio Build Steps had double quotes around it and that didn't seem to help.) Renamed the solution file without the space and that solved the problem.
Related
I have some cloud service projects , which i am trying to get it into CI/CD. When i right click on the project from Visual Studio and click Package it does what i want. I can see the ServiceConfiguration.cscfg and ServiceDefinition.csdef in the bin\Release folder after the package command is completed.
How can i achieve the same from an MSBuild command line ? I have tried
msbuild.exe
/p:DeployTarget=Package
/p:DeployOnBuild=true
/p:AutomatedBuild=True
/p:configuration=release
/p:outdir="D:\Pub"
/p:targetprofile="Cloud"
/target:Publish
/p:SolutionDir=$/src/mysln/ WorkerRole.ccproj
What i get is the command completes and i can see around 241 dll and the required files in the folder. Am i missing something in the command argument ? Please advice
Edit : Also refered the official docs , could'nt find anything
Edit 2 : Looks like i can get the packages generated. Now the problem is doing this in VSTS. The build is failing with " projectfile="*Undefined*Obfuscator\Maps\
Basically the solution path is becoming as undefined
Edit 3 : Here's the error message when i try to build only the CloudServiceProj
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(5165,5): Error MSB3073: The command "if "Release" == "Debug" goto :exit
"*Undefined*Obfuscator\Tool\CO" projectfile="*Undefined*Obfuscator\Maps
The undefined is working fine locally , since it has the $(SolutionDir) variable in VS. Not sure how do i handle it here
Update
Here's the msbuild that am using
Update 4
I tried building the solution directly as suggested, but it has some .NET CORE as well as .NET Framework projects and i am getting this error
C:\Program Files\dotnet\sdk\2.2.105\Sdks\Microsoft.NET.Sdk.Publish\build\netstandard1.0\Microsoft.NET.Sdk.Publish.targets(163,11): Error MSB4006: There is a circular dependency in the target dependency graph involving target "Publish"..
What i get is the command completes and i can see around 241 dll and the required files in the folder. Am i missing something in the command argument ?
For this question, you can try to change the argument /p:outdir="D:\Pub" to /p:PublishDir="D:\Pub". That because the argument outdir is used to stored the output files not the publish files, it contains the build output of the projects (including the reference project). That the reason why there are around 241 dll and the required files in the folder.
As I test, if I change the argument to PublishDir, it works fine:
For the second question, I am not familiar with Azure Cloud Service, as I know about MSBuild/Visual Studio, we should build the "main" project instead of the reference project, so you can try to build the AzureCloudService.ccproj or build the solution file .sln.
Besides, when we build the project/solution, we do not need specify the solution folder, just specify the project file or solution directly:
msbuild.exe "TheRelativePathForYourSolutionInRepos.sln" /t:Publish /p:DeployOnBuild=true /p:AutomatedBuild=True /p:configuration=release /p:TargetProfile=Cloud /p:PublishDir="D:\Pub"
If above not resolve your questions, please share your build error log in your question.
Update:
For the second part, I have a post build event which does some
obfuscation .
If you have use any Macros, like $(SolutionDir) in your build event, but build the project file, you will got that error. Because the project reference information exists in the solution information, we can't access it when we only build one project.
Try to replace all $(SolutionDir) with $(ProjectDir)..\
Update2:
Since you can build the .sln file on your local without any issue, you could also build the .sln file with Azure pipeline. As test, I could build the .sln file in the Azure pipeline:
Besides, if you have replace $(SolutionDir) with $(ProjectDir)..\, how do you still get the error Undefined? Try to double check you build event, or you can share it in the question.
Hope this helps.
So coming across a very strange issue with MSbuild using TFS 2015 build definition.
The web application I am trying to build has multiple csprojs that are used as class libraries throughout the application and of course my actual web application.
Bellow are the MSBuild arguments I am passing through currently to get a fully completed build.
/p:UseWPP_CopyWebApplication=True
/p:PipelineDependsOnBuild=False /p:OutDir=C:\Agent\_work\1\s\Application\Package\bin\
/p:WebProjectOutputDir=C:\Agent\_work\1\s\Application\Package\WebSite\
/p:NoWarn=0067
/v:Minimal
What I would actually like to do is the following.
/p:UseWPP_CopyWebApplication=True
/p:PipelineDependsOnBuild=False /p:OutDir=C:\Agent\_work\1\s\Application\Package\Website\bin\
/p:WebProjectOutputDir=C:\Agent\_work\1\s\Application\Package\WebSite\
/p:NoWarn=0067
/v:Minimal
The issue I run in to is after the first assemblies are run and placed in the bin folder it then works on the main webproject csproj and throws a unable to locate file for copy message.
I don't understand why this would be the case? Is it because MSBuild is expecting the bin folder to be empty/not there?
Am I missing something in the build order or different Argument needs to be passed. I have also to tried 'outpath' as well.
In the second arguments, the "OutDir" path is the same with "WebProjectOutputDir". This cause the issue since MSBuild will clean the "WebProjectOutputDir" folder before run "_WPPCopyWebApplication" task which copies files to "WebProjectOutputDir" folder. That means the files generated in "OutDir" during the build will be cleaned because it use the same path with "WebProjectOutputDir", so the task will cannot locate the files to copy.
To avoid this issue, you'd either change the "OutDir" different with "WebProjectOutputDir" or add one more arguments:
/p:CleanWebProjectOutputDir=False
When I run my TeamCity build with the only build step being of runner type Visual Studio (sln), I get the following error:
C:\TeamCity\buildAgent\work\4978ec6ee0ade5b4\Test\Code\Test.sln(2, 1): error MSB4025: The project file could not be loaded. Data at the root level is invalid. Line 2, position 1.
This is on a dedicated CI server running TeamCity Professional 8.1.1 (build 29939). There are several other successfully-running builds on this server.
The odd bit is that the same build runs successfully on TeamCity on my dev machine. I followed an answer to a similar question, and copied the specified folders across, but that didn't help.
I'm sure the project/solution file isn't invalid because in addition to the build running on my dev box, I have opened the solution in Visual Studio and built it there with no problems.
Any suggestions?
I just fixed this.
Look inside the Test.sln file for Project or EndProject tags that aren't closed. For us, the EndProject was missing and it broke on teamcity, but no issues in Visual Studio.
It seems the TeamCity error message will occur for any number of root causes. In my case the problem occurred because a line inside the GlobalSection(NestedProjects) section was referring to a project Guid which didn't relate to any project defined in the Solution file.
As with the previous post I didn't have any issues building in Visual Studio. I only got a more helpful error message that allowed me to discover what the real problem was when I built using msbuild.
See https://therightjoin.wordpress.com/2014/07/04/msb4025-the-project-file-could-not-be-loaded-data-at-the-root-level-is-invalid-error-when-building-ssdt-project-in-teamcity for another example, and where using msbuild helped identify the true problem.
In our case, it was a duplicate project reference in the solution file (caused by near simultaneous commits and an automatic merge).
In our situation the problem was specifying a ToolsVersion that was not installed on that machine. (14 which VS2015 has but VS2017 does not have by default)
In my case, after merging, in .sln file, it was a mismatch of lines under
GlobalSection(NestedProjects) = preSolution
{6B971E15-6B61-4AA8-9B93-9639C23269C3} = {9A14E7EF-3FA1-4B9A-B413-C550B3E5AC62}
{54D14F01-D576-4DE6-9404-D21AD0DC4916} = {9A14E7EF-3FA1-4B9A-B413-C550B3E5AC62}
... (was some extra entry here )
...
EndGlobalSection
section. In clear words, there were some extra lines added after merging. So, If you have merged, please compare two solution files manually. You can start with total line numbers in both files.
In another Case
We had a blank lines - so make sure any blank lines are removed!
Hope this helps some else too!
I got this same error with Jenkins. It turns out the root Jenkins folder was set to C:\Program Files (x86)\ and it didn't have write access to bin and obj directories.
Error:
error MSB4025: The project file could not be loaded. Data at the root level is invalid.
I launched cmd as Administrator and ran this:
"C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" "C:\Program Files (x86)\Jenkins\workspace\BuildBI_1\Reports\Test\ReportsTests.sln" /t:Build /p:RunOctoPack=true
And that gave me clues about not being able to write to bin and obj.
This worked for me-
You can install Build Tools for Visual Studio 2017, make sure to select C++ tools, Windows 10 SDK and MSBuild and your set.
Use MSBuild to identify the underlying problem:
$> msbuild mysolution.sln
Gave me this beauty with the correct error line number:
If msbuild cannot be accessed like that from the command line / powershell, try to find the MSBuild.exe shipped with VisualStudio, e.g. C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\amd64\MSBuild.exe.
VisualStudio itself seems to be very "tolerant" against errors / inconsistencies in the solution file, so having it open in VS is no guarantee for the sln file being correct.
I fixed it by updating the solution file.
Another possible problem (and resolution): I had a stray unused solution file in my repo, pointing to who-knows-where, and the MSBUILD step in my Azure DevOps pipeline was set to **\*.sln.
My MSBuild build script executes fine on all the development machines, but fails to run on the build server, except for the Trunk build. Branches all fail with the following warnings indicating the source of the problem:
Target "ResolveProjectReferences":
C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets (0,0):
warning : The referenced project '..\..\..\Class Library\
Company.BusinessModel\Company.BusinessModel.csproj' does not exist.
I can't understand why this error is even appearing - I have verified that (relative to the csproj being processed) the referenced project does exist. Copying (file copy) the checked out code to my local machine and running the script, the build completes as expected.
Is there anything obviously wrong here? Anything I can check to try and resolve this mystery?
EDIT:
I've tried running MSBuild against the project raising the build error in isolation, so it's not the rest of the solution which is the problem, just something about this specific .csproj file.
I actually found the problem. It's a bug in Visual Studio 2010 with path names totalling 259
http://support.microsoft.com/kb/2516078
Have you run msbuild in diag mode. That should give you some hints about the current path, and the relative path that MSBuild is trying to search.
msbuild myproj.msbuild /v:diag
I know that I can pass MSBuild a VS solution file (.sln) and it will build the solution but somewhere in the back of my mind, I remember using a MSBuild command line switch that would take a solution file (and it's referenced project files) and generate a single MSBuild project file from them. However, I now can't find this switch!
Was this all a dream?
I see the /preprocess switch (short form /pp) but I don't think that this was it as this will include all of the imported files (including Microsoft.*.targets) and besides I can't seem to get this switch to work. I when I try the following command line, MSbuild generates the *.out file but its empty!
msbuild /target:rebuild /generate MSBuildCopyTargets.sln
The easiest way to do this is to run MSBuild from the command line, with an environment variable set:
Set MSBuildEmitSolution=1
The output will be in the format SolutionName.metaproj