The project file could not be loaded. Root element is missing - visual-studio

I am trying to build a dotnet 3.5 project solution file with VS Build tools 2017 in Jenkins. The project is compiling well with DotNet 3.5's MSBuild, but when I try the same activity with MSBuild Engine Version 15.9.21+g9802d43bc3, it is throwing MSBUILD : error MSB4025: The project file could not be loaded. Root element is missing.
This is the command which I have used to compile dotnet 3.5 project.
cd "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin"
MSBuild.exe "%WORKSPACE%\WBR.sln" /p:Configuration=Debug /p:DeployOnBuild=True /p:AllowUntrustedCertificate=True /p:CreatePackageOnPublish=True
Please find below Jenkins execution logs
C:\Users\Netadmin\.jenkins\jobs\FCRS\jobs\FCRS_VS\workspace>cd "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin"
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin>MSBuild.exe "C:\Users\Netadmin\.jenkins\jobs\FCRS\jobs\FCRS_VS\workspace\WBR.sln" /p:Configuration=Debug /p:DeployOnBuild=True /p:AllowUntrustedCertificate=True /p:CreatePackageOnPublish=True
Microsoft (R) Build Engine version 15.9.21+g9802d43bc3 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.
Build started 8/19/2019 6:38:12 PM.
MSBUILD : error MSB4025: The project file could not be loaded. Root element is missing.
Build FAILED.
MSBUILD : error MSB4025: The project file could not be loaded. Root element is missing.
0 Warning(s)
1 Error(s)
The below pic is my jenkins workspace directory.
Any help would be great.

When you use command msbuild xx.sln, you are actually build the projects belonging to the solution.
According to your error message: One of the project's project file (xx.csproj) is not loaded cause the msbuild can't read the xml content well. You can try:
1.Open the xx.csproj file and make sure its format is:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
...
</Project>
2.Save it with UTF-8 encoding to avoid BOM be messed up
3.Backup and then delete the .suo and .csproj.user files
4.Otherwise, since it's a asp.net mvc project, you can create a same-name asp.net mvc project by vs2017, copy all the source files to the new project to migrate the project to VS2017
5.Make sure your build tools package install the web development workload:
6.Since it works well when using msbuild from .net3.5, you can install the .net framework 3.5 in your server and try calling the msbuild from C:\Windows\Microsoft.NET\Framework64\v3.5 instead of C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin when building .net 3.5 projects from vs2010.

Related

How to set PlatformToolset property from MSbuild?

