I've installed the latest VS Build Tools (2022), but my on-prem build agent isn't picking up the VisualStudio-related capabilities. I've been under the impression that we no longer need to install the full application in order to get these capabilities.
An example from this blog post:
I've added all workloads to my offline layout, and I've included them in my installation.
I know this is possible, because earlier I accidentally included Python and VS 2019 Build Tools in my Node.js installation configuration. The VS-related capabilities were found by the agent then.
But I'm trying to get 2022, so I uninstalled 2019.
How can I get the 2022 VS-related capabilities to be installed and detected by my build agent, without installing the full Visual Studio product?
You need to upgrade the agent to a recent enough version. You can download the agent from the azure-pipelines-agent repository's releases page. Or manually specify the capabilities.
You may need to set a special environment flag on the agent to prevent it from automatically being downgraded to whatever version shipped with your version if Azure DevOps Server or Team Foundation Server.
And then you'll also need to install the latest version of the vsbuild/msbuild and vstest tasks
Required agent version
You will need to install the most recent agent from the azure-pipelines-agent repository for it to auto-detect Visual Studio 2022, or alternatively add the capabilities to the agent manually.
You may need to force Azure DevOps Server to not downgrade back to its preferred agent version. You can do so by setting the following environment variable at the system level on your server before launching the agent:
AZP_AGENT_DOWNGRADE_DISABLED=true
These tricks will work for most tasks in the azure-pipelines-tasks repository, as long as it doesn't depend on a UI extension or service connection type that isn't available in your version of Azure DevOps Server.
https://jessehouwing.net/adding-visual-studio-2022-to-azure-devops-server-2020/
Related
We have an on-premises Azure DevOps 2019 server, with build pipelines for numerous .Net 4.x solutions that our small team maintains using VS2019.
The team is about to upgrade to VS2022, and at some point I would like to migrate some solutions to .Net 6. Can DevOps 2019 build .Net 6 solutions, and if so what changes are needed to support this (such as presumably installing VS2022 on the server)?
Will those solutions' build pipelines require any changes or should they continue to work as-is? They don't contain anything too clever, with steps such as: NuGet restore, build solution, run unit tests, NuGet pack & push. (The build pipelines are managed via the web GUI, not YAML, if that makes a difference).
Some solutions will remain .Net 4.x, so the server will still need to support (build) these.
You should just need two things:
First you have to install the corresponding SDK for building the apps (see sdk download - Build apps - SDK) on your build-agents.
(Optional) Add or modify your set SDK Task in your pipelines (see use dotnet core task).
One more hint, you don't need to install a whole VS on the server. The Build-Tools are enough (VS2022 Buildtools preview).
I have some problem with self-hosted Integration Runtime in Azure Data Factory V2.
I have a few VMs running 4.X.X IR software. Some of them had auto update enabled in DFv2
There was an update from 4.X.X to 5.X. After this, IR is unavailable from DFv2.
Looks like the IR services running on the VMs are pointing to a wrong execute path - using still 4.0. I can fix it manually with sc config or reinstall IR, but after reboot it doesn't work again.
Is that a bug? Can I somehow fix it without removing the VMs?
Update:
What I did - I went to Data Factory V2 Integration Runtimes and picked my self-hosted IR, went to Auto update and enabled it. My Virtual Machine hosting this IR was running an older IR software (4.X.X). There was an update to 5.X.X. Everything was working fine until I rebooted the VM. After this from Data Factory V2 Integration Runtimes I was seeing an error saying that my self-hosted IR is unavailable. I logged into the hosting VM and it turned out that IR software cannot start its service dmgsvc.exe. When you go to services.msc and check the Integration Runtime service pointing to the dmgsvc.exe, the path will be incorrect. What was wrong there? It was a catalog 4.0 instead of 5.0. IR software cannot start up correctly because of that and the error is Error 2: System cannot find the file specified. So what I did? I manually fixed it and it was working. But after the first reboot of the VM it was again pointing to the 4.0 catalog. I reinstalled the software and the effect was the same.
For the upgrade to version 5.x of the Azure Data Factory self-hosted integration runtime, we require .NET Framework Runtime 4.7.2 or later. On the download page, you'll find download links for the latest 4.x version and the latest two 5.x versions.
If automatic update is on and you've already upgraded your .NET
Framework Runtime to 4.7.2 or later, the self-hosted integration
runtime will be automatically upgraded to the latest 5.x version.
If automatic update is on and you haven't upgraded your .NET
Framework Runtime to 4.7.2 or later, the self-hosted integration
runtime won't be automatically upgraded to the latest 5.x version.
The self-hosted integration runtime will stay in the current 4.x
version. You can see a warning for a .NET Framework Runtime upgrade
in the portal and the self-hosted integration runtime client.
Refer: Troubleshoot self-hosted integration runtime
The documentation around the AOT compilation feature of Xamarin Android states that it is only available when using Enterprise additions of Visual Studio. What does this means for AzureDevops build pipelines if the feature is enabled?
Presumably the build agents don't use an Enterprise addition of the Visual Studio build tools so does this mean a build produced via AzureDevops cannot have the AOT feature enabled? If this is true the feature seems of limited use when using AzureDevops as you won't be able to have it enabled for release builds coming from your build pipelines.
The Build Agent "Windows latest" does have VS 2019 Enterprise installed. See here for a link to the List with all included software.
In addition, last time I tried that out I had to manually install the Android NDK. I used a command line step with this:
C:\"Program Files (x86)"\Android\android-sdk\tools\bin\sdkmanager "ndk-bundle"
Although it might well be that this changed meanwhile since it is listed in the included software.
Background:
We are using the VSTS to build and Octopus integration to deploy our product. The Octopus step is configured as follows,
Issue
Today VSTS Build was throwing following error,
No supported agent found in pool Default. All agents in this pool are
using a version that is deprecated. Migrate to the latest 2.x version
of agent. For more information, see
https://go.microsoft.com/fwlink/?linkid=851067
As a result, the Agent was updated to the latest version,
After the update the octopus step stopped working with following error,
Then issue seems to be the environment variables are not replaced in the step.
I would like to know if there is a work around to fix this issue.
First, there is 2.* version available, so you can delete the old one and add the new one.
Secondly, use $(Build.BuildNumber) instead in Package Version input box, also for Output path: $(Build.ArtifactStagingDirectory).
Can you please enlighten me on my task?
My task is to create a nightly builds of MSI (done in WiX) and install it to our web server using powershell.
TFSBuild server build an MSI
Run Powershell to uninstall and install the newly build MSI.
Run Powershell to Start the windows service.
The WiX MSI contains WindowsService and a Web Application.
Below are list of what i have done so far:
Solution.sln : Configuration Manager and "x86|debug" (check all the files that needs to be built '.wixproj' already checked)
Created a build definition and set "x86|debug" for configurations to build and set projects to build is my solution file.
but after the build has completed, there is no MSI files on the binaries build folder on the build server. :(
Thanks in advance.
Few pointers:
Have you installed Wix on the buildserver?
Which version of Team Build are you using? 2010 has the preference here as the tooling has progressed a lot since 2008.
Did you configure to run msbuild in auto or x86 mode (auto can result in 64-bit which has some issues with the latest stable version of wix) link link
Is your build agent running on a 64 bit server? If so, you either need to run the build agent under an administrative account or do some mucking around in the registry to fix issues with Wix. link
To install the build using Powershell, I personally prefer TFSDeployer, which can monitor your build output and trigger powershell scripts based on the build outcome. It takes away the deployment responsibility from the build server and saves a lot of headaches around security and account configurations.