i have a vm on which i installed the lastest version of microsoft visual studio (16.7.3). this machine is intended to be used as a build-agent for azure devops pipelines.
i tried the following.
opened visual studio, download and open the project source, build (releasebuild) the project, archive and sign the apk and install it on the target device (android 7.0) --> this was successful. the app works as expected.
i also installed the build-agent-package (vsts-agent-win-x64-2.170.1.zip) on this machine.
i configured it and it was succesfully registered at the azure devops site.
when i run a build pipeline targetting the same project (releasebuild), the agent generates and signs the apk-package. this apk-package installs on the target device but the app does not start.
this means: no error messages, only a white screen.
i compared the two apks, they differ slightly, the inner folder structure is equal,
but some files have different sizes.
this test runs against the azure devops server 2020 rc2. but i have the same issue
using the tfs 2018 and the corresponding build agent.
could anyone give me some hints how to research this issue?
many thanks in advance
keek
Related
I have a fully working web api written in dotnet core 3.1. I've been following the TimCoRetailManager series.
The application builds with no errors and works as intended when running in Visual Studio. I have a free azure subscription. I setup a F1 free web app service on linux and two basic SQL server databases, all in the same resource group with the firewall set to allow access to other azure services to connect. I can publish the web api and the databases. I can connect to the databases with azure data studio and things look fine. I updated the config on the app service so it's using the azure secrets instead of my dev environment secrets. The API works as intended when published from Visual Studio, i can get to the swagger ui, and life is good.
On to Azure DevOps. When I use a release pipeline from Azure DevOps, the pipeline gives a success message. However, when I navigate to the API (has a simple MVC landing page + swagger) it just has an "Application Error :(" page. I found the logs on the Azure App service and they have this...
Ok 2022-03-01T21:44:43.8098649 \/ \/ \/
Ok 2022-03-01T21:44:43.8098677 A P P S E R V I C E O N L I N U X
Ok 2022-03-01T21:44:43.8098704
Ok 2022-03-01T21:44:43.809873 Documentation: http://aka.ms/webapp-linux
Ok 2022-03-01T21:44:43.8098757 Dotnet quickstart: https://aka.ms/dotnet-qs
Ok 2022-03-01T21:44:43.8098784 ASP .NETCore Version: 3.1.21
Ok 2022-03-01T21:44:43.809881 Note: Any data outside '/home' is not persisted
Ok 2022-03-01T21:44:44.3985103 Running oryx create-script -appPath /home/site/wwwroot -output /opt/startup/startup.sh -defaultAppFilePath /defaulthome/hostingstart/hostingstart.dll -bindPort 8080 -userStartupCommand 'dotnet TRMApi.dll'
Ok 2022-03-01T21:44:44.4498212 Cound not find build manifest file at '/home/site/wwwroot/oryx-manifest.toml'
Ok 2022-03-01T21:44:44.4499139 Could not find operation ID in manifest. Generating an operation id...
Ok 2022-03-01T21:44:44.4500119 Build Operation ID: 74cf02f2-a6c2-44a8-9077-95f1bab9d974
Ok 2022-03-01T21:44:45.5344493
Ok 2022-03-01T21:44:45.5358264 Agent extension
Ok 2022-03-01T21:44:45.5358438 Before if loop >> DotNet Runtime
Ok 2022-03-01T21:44:46.2152908 DotNet Runtime 3.1Writing output script to '/opt/startup/startup.sh'
Ok 2022-03-01T21:44:46.6953451 Running user provided startup command...
Ok 2022-03-01T21:44:46.7448258 It was not possible to find any installed .NET Core SDKs
Ok 2022-03-01T21:44:46.7453653 Did you mean to run .NET Core SDK commands? Install a .NET Core SDK from:
Ok 2022-03-01T21:44:46.7457829 https://aka.ms/dotnet-download
The build pipeline appears to be working as intended. It produces four artifacts: a folder for the web api with a zip for deployment, a folder for the database stuff notably with a dacpac, and a folder for the front end with a zip file in there, too. The release pipeline isn't publishing all of this though. I set the package to $(System.DefaultWorkingDirectory)/_Standard Continuous Integration Build/ApiDrop/TRMApi.zip.
The release pipeline has the following settings:
Azure subscription: selected free trial and authenticated it
App Type: Web App on Linux
App Service name: selected api's name from drop down
Startup command: blank
Agent Job
Agent: Azure Pipelines
Agent Specification: windows-2019
Artifact download: continuous integration build > selected all artifacts
Deploy Azure App Service step
Task version: 4.*
Connection type: Azure Resource Manager
Azure subcription: read only, prefilled by app service selection earlier
App service type: also read only, prefilled
App service name: also read only, prefilled
Package or folder: $(System.DefaultWorkingDirectory)/_Standard Continuous Integration Build/ApiDrop/TRMApi.zip
Runtime Stack: 3.1 (DOTNETCORE|3.1)
Any tips or suggestions? I'm really scratching my head on this. I'm watching videos on pluralsight and youtube and it seems like the process "just works" for the content creators, but I'm not able to repeat the results.
Edit: Including screenshot of how artifact is configured in release pipeline.
FWIW, I have the exact same problem from the exact same code base.
I also have the build pipeline artifact set up correctly.
I initially got caught up on the message "It was not possible to find any installed .NET Core SDKs".
I went to the app service "Advanced tools" and then used Bash and issued the commands:
dotnet --list-sdks
dotnet --list-runtimes
Initially, it wasnt reporting any sdk's.
This led to me adding an additional Use.NET Core pipeline task at the beginning of the pipeline with the following parameters
Display Name:
Use .NET Code sdk 3.1.415
Package to install:
SDK (contains runtime)
Version:
3.1.415
Compatible Visual Studio version:
16.7.21
Path to Install .Net core:
$(Agent.ToolsDirectory)/dotnet
I chose the above versions which seemed to match what was reported being available on the linux box.
However, none of this seemed to make any difference, as it still fails with the same error as you. I did want to share what I have tried so far, but wasnt enough to solve it.
On a whim, I spun up a Windows-based App server (Free tier) to deploy to as well. I modified my Release pipeline and added a second "Deploy to App Service" step. This second one deploys to the Windows App Service.
Once I did this, the app runs successfully on the Windows App Service after the second deployment step, but not on the Linux app service after the first deployment step.
It turns out the issue was due to a Build pipeline issue.
It was building the API project using a Visual Studio Build (i.e. MsBuild) project step.
In order to target linux, this needs to be replaced with a
dotnet publish (or a dotnet build followed by a publish) with the parameters "-r linux-x64" plus the appropriate output folder.
Build pipelines and release pipelines do not use the same system default working directory. So I think your release pipeline is probably not getting the artifacts in the build pipeline.
There is an easy way to pass artifacts generated in build pipelines to release pipelines:
In your build pipeline, Use publish build artifact task or publish pipeline artifact task to publish your artfact.
In your release pipeline, click "Add an artifact". Then select "Build" as source type and fill in the information about your build. Note the value of "Source alias", which you need to use as the name for artifacts in release pipeline.
Go to the "Azure App Service Deploy" task. In "Package or folder", click browse button, and you can find your artifacts path there.
I am experimenting with VSTS and CI with Xamarin projects. In doing so I have been running an on-premise build agent on my Mac, to observe the files used and emitted during the build process (in the _work sub folder tree). I have also been running a local build agent on my PC, when building the mobile backend (to be deployed to Azure) but when I start a build for the Android project on the Windows on-prem build agent I get this message from VSTS:
There are agents that are capable of running the build, but they are not online. If the agent is configured to run as a service, ensure that the "VSO Agent ({agent name})" service is running.
I have double-checked the build agent is indeed running and connected to VSTS so my conclusion is it is incapable of running the Android build task. Indeed, if I disable that step, the build starts as expected.
So, Is the Windows version of the build agent incapable of building Xamarin projects?
[EDIT]
Some more experimenting tells me this is related to the machine and, possibly, our corporate network. On my Mac I flipped back to a non-corporate local account and joined the open "Guest" network that is not running behind a proxy. This makes the agent available as a "Xamarin capable" agent. I also successfully built both an iOS and Android project this way. But if I switch back to the corporate local account, the agent becomes "Xamarin incapable" again, even if I join the guest network. So, apparently, the agent's capabilities for building Xamarin projects can be affected by the machine's setup. I will investigate further and also bring this to Microsoft to try and figure out what is going on.
Thanks
We are building Xamarin.Android projects on TFS (on-premise).
With every Visual Studio / Android SDK update we have to update all our build agents.
Is there a way to simplify this process?
There are some vsts-agent images available, but none of them are for xamarin. There are some xamarin-related images, but they are a bit out of date (and not related to TFS).
Is there anything I'm missing? Any other solutions to the problem?
Currently, there are no Docker images support for xamarin or windows. Even for the existing Docker images, there are not for all TFS versions. As you can see from vsts-agent images:
Ubuntu 14.04 and 16.04 are the currently supported OSes, but there are
plans for Windows support.
When used with VSTS, the agent version is automatically determined and
downloaded at container startup based on the account to which the
agent is connecting. When used with TFS, an image that matches the
installed TFS version should be chosen.
There are no better way to do that. So, you have to update the build agents manually once there are any SDK updates.
You can also submit a User Voice to suggest the feature on this site: https://visualstudio.uservoice.com/forums/330519-team-services
Actually a similar user voice submitted here,
Another workaround is migrating to VSTS (Visual Studio Team Services ) and using the hosts agent (Generally the hosts anget will be updated accordingly once new SDK/components updated, See this user voice).
Downloading a current version of the Azure SDK for .Net is easy to do via the Web Platform Installer tool.
The thing is that it only has the latest 2 versions or so.
If I want to download an older version, Microsoft points me to the following download site. When clicking download, I'm confronted with a dialog asking me to select which of 20(!) different files I would like to install.
Of course none of these files have any descriptions, so I'm left to deduce stuff from the file names.
here's the list of all the files i'm seeing for SDK version 2.5
EnvironmentTools.VS.msi
HiveODBC32.msi
HiveODBC64.msi
Microsoft.Azure.HDInsightToolsForVS2012.msi
Microsoft.Azure.HDInsightToolsForVS2013.msi
Microsoft.Azure.HDInsightToolsForVS2015.msi
MicrosoftAzureAuthoringTools-x64.msi
MicrosoftAzureAuthoringTools-x86.msi
MicrosoftAzureComputeEmulator-x64.exe
MicrosoftAzureComputeEmulator-x86.exe
MicrosoftAzureLibsForNet-x64.msi
MicrosoftAzureLibsForNet-x86.msi
MicrosoftAzureQuickstarts.msi
MicrosoftAzureStorageTools.msi
MicrosoftAzureTools.VS110.exe
MicrosoftAzureTools.VS120.exe
MicrosoftAzureTools.VS140.exe
WebToolsExtensionsVS2013.msi
WebToolsExtensionsVWD2013.msi
WindowsAzureStorageEmulator.msi
IS there a way to install older SDKs with a single installation (like Web Platform installer)
if not, What is the minimal set of programs i need to run in order to successfully build and deploy Azure cloud services? (i don't even need to run it on local emulator). Assuming I have 64 bit machine and VS2013.
For me (on x64 machine and VS2013 install) these are the minimal set of programs i needed to install in order for my build to pass:
MicrosoftAzureAuthoringTools-x64.msi
MicrosoftAzureLibsForNet-x64.msi
MicrosoftAzureTools.VS140.exe (for VS2015) or;
MicrosoftAzureTools.VS120.exe (for VS2013)
I have used TFS API to develop a custom Web Application.
When I try to build the Application on the server using TFS Build, I see the
build failing since there are no assemblies installed on the
Build Server.
I have searched online but couldnt find any. Is there an msi somewhere
that I can install on the TFS Build Server which installs all the TFS
API assemblies on the build server ?? , instead of installing
each and every assembly individually.
Most teams install Visual Studio on the build server for a number of reasons. If you do that it will include the TFS Object Model assemblies.