We are experiencing AppVeyor x64 build failures, and trying a suggestion to set PlatformToolset to DefaultPlatformToolset. The property value is undocumented, so we want to thoroughly test it.
We wired DefaultPlatformToolset into our AppVeyor configuration file:
test_script:
- cmd: >-
msbuild /t:Build /p:PlatformToolset=DefaultPlatformToolset cryptlib.vcxproj
msbuild /t:Build /p:PlatformToolset=DefaultPlatformToolset cryptest.vcxproj
msbuild /t:CopyCryptestToRoot /p:PlatformToolset=DefaultPlatformToolset cryptest.vcxproj
cryptest.exe v
cryptest.exe tv all
The value DefaultPlatformToolset is causing AppVeyor failures. Here's from the log where we believe everything is correct: Build 1.0.129:
msbuild /t:Build /p:PlatformToolset=DefaultPlatformToolset cryptlib.vcxproj
Microsoft (R) Build Engine version 14.0.25420.1
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 8/2/2017 5:14:24 AM.
The target "_ConvertPdbFiles" listed in a BeforeTargets attribute at "C:\Program Files (x86)\MSBuild\14.0\Microsoft.Common.targets\ImportAfter\Xamarin.Common.targets (45,37)" does not exist in the project, and will be ignored.
The target "_CollectPdbFiles" listed in an AfterTargets attribute at "C:\Program Files (x86)\MSBuild\14.0\Microsoft.Common.targets\ImportAfter\Xamarin.Common.targets (45,70)" does not exist in the project, and will be ignored.
The target "_CollectMdbFiles" listed in a BeforeTargets attribute at "C:\Program Files (x86)\MSBuild\14.0\Microsoft.Common.targets\ImportAfter\Xamarin.Common.targets (52,38)" does not exist in the project, and will be ignored.
The target "_CopyMdbFiles" listed in an AfterTargets attribute at "C:\Program Files (x86)\MSBuild\14.0\Microsoft.Common.targets\ImportAfter\Xamarin.Common.targets (52,71)" does not exist in the project, and will be ignored.
Project "C:\projects\cryptopp\cryptlib.vcxproj" on node 1 (Build target(s)).
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Cpp.Platform.targets(57,5): error MSB8020: The build tools for DefaultPlatformToolset (Platform Toolset = 'DefaultPlatformToolset') cannot be found. To build using the DefaultPlatformToolset build tools, please install DefaultPlatformToolset build tools. Alternatively, you may upgrade to the current Visual Studio tools by selecting the Project menu or right-click the solution, and then selecting "Retarget solution". [C:\projects\cryptopp\cryptlib.vcxproj]
Done Building Project "C:\projects\cryptopp\cryptlib.vcxproj" (Build target(s)) -- FAILED.
Build FAILED.
How do we set PlatformToolset on the command line when using MSbuild to build the project?
None of these work. They produce similar errors as above.
> msbuild /t:Build /p:PlatformToolset=DefaultPlatformToolset cryptlib.vcxproj
> msbuild /t:Build /p:PlatformToolset=$(DefaultPlatformToolset) cryptlib.vcxproj
> msbuild /t:Build /p:PlatformToolset="$(DefaultPlatformToolset)" cryptlib.vcxproj
> msbuild /t:Build /p:PlatformToolset='$(DefaultPlatformToolset)' cryptlib.vcxproj
Here's another error when trying to do that silly MS XML quoting:
>msbuild /t:Build /p:PlatformToolset="$(DefaultPlatformToolset)" cryptlib.vcxproj
Microsoft (R) Build Engine version 4.6.1087.0
[Microsoft .NET Framework, version 4.0.30319.42000]
Copyright (C) Microsoft Corporation. All rights reserved.
MSBUILD : error MSB1011: Specify which project or solution file to use because t
his folder contains more than one project or solution file.
'#34' is not recognized as an internal or external command,
operable program or batch file.
'#34' is not recognized as an internal or external command,
operable program or batch file.
And then there's this one:
> msbuild /t:Build /p:PlatformToolset=""$(DefaultPlatformToolset)"" cryptlib.vcxproj
Microsoft (R) Build Engine version 4.6.1087.0
[Microsoft .NET Framework, version 4.0.30319.42000]
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 8/2/2017 2:19:15 AM.
Project "c:\Users\Test\cryptlib.vcxproj" on node 1 (Build target(s)).
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.Cpp.Platform.p
rops(15,24): error MSB4115: The "exists" function only accepts a scalar value,
but its argument "$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\$(Pla
tformToolset)\Microsoft.Cpp.$(Platform).$(PlatformToolset).props" evaluates to
"C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\\Platforms\x64\Platform
Toolsets\"$(DefaultPlatformToolset)"\Microsoft.Cpp.x64."$(DefaultPl
atformToolset)".props" which is not a scalar value.
Regarding the error message's suggestion ... or right-click the solution, and then selecting "Retarget solution", we can't. This is remote, command line only. We are trying to figure out how to run VCUpgrade from the command line at How to run VCUpgrade before Appveyor build?
DefaultPlatformToolset is an MSBuild property which gets set in one of the platform .props files imported by the main project. At one point in a C++ project file there should be the line
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
which for instance for VS2017 ends up importing <msbuild installation>\Microsoft.Cpp\v4.0\V140\Microsoft.Cpp.Default.props in turn, which sets the property using
<DefaultPlatformToolset>v140</DefaultPlatformToolset>
Since this is an msbuild property it is not known by Appveyor nor by cmd and as such you cannot reference it directly from within appveyor.yml. And even if it were known, you cannot refer to it using $(DefaultPlatformToolset) which is msbuild property expansion syntax whereas cmd's is of the form %ABC%. The errors you get are all because the PlatformToolset property gets set to e.g. the string 'DefaultPlatformToolset' whereas it needs to be set to the name of an actual available platform like v110 or v140 or v120_xp or ...
If you want to use DefaultPlatformToolset the easiest way is entering it in the project file. It can still be overriden from the commandline if needed. The alternative would be running msbuild and have it print it's value, then pass that using /p:PlatformToolset=. But that's not so nice for local development builds in Visual Studio.
For changing the project file, find the section(s) where the PlatformToolset is defined and change it to $(DefaultPlatformToolset) - this should come after the Microsoft.Cpp.Default.props import else the property might not yet be defined. To guard against the case where you're building for a platform which for some reason does not define DefaultPlatformToolset (something custom, or possibly old VS versions) set it to a sensible default first, before the Microsoft.Cpp.Default.props. Example:
<PropertyGroup Label="Globals">
<PlatformToolset>v100</PlatformToolset>
</PropertyGroup>
....
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
....
<PropertyGroup>
<PlatformToolset>$(DefaultPlatformToolset)</PlatformToolset>
</PropertyGroup>
Here's another way to do it:
<!-- Use DefaultPlatformToolset after Microsoft.Cpp.Default.props -->
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
<!-- Set DefaultPlatformToolset to v100 (VS2010) if not defined -->
<PropertyGroup Label="EmptyDefaultPlatformToolset">
<DefaultPlatformToolset Condition=" '$(DefaultPlatformToolset)' == '' ">v100</DefaultPlatformToolset>
</PropertyGroup>
<PropertyGroup Label="PlatformToolset">
<PlatformToolset>$(DefaultPlatformToolset)</PlatformToolset>
</PropertyGroup>
It is also very important to ensure the Global property group elements are set before Microsoft.Cpp.Default.props is imported. If they are not set, then MSbuild assumes an Application is being built, and it ignores the ConfigurationType that comes later:
<PropertyGroup Label="Globals">
<ProjectGuid>{016d3861-ccd6-4a50-83b4-fe4e93bea333}</ProjectGuid>
<RootNamespace>mylib</RootNamespace>
<ConfigurationType>StaticLibrary</ConfigurationType>
</PropertyGroup>
...
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
...
<PropertyGroup>
<PlatformToolset>$(DefaultPlatformToolset)</PlatformToolset>
</PropertyGroup>

