I have a Xamarin Forms app for Android, which works perfectly fine when I build it locally in VS. I've set up a pipeline to build it in Azure DevOps, too, but the XamarinAndroid#1 task keeps failing without any actual error messages; it just stops. The corresponding "error message" in the pipeline view is just "No message found for this issue". I even added a VSBuild#1 task before, which successfully compiles all projects (including unit tests, which all succeed).
The failing task itself is nothing special, pretty default stuff:
- task: XamarinAndroid#1
inputs:
projectFile: '**/*droid*.csproj'
outputDirectory: '$(outputDirectory)'
configuration: '$(buildConfiguration)'
jdkOption: 'JDKVersion'
It even used to work, too, before adding an indirect dependency to another library, which in turn has a few NuGet dependencies. Both NuGetToolInstaller#1 and NuGetCommand#2 also work perfectly fine in the beginning of the pipeline, finding, installing, and verifying all external packages. And as mentioned before, locally everything works fine, and even the plain VS build task has no problem building everything. I can even see in the build log of the XamarinAndroid-task that the newly added library builds without any errors. Only when it claims to build my actual Xamarin project does it silently die.
The last few lines of that build log are these:
...
CoreGenerateAssemblyInfo:
Skipping target "CoreGenerateAssemblyInfo" because all output files are up-to-date with respect to the input files.
CssG:
Skipping target "CssG" because it has no outputs.
CoreCompile:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Roslyn\csc.exe /noconfig /unsafe- /checked- [... all the build options in the world ...]
Using shared compilation with compiler from directory: C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Roslyn
XamlC:
Compiling Xaml, assembly: obj\Release\netstandard2.0\[My Main Xamarin Project].dll
Finishing: XamarinAndroid
Any pointers to what could be the problem, where to look (is it my project, a Nuget dependency, or the pipeline definition itself?), or how to at least get an error message out of this?
So after the (semi-legal ^^) discussion in the comments with #jdweng I found the culprit: I was indeed using different frameworks in the various libraries, which somehow let the pipeline build fail.
Since DevOps agent jobs (to my understanding) always run on blank, fresh VMs, legacy files could not have been a problem (plus various un-/checkings of "clean" options didn't change anything, either). It's also important to note that everything was only about the pure building (a.k.a converting a *.sln file to an *.apk file), no actual deployment happened yet, and obviously no files were manually exchanged between local and remote machines, as everything was always built from scratch.
Detailed project structure before:
XamarinMainProject both .Net Standard 2.0
& XamarinMainProject.Android
'-> ViewModelLibrary .Net Framework 4.6.1
'-> OneCodeLibrary .Net Framework 4.6.1
'-> TheOtherLibrary .Net Standard 2.0
Interestingly everything worked fine (locally AND on DevOps) when TheOtherLibrary was not included in the build. But as soon as it was referenced, the DevOps Build failed as described above, while locally everything just kept on going as expected.
Now I have recreated the two 4.6.1 projects as .Net Standard 2.0 and the pipeline is happy, too.
This of course raises several questions still:
Why did it work locally (and even on DevOps with a VSBuild task), but not on DevOps for the XamarinAndroid task?
Almost more importantly: Why was there no error message at all (let alone a helpful one)?
Should this be reported as bug to Xamarin (and if so, any hints on where to do so)?
Related
I created a class library project and configured the properties section debug to start an exe (the.exe) located in the output directory of the build (as shown in the image).
It worked as long as we had a pre-build event copying the exe and all related files from one directory in the output directory of the build. Unfortunatly this is inconvinient and we do not have track which version of the exe is used.
So I created a versioned nuget package to place all the files in the output directory. I confirmed all the required files (I know of) are in the output directory. And since I created the nuget package manually with the CLI I can confirm they are exactly the same files.
But when I try to start the application from Visual Studio 2019 now I get the following error in the debug output:
The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core.
The program '[16616] the.exe' has exited with code -2147450749 (0x80008083).
Actually both (the.exe and the class library) are .NET 5.
Comparing the changes of the two setups via Git changes does not hold any clues beside adding the nuget and removing the pre-build events.
So any clue what could be the difference/problem and how to get the executable running? May I missed something?
Well, better check twice when you are stating "I confirmed all the required files (I know of) are in the output directory."
The problem was that not all files made it into the output directory.
In my case only the the.exe and the.dll were placed into the output directory. Once I checked again and ensured that also the.runtimeconfig.json (which was missing) were added it was running again and the exception were gone. Though I am not sure if there is a better way than distributing the.runtimeconfig.json.
update visual studio using Visual Studio installer worked for me. This link! helped for me.
I have a solution written on c#, .netcore 2.2 and the testing framework is xunit that looks pretty much like this:
-src
--controllers
--services
-test
--controllers.integrationtest
--services.integratiotest
we are performing some integration test with two distinct dlls (controllers.integrationtest.dll & services.integrationtest) that use the same database (solutionname.test)
now, when I run "dotnet test" on the solution, it seems that the two dlls are trying to access the same resource (database) and one dll gets a deadlock.
The thing is that I want to disable the parallel execution of the dlls when I run "dotnet test" to avoid that deadlock, so I search that up and the documentation says that to disable parallel execution of dlls you have to:
Add a xunit.runner.json in the root of the csproject which I did and works fine. (this is working on visual studio because I tested it with another feature that deletes the "_" character of test names: [methodDisplay])
Configure xunit.runner.json file to copy always or preserve newest in visual studio so that gets copied on bin folder (as any appsetings.json file)
I've read that you can place an assembly attribute in the assemblyInfo.cs file that by the way it seems that was replaced by the plain csproj so I'm a bit confused.
The ultimate goal that I want to achieve is that when devops use dotnet test the integration test doesn't blow up on concurrency problems.
In xUnit the default value for ParallelizeAssemblies is false so I can only assume that a behavior of dotnet test is causing both to be executed together.
Try and run the tests using dotnet vstest. This requires the DLLS to have been built.
dotnet vstest **/*test.dll
I have a dotNet Core solution containing three projects - one common code, one "read-only" web service and one "admin" web service (which has all the POST, PUT and DELETE routes). The solution builds just fine locally and works. I want to build both projects and run both their publish operations to generate the output artifacts as part of the TFS Gated Check-In.
I have a build definition in TFS (2017) which includes a dotnet build task in which I specified the two project file paths and which has the following parameters...
/p:AssemblyVersion=$(Build.BuildNumber)
/p:Version=$(Build.BuildNumber) /p:DeployOnBuild=True
/p:PublishProfile=Dev.pubxml /p:AllowUntrustedCertificate=True
/p:Configuration=$(BuildConfiguration)
When the build runs it has no problem with the first project which builds just fine and correctly publishes, but when it then attempts to build the second project it comes up with the error...
Copyright (C) Microsoft Corporation. All rights reserved.
Restoring packages for e:\ci\builds\173\s\JMO.WebAPI\develop\JMOAdmin.WebAPI\JMOAdmin.WebAPI.csproj...
Restore completed in 23.62 ms for e:\ci\builds\173\s\JMO.WebAPI\develop\JMO.DAL\JMO.DAL.csproj.
Restore completed in 78.55 ms for e:\ci\builds\173\s\JMO.WebAPI\develop\JMO.WebAPI\JMO.WebAPI.csproj.
Restore completed in 34.6 ms for e:\ci\builds\173\s\JMO.WebAPI\develop\JMO.WebAPI\JMO.WebAPI.csproj.
Generating MSBuild file e:\ci\builds\173\s\JMO.WebAPI\develop\JMOAdmin.WebAPI\obj\JMOAdmin.WebAPI.csproj.nuget.g.props.
Restore completed in 1.3 sec for e:\ci\builds\173\s\JMO.WebAPI\develop\JMOAdmin.WebAPI\JMOAdmin.WebAPI.csproj.
JMO.DAL -> e:\ci\builds\173\s\JMO.WebAPI\develop\JMO.DAL\bin\dev\netcoreapp2.1\JMO.DAL.dll
CSC : error CS0006: Metadata file 'e:\ci\builds\173\s\JMO.WebAPI\develop\JMO.WebAPI\publish\System.EnterpriseServices.Wrapper.dll' could not be found [e:\ci\builds\173\s\JMO.WebAPI\develop\JMO.WebAPI\JMO.WebAPI.csproj]
Build FAILED.
CSC : error CS0006: Metadata file 'e:\ci\builds\173\s\JMO.WebAPI\develop\JMO.WebAPI\publish\System.EnterpriseServices.Wrapper.dll' could not be found [e:\ci\builds\173\s\JMO.WebAPI\develop\JMO.WebAPI\JMO.WebAPI.csproj]
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:03.71
Error: C:\Program Files\dotnet\dotnet.exe failed with return code: 1
Dotnet command failed with non-zero exit code on the following projects : e:\ci\builds\173\s\JMO.WebAPI\develop\JMOAdmin.WebAPI\JMOAdmin.WebAPI.csproj
Here's the rub though, if I swap the order of the projects in the task it is still the second project that fails to build. What is more, if I add a second dotnet build task so there is one for each project it still does the same - the second build fails with the same error, irrespective of which actual project builds first. The same applies if I use a wildcard for the project file names.
The other thing to note is that the file specified in the error (System.EnterpriseServices.Wrapper.dll) is not to be found in either build's output path anyway, whether the build succeeds or not!
The only way I have found so far to get a successful build of both projects is to use the MultiConfiguration option with a Pass1,Pass2 value and enable/disable the build tasks so that it takes two entire passes at the process, once for the "read-only" WS and one for the admin WS. I'm guessing that something is getting stuck in memory during the first project build process and it's tripping up the second but I can't prove it so far.
My problem with this solution is that this only works on the develop branch, on the release branch I need to use the multi-configuration option for the intended purpose - the various target environments (test, uat, prod).
Short of installing a TFS extension to chain builds (not ideal but viable), can anyone suggest why I'm getting this behaviour and, more importantly, suggest a better solution.
Cheers.
I've been trying to run code analysis of several .Net Core 1.1 projects, but have failed to get any results.
While using VS2015 and the project.json format I successfully sent the command:
../Sonar/tools/sonar-scanner-2.8/bin/sonar-scanner
and the sonar server shows each of the files in project(s) and test projects(s), but no analysis has actually been carried out:
Lines of code = 0
Vulnerabilities = 0
code smells = 0
Having migrated the projects to VS2017 and the csproj format, I can't even get the scan to run.
Running in the main project folder:
SonarQube.Scanner.MSBuild.exe begin /k:"Car.Enquiry-Presenter" /n:"Car.Enquiry-Presenter" /v:"1.0" (no prolems here)
msbuild Car.EnquiryPresenter.csproj
throws error: "error MSB4066: The attribute "Version" in element is unrecognized."
I can see here that the dotnet cli is not yet supported
https://jira.sonarsource.com/browse/SONARMSBRU-310
But this post suggests that it is possible:
https://www.sonarsource.com/resources/product-news/news.html#2017-04-13-sonarqube-scanner-for-msbuild-2-3-released
'support for .NET Core projects: SONARMSBRU-167'
But I've been unable to get this to work.
Can anyone help?
Yes is the answer (great, I get to answer my own question!).
I've just got it working using v15 of MSBuild, but I needed to fully qlaulify the path to the exe, otherwise it continued to use v14:
MSBuild.SonarQube.Runner.exe begin /key:"Car.Enquiry-Presenter" /name:"Car.Enquiry-Presenter" /version:"1.0"
"../../../../Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\msbuild.exe"
MSBuild.SonarQube.Runner.exe end
I also needed to add a 'ProjectGuid' node to my csproj file containing a guid (i just generated that with https://www.guidgen.com/)
NB: Overriding the toolset you use in the csproj file does not force it to use v15. ie: ... .
Hence the fully qualified path.
you need to ensure that the nuget packages are updated using a "dotnet restore" before calling msbuild.exe too.
We have an ASP.NET MVC 4.5 project. For months it has been compiling and all unit tests passing locally on our development machines and on the TeamCity 7.1.5 machine. Monday we updated to newer versions of some of our dependencies (specifically, to get OData 5.0.0-rc1 for select-expand).
The project compiles fine on our development machines and the build machine. It runs fine on our development machines and on both QA environments it's deployed to. All the unit tests pass on our development machines. However, about half (~300) of the unit tests now fail when run from TeamCity using the MSTest build runner, all with the same, useless error:
Unit Test Adapter threw exception:
Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
I've tried everything imaginable. At first I figured there was a legitimate problem. Since there's no way to retrieve the LoaderExceptions property from TeamCity (why doesn't MSTest just display more information!?!?), I logged in to the machine TeamCity is running on, opened up the console, changed into the work directory that our build is running from, and ran the tests manually so that I could retrieve the property. ALL OF THE TESTS PASSED! There goes that theory...
After an entire day of Googling and reading other answers on StackOverflow, I've tried about two dozen different combinations of the following steps:
Changing the build from "Rebuild" to "Clean," running it without tests so that it just cleans, changing it back, and running it again.
Changing the build from "Debug" to "Release," running it, and changing it back again.
Cleaning agent sources from TeamCity admin pages.
Manually deleting entire work directory off of the agents, skipping the recycle bin and going straight to the netherworlds.
Deleting all source control (TFS) caches off the build machine and agents.
Telling TeamCity to clean the work directory before getting latest from source control.
I've reached the end of my troubleshooting capabilities. The tests just won't run anymore on the build machine, for apparently no reason at all.
What can I do? What the heck is going on?
The short answer to this is, "It's a bug."
I reported the bug to JetBrains. It appears that, though there might be some underlying problem with my project, it's only a problem when run from Teamcity, and it's impossible to retrieve the actual error message, so there's no way to know what that problem is. The runner should be catching the exception and printing out the LoaderExceptions property, but it isn't. Instead, it's just calling ToString() on the exception. The runner will have to be updated to look for this specific exception and print the LoaderExceptions property. Once that happens, then we can see the underlying problem, which may result in changing something in the project, or it may result in filing another bug with JetBrains.
Workaround
I spent quite some time debugging our Continuous Integration build failure while experiencing this bug. Since Jetbrains doesn't address the issue, I thought I'd post my workaround here so others have something to work with.
My problem was that the build failed on the step which runs the unit tests. Coincidentally the build which failed added a unit test project. When the newly added unit tests were excluded, everything ran successfully. Because of the reasons stated above and Teamcity not handling the exception properly, debugging options are limited.
I never found a solution which doesn't get your hands dirty, but what you can do is the following. It's basically manually running MSTest versus the test assemblies on the build agent and does require remote desktop access to it. In my case, Teamcity ran the unit tests from the following directory:
C:\BuildAgent\temp\buildTmp[NAME TIMESTAMP]\Out.
Run the following command to initiate the MSTest runner on the assembly which contains failed tests:
C:\BuildAgent\temp\buildTmp\Out>"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\MSTest.exe" /testcontainer:"C:\BuildAgent\temp\buildTmp[NAME TIMESTAMP]\Assembly.With.Failed.Tests.dll"
The output should give you the problem which actually makes the tests fail. In my case it turned out that the new project had a reference to Ploeh.AutoFixture with a different version than the version used in the other unit test projects.
Unable to load the test container 'C:\BuildAgent\temp\buildTmp\Out[NAME TIMESTAMP]\Assembly.With.Failed.Tests.dll' or one of its dependencies. Error details: System.IO.FileLoadException: Could not load file or assembly 'Ploeh.AutoFixture, Version=3.18.10.0, Culture=neutral, PublicKeyToken=b24654c590009d4f' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040).
Specific problem solution
In case you're wondering how to fix a similar issue, you can do the following. Open the package manager console (View -> Other windows -> NuGet Package Manager) and execute the following command.
Install-Package Ploeh.AutoFixture -Version 3.18.10.0
This adds the NuGet package (to the project selected on the dropdown) with a specific version, just make sure that all the projects are aligned in this sense.