I am trying to set up a build pipeline for the Windows Universal Sample Application File Access Project.
The pipeline is using the Azure Pipelines Hosted VS2017 Image
The solution builds when I run it in VS locally.
Package.appxmanifest contains
<TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.10586.0" MaxVersionTested="10.0.17763.0" />
When the pipeline tries to build the following error appears in the build task log.
Error CS0234: The type or namespace name 'ApplicationModel'
does not exist in the namespace 'Windows'
(are you missing an assembly reference?)
The YAML is
resources:
- repo: self
queue:
name: Hosted VS2017
demands:
- msbuild
- visualstudio
steps:
- task: NuGetCommand#2
displayName: 'NuGet restore'
- task: VSBuild#1
displayName: 'Build solution **\*.sln'
The project looks like this on my machine
Where
And it runs correctly.
I notice the log for the Nuget Restore task has no errors and does report
2018-12-16T01:27:31.8700773Z Checking compatibility for Microsoft.NETCore.Targets.UniversalWindowsPlatform 5.0.0 with UAP,Version=v10.0 (win10-x86-aot).
2018-12-16T01:27:31.8700831Z Checking compatibility for Microsoft.NETCore.Platforms 1.0.0 with UAP,Version=v10.0 (win10-x86-aot).
2018-12-16T01:27:31.8700878Z All packages and projects are compatible with UAP,Version=v10.0 (win10-x86-aot).
[Update]
Looking at the location on my machine of the SDK
C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.AI.MachineLearning.MachineLearningContract\1.0.0.0
I wonder how Nuget is meant to know about that.
Indeed I wonder why it has something about MachineLearning in the path.
[Update]
I changed versions to 17134 (RS4/1803) instead of 17763 (RS5/1809) as suggested by Stefan Wick MSFT
The errors changed to
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft
.AppXPackage.Targets(3218,5): Error APPX0101: A signing key is required in
order to package this project. Please specify a PackageCertificateKeyFile or
PackageCertificateThumbprint value in the project file.
Process 'msbuild.exe' exited with code '1'.
SharedContent\Templates\UWPSDKSampleCPP\ARM\Debug\UWPSDKSampleCPP\AppxManifest.xml(0,0):
Error APPX0501: Validation error. error C00CE169: App manifest validation
error: The app manifest must be valid as per schema: Line 10, Column 13,
Reason: 'Microsoft.SDKSamples.$safeprojectname$.CPP' violates pattern
constraint of '[-.A-Za-z0-9]+'. The attribute 'Name' with value
'Microsoft.SDKSamples.$safeprojectname$.CPP' failed to parse.
Process 'msbuild.exe' exited with code '1'.
SharedContent\Templates\UWPSDKSampleCS\bin\ARM\Debug\AppxManifest.xml(0,0):
Error APPX0501: Validation error. error C00CE169: App manifest validation error:
The app manifest must be valid as per schema: Line 10, Column 13, Reason: 'Microsoft.SDKSamples.$safeprojectname$.CS' violates pattern constraint of '[-.A-Za-z0-9]+'.
The attribute 'Name' with value 'Microsoft.SDKSamples.$safeprojectname$.CS' failed to parse.
Process 'msbuild.exe' exited with code '1'
The error is due to the fact that your app is targeting the 1809 SDK (v17763), which has not been rolled out on the build agents yet, due to some issues.
Until it has been rolled out on the agents, you have two options to get unblocked:
Target the 1803 SDK (v17134) if you don't actually need any APIs from the 1809 SDK - or
Use this script to explicitely install the 17763 SDK dependency
I will update the answer once there is an update regarding the SDK rollout to build agents.
Related
I am very much new in TFS framework, and now i am creating build from last 3 days, all steps passes but fail # Build Solution with error:
[error]Process 'msbuild.exe' exited with code '1'.fails.png
My versions are:
TFS version: Version 15.105.25910.0
VS version: Microsoft Visual Studio Enterprice 2017 (15.9.4)
Can anyone from community tell me whats going wrong with my build.
Build Error:
2018-12-29T11:48:37.1011337Z ##[section]Starting: Build solution
*.sln 2018-12-29T11:48:43.4372323Z ##[command]"C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe"
"\localhost\ARM-Drop1\1\s\LetsGo1\LetsGo1.sln" /nologo /nr:false
/dl:CentralLogger,"\localhost\ARM-Drop1_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.0.45\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll";"RootDetailId=f568d794-328b-48cf-a753-e603bc019eed|SolutionDir=\localhost\ARM-Drop1\1\s\LetsGo1"ForwardingLogger,"\localhost\ARM-Drop1_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.0.45\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll"
/p:VisualStudioVersion="14.0"
/p:_MSDeployUserAgent="TFS_29388952-19c1-40f9-b321-9389f9ab526b_build_17_287"
2018-12-29T11:48:43.5382020Z MSBUILD : error MSB1021: Cannot create an
instance of the logger. Could not load file or assembly
'file://\localhost\ARM-Drop1_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.0.45\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll'
or one of its dependencies. The system cannot find the file specified.
2018-12-29T11:48:43.5392017Z Switch:
CentralLogger,\localhost\ARM-Drop1_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.0.45\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll;RootDetailId=f568d794-328b-48cf-a753-e603bc019eed|SolutionDir=\localhost\ARM-Drop1\1\s\LetsGo1
2018-12-29T11:48:43.7011531Z **##[error]Process 'msbuild.exe' exited
with code '1'. 2018-12-29T11:48:43.7871273Z ##[section]Finishing:
Build solution **.sln
I have resolved this bug, as I had done lot of changes into the solution file and the build definition in order to resolve the issues but no luck, so the quickest way I have in my mind is to delete the build definition plus uninstall the agent and again reconfigure it with appropriate agent capability and create new build definition and its all work as expected and the build definition got succeeded.
We have a C++ application using MFC. We also use the manifest that is auto-generated and we actually do use it.
The environment is windows server 2012 it has TFS 2018 installed on it and a build agent configured. Visual studio 2017 pro 15.6.2 is also installed with all the needed packages for our project.
The weird thing is when I compile the project within visual studio everything is build just fine BUT when I build with the build agent on the same machine there is an error:
Generating code
All 26621 functions were compiled because no usable IPDB/IOBJ from previous compilation was found.Finished generating code
C:\_TFS(0,0): Error c1010070: Failed to load and parse the manifest. The system cannot find the file specified.
C:\_TFS : general error c1010070: Failed to load and parse the manifest. The system cannot find the file specified. [C:\_TFS Build Agents\DEUSRV52\_work\1\s\test\App\HC100\HC100.vcxproj]
LINK(0,0): Error LNK1327: failure during running mt.exe
LINK : fatal error LNK1327: failure during running mt.exe [C:\_TFS Build Agents\DEUSRV52\_work\1\s\test\App\HC100\HC100.vcxproj]
Done Building Project "C:\_TFS Build Agents\DEUSRV52\_work\1\s\test\App\HC100\HC100.vcxproj" (default targets) -- FAILED.
Done Building Project "C:\_TFS Build Agents\DEUSRV52\_work\1\s\test\App\HC100.sln" (default targets) -- FAILED.
Build FAILED.
"C:\_TFS Build Agents\DEUSRV52\_work\1\s\test\App\HC100.sln" (default target) (1) ->
"C:\_TFS Build Agents\DEUSRV52\_work\1\s\test\App\HC100\HC100.vcxproj" (default target) (4) ->(Link target) -> C:\_TFS : general error c1010070: Failed to load and parse the manifest. The system cannot find the file specified. [C:\_TFS Build Agents\DEUSRV52\_work\1\s\test\App\HC100\HC100.vcxproj]
LINK : fatal error LNK1327: failure during running mt.exe [C:\_TFS Build Agents\DEUSRV52\_work\1\s\test\App\HC100\HC100.vcxproj]
0 Warning(s)
2 Error(s)
Time Elapsed 00:02:11.68
Process 'msbuild.exe' exited with code '1'.
Now it says that a certain file cannot be found except that the file is actually there. My guess is that something else might be wrong here.
So I went to the folder where the sources are being placed via the get sources task which is in the agent's folder structure and I then opened the solution with visual studio and build it there and again within visual studio the build is successful.
I've been looking on the internet and I found a couple of solutions such as:
disable manifest creation in the linker options menu... (this is not a solution for us since we need it)
mt.exe can't cope with spaces in the file path (strange since when opening the same files in visual studio it does build or is there something different when opening it from VS or building it with an agent?)
Digital Guardian might restrict execution (we don't have that nor can I see it in procmon)
A virus scanner might block execution (nothing is installed on the environment)
when using the Visual studio build step instead of msbuild build step in the TFS build system the build fails with exactly the same error.
I'm pretty sure that it has nothing to do with points 3 and 4 (virus scanners/ security restrictions) since I can build it successfully within the visual studio itself.
I just started to use TFS build for the first time so there is a big chance that I'm missing something here. Hopefully, someone can help me out.
I have asked this question on MSDN forums as well (https://social.msdn.microsoft.com/Forums/en-US/587b1c42-8ac6-4deb-95aa-4d74c91fd55f/msbuild-issue-on-windows-server-2012-link1327-mtexe-error-c1010070?forum=Offtopic) where I got the suggestion to ask the question here as well.
The issue is found and we have a workaround implemented.
When an Agent is defined in a path that has spaces in it mt.exe will not be able to find a file within that path. But this gets stranger because when you have a path that contains spaces and you run msbuild.exe via the command line mt.exe will find the path and the build is successful. after some testing we found out that if you combine the execution on an agent (which is located in a path that has spaces) the execution of mt.exe by the agent will have this error that mt.exe is not able to find the file. Now to completely test this and to make 100% sure that this has something to do with the agents path I created a build definition with specific execution paths. So I disabled the get sources step, removed all the sources then placed all the sources in a space free path and then ran the msbuild commands on an agent that contains spaces in its path and then it failed again.
So what we settled for is to locate our agents in a path that does not contain any spaces and now it builds just fine.
I habe a TFS-Server-Build (TFS 2017) on a Build-Agent with VS 2017. The first Buildstep (Prepare the Sonarqube analysis) and the build of the solution works fine. But i have a error at "Complete the SonarQube analysis":
2017-05-29T03:06:09.1933915Z ##[error]The SonarQube MSBuild integration failed: SonarQube was unable to collect the required information about your projects.
2017-05-29T03:06:09.1933915Z ##[error]Possible causes:
2017-05-29T03:06:09.1933915Z ##[error]1. The project has not been built - the project must be built in between the begin and end steps
2017-05-29T03:06:09.1933915Z ##[error]2. An unsupported version of MSBuild has been used to build the project. Currently MSBuild 12.0 upwards are supported
2017-05-29T03:06:09.1933915Z ##[error]3. The begin, build or end steps have not all been launched from the same folder
2017-05-29T03:06:09.1933915Z Generation of the sonar-properties file failed. Unable to complete SonarQube analysis.
2017-05-29T03:06:09.1933915Z ##[error]05:06:09.115 Post-processing failed. Exit code: 1
Can anyone help?
Kind regards
Sebastian
I am not familiar with TFS-Server-Build,, but the possible causes are mentioned.
Check the following link for more details on how to set it up properly
Just like the error mentioned this stands for SonarQube was unable to collect the required information about your projects
Even though you have installed MSBUILD 12 or above, you should make sure the Build agent is calling the right version.
And double check if the MSBuild.SonarQube.Runner and MSBuild is running from the same working directory. At .sonarqube/out folder the sonar-project.properties is getting created or not.
I'm trying to do a teambuild for a VS2015 solution with TFS2013.
On the buildserver VS2015 is installed and I changed the buildtemplate so msbuild has an argument \tv:14.0, but when a start a build I get the following error:
C:\Program Files
(x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets (96):
Invalid static method invocation syntax:
"[Microsoft.Build.Utilities.ToolLocationHelper]::GetPlatformSDKDisplayName($(TargetPlatformIdentifier),
$(TargetPlatformVersion))". Method
'Microsoft.Build.Utilities.ToolLocationHelper.GetPlatformSDKDisplayName'
not found. Static method invocation should be of the form:
$([FullTypeName]::Method()), e.g. $([System.IO.Path]::Combine(a,
b)).
The buildserver has been restarted but I still get the error.
I also checked this thread: Build failed in TFS but no real answer was given there. Is there anyone that knows how to solve this.
I was experiencing the exact same error. I determined that TFS2013 was the RTM version so we installed TFS2013 Update 5. Now if I run using the *.12.xaml process template with the /tv:14.0 /p:VisualStudioVersion=14.0 parameters the build succeeds. I have also made a copy of the *.12.xaml build process and named it *.14.xaml and changed the Run MSBuild steps ToolVersion property to "14.0" and this build works as well, without the parameters.
You need to customize the build process template by finding all the Run MSBuild for Project MSBuild activity, then set the ToolVersion to "14.0" and set ToolPath to target to MSBuild14 (by default: "C:\Program Files (x86)\MSBuild\14.0\Bin"). After that, check in the build process template and re-queue the build.
Check the solutions here:TFS 2013 building .NET 4.6 / C# 6.0
My TeamCity build fails because I have a project that has 2 EF Code Migration configurations in it.
From the build log:
[12:39:58]Checking for changes
[12:39:58]Collecting changes in 1 VCS root (1s)
[12:40:00]Clearing temporary directory: C:\TeamCity\buildAgent2\temp\buildTmp
[12:40:00]Publishing internal artifacts
[12:40:00]Checkout directory: C:\TeamCity\buildAgent2\work\1679b8b30e00ad0
[12:40:00]Updating sources: server side checkout (2s)
[12:40:03]Step 1/8: Gulp (Command Line)
[12:40:03]Step 2/8: Nuget Package Refresh (NuGet Installer) (3s)
[12:40:06]Step 3/8: Compile (MSBuild) (21s)
[12:40:27]Step 4/8: Unit Tests (NUnit) (33s)
[12:41:01]Step 5/8: Transform Files (Powershell) (2s)
[12:41:03]Step 6/8: Deployment Build on XXXXX Live (MSBuild) (25s)
[12:41:29]Step 7/8: Deploy Database (Powershell) (5s)
[12:41:34]Step 8/8: Deploy Portal.Hub (Powershell) (33s)
[12:42:08]Publishing artifacts
[12:42:08][Publishing artifacts] Collecting files to publish: [C:\TeamCity\buildAgent2\temp\buildTmp\nuget5954880593924726328packages\nuget.xml => .teamcity/nuget]
[12:42:08][Publishing artifacts] Publishing using [WebPublisher]
[12:42:08][Publishing artifacts] Publishing using [ArtifactsCachePublisher]
[12:42:08][Publishing artifacts] Artifacts path 'C:/TeamCity/buildAgent2/temp/buildTmp/nuget5954880593924726328packages/nuget.xml' not found
[12:42:08]Reverting patched assembly versions
[12:42:08][Reverting patched assembly versions] Restoring C:\TeamCity\buildAgent2\work\1679b8b30e00ad0\src\Portal.Api\Properties\AssemblyInfo.cs
[12:42:08][Reverting patched assembly versions] Restoring C:\TeamCity\buildAgent2\work\1679b8b30e00ad0\src\Portal.Common\Properties\AssemblyInfo.cs
[12:42:08][Reverting patched assembly versions] Restoring C:\TeamCity\buildAgent2\work\1679b8b30e00ad0\src\Portal.Data\Properties\AssemblyInfo.cs
[12:42:08][Reverting patched assembly versions] Restoring C:\TeamCity\buildAgent2\work\1679b8b30e00ad0\src\Portal.Hub\Properties\AssemblyInfo.cs
[12:42:08][Reverting patched assembly versions] Restoring C:\TeamCity\buildAgent2\work\1679b8b30e00ad0\src\Portal.Manager\Properties\AssemblyInfo.cs
[12:42:08][Reverting patched assembly versions] Restoring C:\TeamCity\buildAgent2\work\1679b8b30e00ad0\src\Portal.Managers\Properties\AssemblyInfo.cs
[12:42:08][Reverting patched assembly versions] Restoring C:\TeamCity\buildAgent2\work\1679b8b30e00ad0\src\Portal.SignalR\Properties\AssemblyInfo.cs
[12:42:08][Reverting patched assembly versions] Restoring C:\TeamCity\buildAgent2\work\1679b8b30e00ad0\src\Portal.Tests\Properties\AssemblyInfo.cs
[12:42:08]Publishing internal artifacts
[12:42:08][Publishing internal artifacts] Sending using WebPublisher
[12:42:08][Publishing internal artifacts] Sending using ArtifactsCachePublisher
[12:42:08]Build failure condition: There was an error reported in one of the build steps.
[12:42:08]Build failure condition cause message: ERROR: More than one migrations configuration type was found in the assembly 'Portal.Data'. Specify the name of the one to use. (show original message)
[12:42:08]Build finished
Note: the only red (failures) are the last two lines above "Build Finished"
I am not running the migrations and I can't see any steps in team city or the publish profile that would be attempting to do this.
I do not want to split my configurations into separate projects, I just want to stop TeamCity from attempting to run them.
My Build Steps are:
1/8 Gulp - minimize js files
2/8 NuGet Installer - update nuget references in the solution
3/8 MSBuild - .NET 4.5 x86 compile
4/8 NUnit - run unit tests
5/8 Powershell - run script to manipulate app.config files for the windows service
6/8 MSBuild - use publish profile to deploy website
7/8 Powershell - script to deploy database
8/8 Powershell - script to deploy windows service
The publish profile: validation connection button works OK on the connection tab, on the settings page there are several databases listed but none have connection strings or "use this connection string at runtime" checked. One of them has an info label next to it "In order to publish a Code First Model, Code First Migrations should be used".
We have virtually identical build configurations for other projects which work fine.
Thanks
From the logs, it does appear as though you are trying to apply the EF migrations in Step 7 - Deploy Database Step.
This is where the config exception is getting thrown.
If the goal is to stop TeamCity from running them then disabling the step would do that.
Hope this helps