MSBuild 2015 fails packaging web app from VS2010

I have a build server that until recently had up to .Net 4.5.1 and VS2010/VS2012 installed. I ran MSBuild to build and package web apps as follows:
"C:\Program Files (x86)\MSBuild\12.0\Bin\MSBuild.exe" Hartford.Pace.sln /nologo /v:n /p:Configuration=Release /p:DeployOnBuild=True /p:CreatePackageOnPublish=True /p:AutoParameterizationWebConfigConnectionStrings=False /p:EnableNuGetPackageRestore=True
I recently updated the build server to include Frameworks through 4.6.1 and VS2013/VS2015. Everything was installed in sequence. I updated the build command to:
"C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" Hartford.Pace.sln /nologo /v:n /p:Configuration=Release /p:DeployOnBuild=True /p:CreatePackageOnPublish=True /p:AutoParameterizationWebConfigConnectionStrings=False /p:EnableNuGetPackageRestore=True /p:VisualStudioVersion=10.0
And now I'm getting the following error only for VS2010 web apps:
"d:\a5\bi_hartsource_pace\Microsoft_Build_Web_App\trunk\Hartford.Pace.sln" (default target) (1) ->
"d:\a5\bi_hartsource_pace\Microsoft_Build_Web_App\trunk\Hartford.Pace.Services\Hartford.Pace.Services.csproj" (default target) (2) ->
(PackageUsingManifest target) ->
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets(3009,5): error : Web deployment task failed. (Unknown ProviderOption:DefiningProjectFullPath. Known ProviderOptions are:.) [d:\a5\bi_hartsource_pace\Microsoft_Build_Web_App\trunk\Hartford.Pace.Services\Hartford.Pace.Services.csproj]
Which points to a problem with the packaging target files. I checked them and none of them were changed by the update.
Does anyone know of side-by-side issues with VS2010 and VS2015? I'd like to upgrade the VS2010 Solutions but it's not my code and I need to build existing apps without modification.
Is this the best method for packaging an app without having the developers create publishing profiles or running anything at their end? This is supposed to be a fully automated build and deploy process. It has been working for three years with no issues but I'm open to suggestions that I can implement entirely on my build server without involving changing files in the source code (including csproj or other controlling files).
Add /p:VisualStudioVersion=10.0

