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).
Related
We are migrating our application from .NET 4.6.1 to .NET 6.0.
after deploying the migrated application, it is failing to find framework dlls. After logging into cluster VM looks like .NET 6.0 is not installed on machines. Do we have to have to separately install .NET 6 on cluster?
existing cluster is configured for auto fabric upgrade and current fabric version is 9.0.1028.9590
Thanks
You definitely don't need to install .NET frameworks on Service Fabric - this should be bundled as part of your Service Fabric application packages. We recently went through the exact process of upgrading our applications and I can also confirm that our cluster does not have any recent .NET frameworks installed.
How do you create your deployment packages? I suspect this may be the source of your problem...
For example, if using Azure DevOps, basically you need the following build tasks:
Use Net Core => to install 6.0.x SDK
Restore nuget packages
Build your .sln file via VS Studio build task
Build your .sfproj file via another VS Studio build task with parameters /t:Package /p:PackageLocation=$(build.artifactstagingdirectory)\applicationpackage
And publish artifact using source $(build.artifactstagingdirectory)
Finally, use the default powershell script Deploy-FabricApplication.ps1 that comes with default VS Studio to register and deploy your application to cluster.
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/
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.
When development is finished and TFS (VSTS) takes over. The build completes successfully and the artifact directory contains the published website via a build definition. The Release Manager is then triggered, and takes over and creates a website in an environment, the website files are copied to the environment and the website started. All good so far.
Missing the Database migration steps here...
Now someone starts the server and it fails because the database has not been migrated. How do we do that? The EF Tools were not copied to that environment, in fact we can't even run dotnet.exe because the core sdk has not been deployed onto that environment either. so even if we had the tools, we can't execute them.
In EF 6.x it was easy cause we could just copy migrate.exe as part of the artifacts, and run that on the environment after the files were copied. As I understand it, the EF Tools are now a DLL (ef.dll) that has to be run by dotnet.exe. Does this mean that all web servers now need Core SDK to perform migrations?
Other details about my project setup:
asp.net.core application being deployed onto a QA server for testing. This is not a dev box, does not have VS2015 installed, does not have Core SDK installed.
Update: EF.EXE is part of preview3 and 4.
This solves the requirement for "dotnet.exe" being installed. I can copy that into the artifacts drop like I used to with migrate.exe. Is this the proposed solution by the EF Team?
EF.EXE is part of preview3 and 4.
This solves the requirement for "dotnet.exe" being installed. I can copy that into the artifacts drop like I used to with migrate.exe. Is this the proposed solution by the EF Team?
Yes. Do this.
Also see issue #6313 where we want to make this experience a little easier on .NET Core.
In order to run .NET Core web application on your server, you need to install .NET Core SDK (currently 1.1) on your servers. Doing so will give you the dotnet command so that you can execute dotnet ef database update on your server environment to update the database to a specified migration.
I have a NuGet, currently v2.0.0. It is a portable class library (PCL) supporting .Net4.0+ and WP, Win8, Silverlight (oh-yeah)..., but not vNext (dotnet profile as in universal and aspnetcore50).
Now I have fixed a separate PCL for vNext, that targets the dotnet profile (universal app for win 10, net46, aspnetcore50).
So the nupkg contains myproj.vDinasour.dll and myproj.vNext.dll. Hence if you install in pre vNext you get myproj.vDinasour.dll if in vNext you get myproj.vNext.dll.
I bumped to v3.0.0 from v2.0.0, but should I instead bump to v3.0.0-pre1 or maybe put out two nupkgs?