Running command
msbuild DevTools.Target /p:Configuration=Debug /p:Platform="Win32"
fails with error
Microsoft (R) Build Engine Version 4.0.30319.1
[Microsoft .NET Framework, Version 4.0.30319.225]
Copyright (C) Microsoft Corporation 2007. All rights reserved.
Build started 1/7/2014 2:24:12 PM.
Project "t:\DevTools.Target" on node 1 (default targets).
LoadInfo:
Built PROJECT as C:\XXX
Gathering Version information
IS BUILD MACHINE: false
Next Build # :
Will this run increment the build : yes
Project "t:\PROJECT\DevTools.Target" (1) is building "T:\solution.sln" (2) on node 1 (default targets).
T:\solution.sln.metaproj : error MSB4126: The specified solution configuration "|Debug|Win32" 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.
Build FAILED.
Win32 platform DOES exist in solution and I able to build Solution successfully from IDE
Thing is that this is no ordinary SLN file passed to msbuild but instead its TARGET (XML) file.
How can I force msbuild to use "Win32" platform during build ?
see the error, you've got something wrong in your devtools.target: it tries to build "|Debug|Win32" but that should be "Debug|Win32"
Related
How can I publish the UWP package via command line?
I have a WPF application that is packaged with a Windows Application Package Project that ends up being published to the Microsoft Store.
In order to be accepted in the Store, the WPF project needs to be compiled with a preprocessor directive (that I named as "UWP"), deactivating stuff that are not allowed for Store apps.
I'm in the process of migrating the WPF app from .NET Framework 4.8 to .NET 5 and along with that I'm trying to streamline my publishing process via command line.
Is there any way to configure or update the package to support ARM64?
The app will be published outside the Store as x86, x64 and ARM64 and I intend to do the same for the Store version.
When checking the WAPP, I noticed that ARM64 is not available on the list. As you can see in the screenshot, I was able to create a ARM64 build profile, but the architecture is not available on the table.
What have I tried? (Command line issue)
I tried running this command:
MSBuild.exe C:\Project-UWP\Project.UWP\Project.UWP.wapproj /p:DefineConstants=UWP /p:Configuration=Release;AppxBundle=Always;AppxBundlePlatforms="x86|x64|ARM64" /p:OutDir="..\Publish\UWP"
But got these errors:
Microsoft (R) Build Engine version 16.11.0+0538acc04 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 29/09/2021 22:09:19.
Project "C:\Project-UWP\Project.UWP\Project.UWP.wapproj" on node 1 (default targets).
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(1718,5): warning NU1702: ProjectReference 'C:\Project\Project.csproj' was resolved using '.NETCoreApp,Version=v6.0' instead of the project target framework '.NETFramework,Version=v4.5.1'. This project may not be fully compatible with your project. [C:\Project-UWP\Project.UWP\Project.UWP.wapproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(1718,5): warning NU1702: ProjectReference 'C:\Project\Project.csproj' was resolved using '.NETCoreApp,Version=v6.0' instead of the project target framework '.NETFramework,Version=v4.5.1'. This project may not be fully compatible with your project. [C:\Project-UWP\Project.UWP\Project.UWP.wapproj]
_ResolveVCLibDependencies:
Searching for SDKs targeting "UAP, 10.0.20348.0".
Project "C:\Project-UWP\Project.UWP\Project.UWP.wapproj" (1) is building "C:\Project\Project.csproj" (2:9) on node 1 (publish target(s)).
C:\Program Files\dotnet\sdk\5.0.401\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(241,5): error NETSDK1047: Assets file 'C:\Project\Project\obj\project.assets.json' doesn't have a target for 'net5.0-windows/win-x86'. Ensure that restore has run and that you have included 'net5.0-windows' in the TargetFrameworks for your project. You may also need to include 'win-x86' in your project's RuntimeIdentifiers. [C:\Project\Project.csproj]
Done Building Project "C:\Project\Project.csproj" (publish target(s)) -- FAILED.
Done Building Project "C:\Project-UWP\Project.UWP\Project.UWP.wapproj" (default targets) -- FAILED.
Build FAILED.
"C:\Project-UWP\Project.UWP\Project.UWP.wapproj" (default target) (1) ->
(_GetProjectReferenceTargetFrameworkProperties target) ->
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(1718,5): warning NU1702: ProjectReference 'C:\Project\Project.csproj' was resolved using '.NETCoreApp,Version=v6.0' instead of the project target framework '.NETFramework,Version=v4.5.1'. This project may not be fully compatible with your project. [C:\Project-UWP\Project.UWP\Project.UWP.wapproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(1718,5): warning NU1702: ProjectReference 'C:\Project\Project.csproj' was resolved using '.NETCoreApp,Version=v6.0' instead of the project target framework '.NETFramework,Version=v4.5.1'. This project may not be fully compatible with your project. [C:\Project-UWP\Project.UWP\Project.UWP.wapproj]
"C:\Project-UWP\Project.UWP\Project.UWP.wapproj" (default target) (1) ->
"C:\Project\Project.csproj" (publish target) (2:9) ->
(ResolvePackageAssets target) ->
C:\Program Files\dotnet\sdk\5.0.401\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(241,5): error NETSDK1047: Assets file 'C:\Project\obj\project.assets.json' doesn't have a target for 'net5.0-windows/win-x86'. Ensure that restore has run and that you have included 'net5.0-windows' in the TargetFrameworks for your project. You may also need to include 'win-x86' in your project's RuntimeIdentifiers. [C:\Project\Project.csproj]
2 Warning(s)
1 Error(s)
Time Elapsed 00:00:01.31
Notice that there are warnings related to framework references:
ProjectReference C:\Project\Project.csproj was resolved using .NETCoreApp,Version=v6.0 instead of the project target framework .NETFramework,Version=v4.5.1.
This project may not be fully compatible with your project. Microsoft.Common.CurrentVersion.targets 1719
The WPF project was set to use .NET 5, so I don't see why there's any reference to .NETCoreApp 6 or .NET Framework 4.5.1.
What have I tried? (Missing ARM64 issue)
I created a WAPP from scratch and saw that the option for ARM64 appeared in the architecture table.
But when publishing manually via the context menu, I'll get this error:
The specified RuntimeIdentifier 'win-ARM64' is not recognized.
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.
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>
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
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?