Can you call an earlier version of MSBuild from 2013 from TFS build definition

Our company just migrated our project from a TFS 2012 server to 2013 TFS server as well as our build controllers (2012 servers to 2013). I know within VS2013 MSBuild is now part of the application however I have a need to also reference older build machines that build some of our SSIS and SSAS projects as part of deployment. The challenge I have is these projects use Business Intelligence for 2008R2 and I cannot migrate the solution/projects forward.
Within my analytic's solution which was authored in VS2010 I have the following build command:
<Target Name="BeforeBuild">
<!-- Build SSIS Package-->
<Exec Command=""C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe" "$(MSBuildProjectDirectory)\..\AnalyticsSSAS\AnalyticsSSAS.dwproj" /Build" />
</Target>
<PropertyGroup>
<PostBuildEvent>xcopy "$(ProjectDir)..\AnalyticsSSAS\bin\*.*" /y</PostBuildEvent>
</PropertyGroup>
When I try to run a build using the 2013 definition the build fails and states that the msbiuld taks EXEC is not recognized. I can open the solution and projects individually and build them (running 2010) with no issues 2013 wants to migrate the solution to which I can't do.
Here is the actual message generated in the build log file:
"f:\blds\26\DevCI\src\Analytics.sln" (default target) (1) ->
"f:\blds\26\DevCI\src\Database\Dashboards\SSASBuild\SSASBuild.csproj" (default target) (2) ->
(BeforeBuild target) ->
f:\blds\26\DevCI\src\Database\Dashboards\SSASBuild\SSASBuild.csproj(85,5): error MSB3073: The command ""C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe" "f:\blds\26\DevCI\src\Database\Dashboards\SSASBuild\..\AnalyticsSSAS\AnalyticsSSAS.dwproj" /Build" exited with code 1.
"f:\blds\26\DevCI\src\Analytics.sln" (default target) (1) ->
"f:\blds\26\DevCI\src\Database\Dashboards\SSISBuild\SSISBuild.csproj" (default target) (3) ->
f:\blds\26\DevCI\src\Database\Dashboards\SSISBuild\SSISBuild.csproj(84,5): error MSB3073: The command ""C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe" "f:\blds\26\DevCI\src\Database\Dashboards\SSISBuild\..\AnalyticsSSIS\AnalyticsSSIS.dtproj" /Build" exited with code 1.
I suspect from what I have read that MSBuild in VS2013 will not allow for a lower version of MSBuild v9.0 to be referenced without migrating the project to a newer version.
Has anyone seen this before and is there any workaround for this type of build?
-cheers
I think there are many solution, but the basic idea is to force using the old MSBuild version.
Custom Build Template (old style)
Add an MSBuild activity and set the ToolPath Property to the old version. You must expose a list of solutions to build as Template arguments.
Script (new style)
Write a post-build (or pre-build) script that invokes the proper MSBuild version with the path to the solution.

Building InstallShield LE project with MSBuild - Error MSB4062

