I have a Azure pipeline that builds C++ DLLs, I need to build with different toolsets.
I can build 143 (vs2022), 142 (vs2019) and, 141 (vs2017), but when trying to build the 140 (vs2015) version I cannot install the toolset.
I tried the visualstudio2015professional package.
I tried the visualcppbuildtools (Visual C++ Build Tools 2015 14.0.25420.1)
I tried the microsoft-visual-cpp-build-tools (Microsoft Visual C++ Build Tools 2015 14.0.25420.1)
I'm basing my pipeline on a VS2022 image :
trigger:
- master
pool:
vmImage: 'windows-2022'
steps:
- task: CmdLine#2
displayName: 'Choco install additional packages'
inputs:
script: |
choco install visualstudio2015professional visualstudio2017professional visualstudio2019professional
I am missing something obvious ?
I get errors similar to this :
2022-02-16T18:07:50.2000629Z WARNING: Generic MSI Error. This is a
local environment error, not an issue with a package or the MSI itself
it could mean a pending reboot is necessary prior to install or something else (like the same version is already installed). Please
see MSI log if available. If not, try again adding
'--install-arguments="'/lv
c:\VisualStudio2015Professional_msi_install.log'"'. Then search the
MSI Log for "Return Value 3" and look above that for the error.
2022-02-16T18:07:50.2222631Z ERROR: Running
["C:\Users\VssAdministrator\AppData\Local\Temp\chocolatey\VisualStudio2015Professional\2015.03.03\vs_professional.exe"
/Quiet /NoRestart /Log
C:\Users\VssAdministrator\AppData\Local\Temp\chocolatey\vs.log ] was
not successful. Exit code was '1603'. Exit code indicates the
following: Generic MSI Error. This is a local environment error, not
an issue with a package or the MSI itself - it could mean a pending
reboot is necessary prior to install or something else (like the same
version is already installed). Please see MSI log if available. If
not, try again adding '--install-arguments="'/lv
c:\VisualStudio2015Professional_msi_install.log'"'. Then search the
MSI Log for "Return Value 3" and look above that for the error..
Related
I updated my VS build tools 2019 to 2022. Upgraded it for dotnet6. After I updated it to latest one, the pipelines build for dot net framework and dot net 5 failing and throwing error like below
##[error]No agent found in pool DotNet satisfies both of the following demands: Agent.Name, visualstudio. All demands: Agent.Name -equals , msbuild, visualstudio, Agent.Version -gtVersion 2.115.0
But the same pipelines working fine on VS Build tools 2019. We are using the Nuget and VS build in the tasks which are failing. For some pipelines which we are using .netcoreCLI, this build tools 22 are working for .netcoreCLI task. There are many pipelines where I can't migrate to .netcoreCLI. Please someone help me to sort out this issue. [
MSBuild or VSbuild task is not working after I updated it to Visual Studio Build tools 2022 from 2019
According to the error message, this shows that your pipeline has added demands, but there are no agents that meet the requirements in your agent pool:
##[error]No agent found in pool DotNet satisfies both of the following demands: Agent.Name, visualstudio.
So, please check if your pipeline have set any demands:
If you set it,please try to remove or you need to check the value for the capabilities of your agent:
Basically, I have a .netcore 3.1 proj (an exe) that runs flawlessly locally, both with and without a reference to another class library proj (.net framework 4.7.2). However, when I try to get the .netcore3.1 proj to build in Azure it only works when there is no reference to the class library. If there is a reference to the .net framework 4.7.2 class library, the build fails.
Below is the error within the publish portion of the pipeline. This is what comes up when the related code and reference to the class library are being used.
##[debug]Exit code 1 received from tool 'C:\hostedtoolcache\windows\dotnet\dotnet.exe'
##[debug]STDIO streams have closed for tool 'C:\hostedtoolcache\windows\dotnet\dotnet.exe'
##[error]Error: The process 'C:\hostedtoolcache\windows\dotnet\dotnet.exe' failed with exit code 1
##[debug]Processed: ##vso[task.issue type=error;]Error: The process 'C:\hostedtoolcache\windows\dotnet\dotnet.exe' failed with exit code 1
##[warning].NET 5 has some compatibility issues with older Nuget versions(<=5.7), so if you are using an older Nuget version(and not dotnet cli) to restore, then the dotnet cli commands (e.g. dotnet build) which rely on such restored packages might fail. To mitigate such error, you can either: (1) - Use dotnet cli to restore, (2) - Use Nuget version 5.8 to restore, (3) - Use global.json using an older sdk version(<=3) to build
##[debug]Processed: ##vso[task.issue type=warning;].NET 5 has some compatibility issues with older Nuget versions(<=5.7), so if you are using an older Nuget version(and not dotnet cli) to restore, then the dotnet cli commands (e.g. dotnet build) which rely on such restored packages might fail. To mitigate such error, you can either: (1) - Use dotnet cli to restore, (2) - Use Nuget version 5.8 to restore, (3) - Use global.json using an older sdk version(<=3) to build
Info: Azure Pipelines hosted agents have been updated and now contain .Net 5.x SDK/Runtime along with the older .Net Core version which are currently lts. Unless you have locked down a SDK version for your project(s), 5.x SDK might be picked up which might have breaking behavior as compared to previous versions. You can learn more about the breaking changes here: https://learn.microsoft.com/en-us/dotnet/core/tools/ and https://learn.microsoft.com/en-us/dotnet/core/compatibility/ . To learn about more such changes and troubleshoot, refer here: https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops#troubleshooting
##[debug]task result: Failed
##[error]Dotnet command failed with non-zero exit code on the following projects : D:\a\1\s\gwsCheckmarx\gwsCheckmarx.csproj
##[debug]Processed: ##vso[task.issue type=error;]Dotnet command failed with non-zero exit code on the following projects : D:\a\1\s\gwsCheckmarx\gwsCheckmarx.csproj
##[debug]Processed: ##vso[task.complete result=Failed;]Dotnet command failed with non-zero exit code on the following projects : D:\a\1\s\gwsCheckmarx\gwsCheckmarx.csproj
Finishing: dotnet publish dotnetcore
I find it weird how locally it runs fine, but on Azure only works without the project reference. Any ideas?
To avoid compatibility issues you should use for .NET Core 3.1 -> .NET Standard 2.1, because .NET Framework also implements .NET Standard, it is possible in some cases to include .NET Framework libraries in .NET Core projects but it is not a good practice.
If your app runs locally, the error can be because the dotnet sdk version that you are using locally is different that the one in the azure agent (from the error it is .NET 5). You can check by running this command in you local: $ dotnet --version
To set an specific version of the dotnet sdk for your project you can execute this command in the root folder of your solution file $ dotnet new globaljson, it will generate a global.json file in which you can set the dotnet sdk version you have in your local.
Other option is set the dotnet version in the agent with Use .NET Core YAML task, and after that run the build.
- task: UseDotNet#2
inputs:
packageType: 'sdk'
version: '3.1.401'
If you want to know the included software in the Azure pipeline VMs take a look at this link: https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml#software
I am trying to use Jenkins to run my unittests. I have made a Jenkins Project for a build with a buildstep "Build a Visual Studio Project using MSBuild". My Jenkins server is installed on a linux vm which is in Azure.
You can see it here in the Jenkins UI:
When I run the build I get this Console Output:
Path To MSBuild.exe: msbuild.exe
FATAL: Unable to use this plugin on this kind of operation system
Executing the command msbuild.exe /ContinuousIntegration/ContinuousIntegration.sln from
/var/lib/jenkins/workspace/CSHARP_CI_TEST - UNITTEST
[CSHARP_CI_TEST - UNITTEST] $ msbuild.exe
/ContinuousIntegration/ContinuousIntegration.sln
Build step 'Build a Visual Studio project or solution using MSBuild' changed
build result to FAILURE
Build step 'Build a Visual Studio project or solution using MSBuild' marked
build as failure
Finished: FAILURE
I think the problem here is that I am trying to use msbuild.exe on a Linux VM. Is there a workaround for this or is it not possible to do this?
I have tried to use the msbuild.exe on the vm via a linux terminal, but it is not possible to run it.
To accomplish your requirement you have to install '.NET Core SDK' in the Azure Jenkins Linux VM and then you may simply use 'Execute shell' build step with the command 'dotnet build ContinuousIntegration/ContinuousIntegration.sln'
To install '.NET Core SDK' in your Azure Jenkins Linux VM, please go to https://dotnet.microsoft.com/learn/dotnet/hello-world-tutorial/install and click on 'Linux' in that page and then select the required Linux distribution and follow the steps provided.
For more information on MSBuild support on various operating systems, please refer https://github.com/Microsoft/msbuild/blob/master/documentation/wiki/Building-Testing-and-Debugging-on-.Net-Core-MSBuild.md
Just FYI, I have tested and reproduced your scenario and faced the same error which you have mentioned and then I have followed the above process and resolved the issue successfully. So I hope this helps. Cheers!!
PS: in your shell script you have to cd to the right folder for this to work.
I'm building a Xamarin iOS project on the Hosted macOS Preview queue of VSTS.
The log shows that it uses mono 5.8.0. However, the queue specs show that mono 5.10.0 is installed.
The question is how can to choose the version of mono to use (amongst those installed) to build a xamarin ios project on vsts?
UPDATE
Itried the following after #valdetero's answer
- task: XamariniOS#2
displayName: 'Building iOS'
inputs:
solutionFile: '**/*.sln'
configuration: 'Release'
mdtoolFile: '/Library/Frameworks/Mono.framework/Versions/5.10.1/bin'
However, I got that error:
[error]Xamarin.iOS task failed with error Error: Unable to locate executable file: '/Library/Frameworks/Mono.framework/Versions/5.10.1/bin'.
In your Xamarin.iOS task, open Advanced, check MSBuild, and look at build tool path. Specify an installed version of mono here. I used this for an old project where I can't build it with Mono 5. Here's what I have in the box:
/Library/Frameworks/Mono.framework/Versions/4.8.1/bin
Put that entire path in the box.
There are several answers (e.g. this and this) and a blog post pointing out how to install the Visual C++ 2010 redistributable packages as part of the deployment of an Azure cloud service.
Firstly you add the vcredist_x64.exe to the web project and set its "Copy to output directory" property to "Copy if newer" or "Copy always". Then you do the same for a command file (in my case "InstallVC.cmd") which contains the single line:
vcredist_x64.exe /q /norestart
Then you edit the ServiceDefinition.csdef file to include the setting
<Startup>
<Task commandLine="InstallVC.cmd" executionContext="elevated" taskType="simple" />
</Startup>
within the role. The answers and the blog post go on to point out that the start-up task will hang if the osFamily setting on the ServiceConfiguration.csfg is set to osFamily="1" and that it needs instead to be set to osFamily="2".
Mine is set to osFamily="4", but the deployment fails. I get the error message Role has encountered an error and has stopped. Application startup task failed with exit code 5100.
How do you install the the Visual C++ 2010 redistributable packages as part of the deployment of an Azure cloud service using the more recent Azure OS families?
It failed because the Azure cloud service image already had a more up-to-date version of the Visual C++ redistributable packages installed, and so I did not need to install another. What had fooled me into thinking I did need it was that a DLL I use was failing to load its dependencies (as the screenshot below from Dependency Walker shows). But the failure to find the dependencies was not because the Visual C++ redistributable packages were missing, but instead because I was referencing the debug versions (e.g. MSVCP120D.DLL not MSVCP120.DLL). Swapping to 'release' fixed the missing dependencies problem for me, without needing any Azure deployment start-up tasks.