I work with Visual Studio 2012, and I just switched my deployment tools from NSIS to InstallShield. I've added new projects to my solution for InstallShield installers. When I build in Visual Studio (the IDE) I've no errors, no warnings and I'm happy.
Now, I want to have a script that build the full solution without launching the IDE. But when I run MSBuild in the command line, like that
MSBuild MySolution.sln /t:Build /p:Configuration=Release
I get following error MSB4062
C:\Program Files (x86)\MSBuild\InstallShield\2012SpringLimited\InstallShield.targets(21,3): error MSB4062: The "Microsoft.Build.Tasks.AssignProjectConfiguration" task could not be loaded from the assembly Microsoft.Build.Tasks.v3.5. Could not load file or assembly 'Microsoft.Build.Tasks.v3.5' or one of its dependencies. The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
My searches lead me to the conclusion that I must buy the Premier Edition of InstallShield to take profit of ISCmdBuild. But I can't afford it, and I think there might be another solution.
Any idea?
Using Fusion logging the MSBuild checks for the DLL here: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Microsoft.Build.Tasks.v3.5.DLL.
I copied
c:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Build.Tasks.v3.5.dll
to
c:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Build.Tasks.v3.5.dll
And the error is gone.
Alternatively open your *.isproj file and change from "3.5" to "4.0" on top on the tag:
<Project ToolsVersion="3.5"...> --> <Project ToolsVersion="4.0" ...>
Another solution is to force MSBuild to use the x86 platform. See https://stackoverflow.com/a/1074699/870604
If you're building from a TFS build, this can be configured from the build options:
I found the solution. Use the command devenv.exe instead of MSBuild.exe. It will be similar to launching Visual Studio and clicking the Build button. That's all!
devenv.exe MySolution.sln /build Release

TFS2010: Build Configuration Issues

I have customized the build configurations in my solution by deleting the Debug and Release configurations and creating "Dev" and "Test". Everything builds fine locally but I get the following error (and others like it) when building one of the new configurations in TFS.
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets
(177): Unable to copy file
"bin\CommonServiceFactory.dll" to
"C:\MyApp\Binaries_PublishedWebsites\Epsi.Web\bin\CommonServiceFactory.dll".
Could not find a part of the path
'bin\CommonServiceFactory.dll'.
I'm getting this error for both external and project dependencies. From the posts I've read it seems to be related to the build configuration changes I've made. If I set the TFS build to use the "Debug" configuration I do get a warning but it builds successfully.
C:\MyApp\Sources\MyApp.sln.metaproj:
The specified solution configuration
"Debug|Any CPU" is invalid. Please
specify a valid solution configuration
using the Configuration and Platform
properties (e.g. MSBuild.exe
Solution.sln /p:Configuration=Debug
/p:Platform="Any CPU") or leave those
properties blank to use the default
solution configuration.
Any help would be most appreciated.
MSBuild Command:
MSBuild.exe /nologo /noconsolelogger "C:\Builds\2\MyApp\ci.MyApp.acme.com\Sources\MyApp.sln" /m:1 /fl /flp:"logfile=C:\Builds\2\MyApp\ci.MyApp.acme.com\Sources\MyApp.log;encoding=Unicode;verbosity=diagnostic" /p:SkipInvalidConfigurations=true /p:OutDir="C:\Builds\2\MyApp\ci.MyApp.acme.com\Binaries\" /p:Configuration="Dev" /p:Platform="Any CPU" /p:VCBuildOverride="C:\Builds\2\MyApp\ci.MyApp.acme.com\Sources\MyApp.sln.Any CPU.Dev.vsprops" /dl:WorkflowCentralLogger,"C:\Program Files\Microsoft Team Foundation Server 2010\Tools\Microsoft.TeamFoundation.Build.Server.Logger.dll";"Verbosity=Diagnostic;BuildUri=vstfs:///Build/Build/2603;InformationNodeId=449514;TargetsNotLogged=GetNativeManifest,GetCopyToOutputDirectoryItems,GetTargetPath;TFSUrl=http://tfsServer01:8080/tfs/Core%20Development;"*WorkflowForwardingLogger,"C:\Program Files\Microsoft Team Foundation Server 2010\Tools\Microsoft.TeamFoundation.Build.Server.Logger.dll";"Verbosity=Diagnostic;
The error message indicates that you do not have the dll in the bin\ directory. If you can get on the build machine, can you check to see where the assemblies of your projects were built to? Make sure the path to the assemblies is the one used by the copying/publishing task to copy the assemblies to the Binaries_PublishedWebistes folder.
If this doesn't help, can you post the msbuild command-line from the TFS build details log up?

Resources