Xamarin.Android APK在迁移到Visual Studio Team Services(VSTS)后崩溃 [英] Xamarin.Android APK crashes following migration to Visual Studio Team Services (VSTS)
问题描述
我们已经有了一个移动应用程序(适用于iOS和Android的Xamarin.Forms)，该应用程序正在从本地Team Foundation Server(TFS)迁移到Visual Studio Team Services(VSTS).在过去的几个月中，我们将代码托管在VSTS中，但是已经从本地TFS执行了构建和发布到各个商店的操作.上周晚些时候，我也将构建和发行版定义都迁移到了VSTS，因此现在我们将整个过程都用VSTS进行了.
We've got a mobile application (Xamarin.Forms for iOS and Android) that we've been in the progress of migrating from our on-premise Team Foundation Server (TFS) to Visual Studio Team Services (VSTS). For the last couple of months now we've hosted our code in VSTS but have performed the builds and releases to the respective stores from our on-premise TFS. Late last week I migrated both the build and release definitions to VSTS as well, so that now we have the entire process in VSTS.
所以我想...因为，虽然iOS的构建和发行可以正常运行，而Android的构建和发行也可以，但是 Android应用程序现在在您尝试运行时会崩溃.代码没有重大(读取:否)更改，HockeyApp和我们自己的应用程序自己的错误日志都无法记录崩溃的原因-Google Developer Console也无法为我们提供有关此问题的任何见解.经过几次尝试，我能够从Logcat中获得以下异常:
Or so I thought... For, while the iOS build and release works fine, and Android builds and releases as well, the Android application now crashes when you attempt to run it. No major (read: no) changes have taken place in the code and neither HockeyApp nor our App's own error log are able to record the reason for the crash - nor does the Google Developer Console provide us with any insight for that matter. After a couple of tries I was able to get the following exception out of a Logcat:
I/MonoDroid(21970): UNHANDLED EXCEPTION:
I/MonoDroid(21970): System.ArgumentException: element is not of type Xamarin.Forms.View
I/MonoDroid(21970): Parameter name: element
I/MonoDroid(21970): at Xamarin.Forms.Platform.Android.VisualElementRenderer`1[TElement].Xamarin.Forms.Platform.Android.IVisualElementRenderer.SetElement (Xamarin.Forms.VisualElement element) [0x0001c] in <fa196d4afd1b4356b38d6cf3bb1e4df8>:0
I/MonoDroid(21970): at Xamarin.Forms.Platform.Android.Platform.CreateRenderer (Xamarin.Forms.VisualElement element, Android.Support.V4.App.FragmentManager fragmentManager, Android.Content.Context context) [0x00031] in <fa196d4afd1b4356b38d6cf3bb1e4df8>:0
I/MonoDroid(21970): at Xamarin.Forms.Platform.Android.AppCompat.FragmentContainer.OnCreateView (Android.Views.LayoutInflater inflater, Android.Views.ViewGroup container, Android.OS.Bundle savedInstanceState) [0x0001b] in <fa196d4afd1b4356b38d6cf3bb1e4df8>:0
I/MonoDroid(21970): at Android.Support.V4.App.Fragment.n_OnCreateView_Landroid_view_LayoutInflater_Landroid_view_ViewGroup_Landroid_os_Bundle_ (System.IntPtr jnienv, System.IntPtr native__this, System.IntPtr native_inflater, System.IntPtr native_container, System.IntPtr native_savedInstanceState) [0x00020] in <20045e457c414d37bc46e447a5bb3bb5>:0
I/MonoDroid(21970): at (wrapper dynamic-method) System.Object.b09cff61-6f2e-471d-b43a-8d2949513eb7(intptr,intptr,intptr,intptr,intptr)
现在我们的代码中只有一个地方使用片段，它位于自定义渲染器中，用于扩展我们使用的BottomBarPage的默认实现，而不是Xamarin的默认TabbedPage.因此，我尝试关闭此功能(使用默认的TabbedPage而不是 BottomBarPage 并删除ExportRenderer属性)，但这不能解决问题.当然，我也在线查看了是否可以将错误消息与其他人可能遇到的任何问题相匹配.结果似乎很微不足道，并且不适用于我的情况:清理并重建(我实际上尝试在Xamarin.Android任务中打开Clean-选项，但没有任何效果.)
Now there's only one place in our code where we use fragments, which is in a custom renderer we use to extend the default implementation of the BottomBarPage we use instead of Xamarin's default TabbedPage. I therefore attempted a build with this feature turned off (using the default TabbedPage instead of a BottomBarPage and removing the ExportRenderer-attribute), but this did not solve the problem. Of course I also had a look online to see if I could match the error message with any problem anyone else might have experienced. Results seemed rather meager and not particularly applicable to my case: install the latest version of Xamarin.Forms (which we cannot do at the moment - besides things were working on our private build server) or do a clean and rebuild (I actually tried turning on the Clean-option in our Xamarin.Android-task, but to no effect).
因此，我继续将TFS的最新构建日志与VSTS的最新构建日志进行比较，以查看是否可以发现任何重大差异.事实证明这很棘手，因为两个构建定义之间的输出明显不同.从表面上看，尽管它们执行相同的任务，但它们看起来是相同的.但是我确实注意到，与VSTS托管Mac相比，我们自己的Mac构建服务器同时使用了MS Build和Android Build Tools的更新版本(分别为15.6.0.0和15.4.0.0，以及27.0.1和23.0.0)，所以我决定更改构建环境，因为似乎无法影响构建环境的这些部分，并且无论如何都未明确指定任何版本，则将使用最高安装版本的Android Build Tools(根据
I therefore proceeded to compare the last build log from TFS with a recent one from VSTS to see if I could find any major difference. This turned out to be rather tricky as the output between the two build definitions differs markedly. Superficially, they both look the same, though, performing the same tasks. I did notice, however, that our own Mac build server used newer versions of both MS Build and Android Build Tools than does the VSTS Hosted Mac (15.6.0.0 versus 15.4.0.0 and 27.0.1 versus 23.0.0 respectively), so I decided to change the build environment, as there seems to be no way to influence these parts of the build-environment and the highest installed version of the Android Build Tools will be used when none is explicitly specified anyway (according to https://docs.microsoft.com/en-us/xamarin/android/deploy-test/building-apps/build-process). Running on VS2017 Hosted now at least gives me Android Build Tools version 27.0.3. The JDK-version is the same on all environments, by the way.
构建环境中的开关也无法解决问题，我接下来尝试了以下方法:
With the switch in build-environment also not resolving the issue I next tried the following:
- 关闭AOT编译-尽管对日志的比较显示，最主要的区别在于ID和压缩级别/最终文件大小.
- 已确认我已取消选择使用共享运行时(如建议在此处)，同时选择"armeabi"和"armeabi-v7a"架构进行编译(如建议的
- Turned off AOT-compilation - though a comparison of the log showed that what differed mostly were IDs and compression levels/final file sizes.
- Verified that I deselected to use the shared runtime (as suggested here) and that both "armeabi" and "armeabi-v7a" architectures are selected for compilation (as proposed here).
- Switched from using the Xamarin.Android build-task to using the shell-script which I had built for our on-premise TFS, as the latter's agent had lacked the Xamarin.Android-capability and the script was meant as a work-around.
- Compared the list of Android resources reported by the log as included in the build, which was equal.
- Compared the list of intermediate assemblies reported by both build logs as being packaged and found them to be more or less equal (with the new VSTS-build adding unfamiliar
Mono.Data.Tds.dll- andSystem.Runtime.InteropServices.RuntimeInformation.dll-assemblies). - Performed a per-project comparison of copied files reported by the build logs - something I found of little informative value, since I considered additional assemblies & files reported by VSTS harmless, but am otherwise unable to evaluate the impact of files reported by TFS but not reported by VSTS (in other words, I'm unsure of the informative value of comparing the lists of copied files).
- Verified the list of files reported by both logs as having been signed and zip-aligned (the configuration between TFS and VSTS is completely the same, therefore this task has received little attention in my investigation otherwise).
- Made a build on VSTS from the same branch and commit as the last-known working one made on TFS and compared these using Android Studio's APK analysis/package comparison tool.
只有后者-程序包比较-我发现可以提供很多信息，但是我不知道什么.就是说，人们期望包含完全相同的代码和资源文件的软件包之间几乎没有什么区别，除了Android清单中的版本号.而且的确，这就是我所看到的资产和资源.但是，显着(至少在我看来)，META-INF，lib，classes.dex，assemblies和typemap文件的大小都不同.我不清楚这是什么意思，但是...
Only the latter - the package comparison - I've found to be informative, yet of what I do not know. That is to say, one would expect packages containing exactly the same code and resource files to have little difference among them except for maybe the version numbers in the Android-manifest. And, indeed, this is what I'm seeing for the assets and resources. However, significantly (at least in my opinion), the META-INF, lib, classes.dex, assemblies and typemap-files all differ in size. It is unclear to me what this means, though...
Now about 1.5 days in, the only promising result so far is another post here on Stack Overflow that seems to describe the same symptoms as we're experiencing, yet reports a different exception message in their logcat. No resolution has been posted, however.
我现在比较TFS和VSTS上的Android清单时注意到的一件事是，以下
One thing I've noticed just now when comparing the Android-manifest between builds made on TFS versus those made on VSTS is that the following metadata is lacking from the application-node when building on VSTS (yet is present in local [debug-]builds):
<meta-data
android:name="android.support.VERSION"
android:value="26.1.0" />
我不确定哪个程序包添加了该节点以及它做什么，但是我认为它可能很重要，并将对此进行进一步的调查.
I'm unsure what package adds this node and what it does, however, but feel it might be significant and will be investigating this further.
经过一整天的挫折，尝试了各种不同的库组合(其中有些似乎不想安装在VS2017默认为移动应用程序创建的.NetStandard项目上，而不是默认的旧PCL)，我设法缩小Android清单中以上条目的来源:显然，这是26.1.0 Xamarin Android支持库添加的内容.事实证明，我们的App使用的三个Android项目之一的CS项目文件中的 Xamarin Android支持库之一仍指向旧的26.1.0.1版本，而所有版本其他参考资料已更新为27.0.2.手动更改此条目可确保Android清单中的条目消失.但是，不幸的是，这并没有解决我们的Android版本的App的构建问题...
After a long day of frustration trying all kinds of different combinations of libraries (some of which don't seem to want to install on the .NetStandard projects VS2017 creates for mobile Apps by default instead of the old PCL), I managed to narrow down where the above entry in the Android-manifest comes from: apparently this is something that the version 26.1.0 Xamarin Android support libraries add. It turns out that one of the Xamarin Android support libraries referenced in the CS-project-file of one of the three Android-projects our App uses was still pointing towards an old 26.1.0.1 version, whereas all other references had been updated to 27.0.2. Changing this entry manually ensured that entry in the Android-manifest went away. This, however, did, unfortunately, not solve our build issues with the Android-version of our App...
在托管的VS2017环境上构建现在会产生以下异常消息:
Building on a hosted VS2017 environment now results in the below exception messages:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(2374):C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(2374,3): Error : error XA5101: Missing Android NDK toolchains directory '\toolchains'. Please install the Android NDK. at Xamarin.Android.Tasks.NdkUtil.GetNdkToolchainDirectories(String toolchainsPath, AndroidTargetArch arch) at Xamarin.Android.Tasks.NdkUtil.GetNdkToolchainPath(String androidNdkPath, AndroidTargetArch arch) at Xamarin.Android.Tasks.NdkUtil.GetNdkTool(String androidNdkPath, AndroidTargetArch arch, String tool) at Xamarin.Android.Tasks.NdkUtil.GetNdkToolPrefix(String androidNdkPath, AndroidTargetArch arch) at Xamarin.Android.Tasks.Aot.<GetAotConfigs>d__73.MoveNext() at System.Collections.Concurrent.Partitioner.DynamicPartitionerForIEnumerable`1.InternalPartitionEnumerable.GrabChunk_Buffered(KeyValuePair`2[] destArray, Int32 requestedChunkSize, Int32& actualNumElementsGrabbed) at System.Collections.Concurrent.Partitioner.DynamicPartitionerForIEnumerable`1.InternalPartitionEnumerator.GrabNextChunk(Int32 requestedChunkSize) at System.Collections.Concurrent.Partitioner.DynamicPartitionEnumerator_Abstract`2.MoveNext() at System.Threading.Tasks.Parallel.<>c__DisplayClass42_0`2.<PartitionerForEachWorker>b__1() at System.Threading.Tasks.Task.InnerInvoke() at System.Threading.Tasks.Task.InnerInvokeWithArg(Task childTask) at System.Threading.Tasks.Task.<>c__DisplayClass176_0.<ExecuteSelfReplicating>b__0(Object )
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(2374):C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(2374,3): Error XA3001: System.AggregateException: One or more errors occurred. ---> System.AggregateException: One or more errors occurred. ---> Java.Interop.Tools.Diagnostics.XamarinAndroidException: error XA5101: Missing Android NDK toolchains directory '\toolchains'. Please install the Android NDK. at Xamarin.Android.Tasks.NdkUtil.GetNdkToolchainDirectories(String toolchainsPath, AndroidTargetArch arch) at Xamarin.Android.Tasks.NdkUtil.GetNdkToolchainPath(String androidNdkPath, AndroidTargetArch arch) at Xamarin.Android.Tasks.NdkUtil.GetNdkTool(String androidNdkPath, AndroidTargetArch arch, String tool) at Xamarin.Android.Tasks.NdkUtil.GetNdkToolPrefix(String androidNdkPath, AndroidTargetArch arch) at Xamarin.Android.Tasks.Aot.<GetAotConfigs>d__73.MoveNext() at System.Collections.Concurrent.Partitioner.DynamicPartitionerForIEnumerable`1.InternalPartitionEnumerable.GrabChunk_Buffered(KeyValuePair`2[] destArray, Int32 requestedChunkSize, Int32& actualNumElementsGrabbed) at System.Collections.Concurrent.Partitioner.DynamicPartitionerForIEnumerable`1.InternalPartitionEnumerator.GrabNextChunk(Int32 requestedChunkSize) at System.Collections.Concurrent.Partitioner.DynamicPartitionEnumerator_Abstract`2.MoveNext() at System.Threading.Tasks.Parallel.<>c__DisplayClass42_0`2.<PartitionerForEachWorker>b__1() at System.Threading.Tasks.Task.InnerInvoke() at System.Threading.Tasks.Task.InnerInvokeWithArg(Task childTask) at System.Threading.Tasks.Task.<>c__DisplayClass176_0.<ExecuteSelfReplicating>b__0(Object ) --- End of inner exception stack trace --- at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions) at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken) at System.Threading.Tasks.Task.Wait() at System.Threading.Tasks.Parallel.PartitionerForEachWorker[TSource,TLocal](Partitioner`1 source, ParallelOptions parallelOptions, Action`1 simpleBody, Action`2 bodyWithState, Action`3 bodyWithStateAndIndex, Func`4 bodyWithStateAndLocal, Func`5 bodyWithEverything, Func`1 localInit, Action`1 localFinally) at System.Threading.Tasks.Parallel.ForEachWorker[TSource,TLocal](IEnumerable`1 source, ParallelOptions parallelOptions, Action`1 body, Action`2 bodyWithState, Action`3 bodyWithStateAndIndex, Func`4 bodyWithStateAndLocal, Func`5 bodyWithEverything, Func`1 localInit, Action`1 localFinally) at System.Threading.Tasks.Parallel.ForEach[TSource](IEnumerable`1 source, ParallelOptions parallelOptions, Action`1 body) at Xamarin.Android.Tasks.Aot.RunParallelAotCompiler(List`1 nativeLibs) at Xamarin.Android.Tasks.Aot.<>c__DisplayClass71_0.<DoExecute>b__0() at System.Threading.Tasks.Task`1.InnerInvoke() at System.Threading.Tasks.Task.Execute() --- End of inner exception stack trace --- at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions) at System.Threading.Tasks.Task`1.GetResultCore(Boolean waitCompletionNotification) at System.Threading.Tasks.Task`1.get_Result() at Xamarin.Android.Tasks.Aot.DoExecute() at Xamarin.Android.Tasks.Aot.Execute() ---> (Inner Exception #0) System.AggregateException: One or more errors occurred. ---> Java.Interop.Tools.Diagnostics.XamarinAndroidException: error XA5101: Missing Android NDK toolchains directory '\toolchains'. Please install the Android NDK. at Xamarin.Android.Tasks.NdkUtil.GetNdkToolchainDirectories(String toolchainsPath, AndroidTargetArch arch) at Xamarin.Android.Tasks.NdkUtil.GetNdkToolchainPath(String androidNdkPath, AndroidTargetArch arch) at Xamarin.Android.Tasks.NdkUtil.GetNdkTool(String androidNdkPath, AndroidTargetArch arch, String tool) at Xamarin.Android.Tasks.NdkUtil.GetNdkToolPrefix(String androidNdkPath, AndroidTargetArch arch) at Xamarin.Android.Tasks.Aot.<GetAotConfigs>d__73.MoveNext() at System.Collections.Concurrent.Partitioner.DynamicPartitionerForIEnumerable`1.InternalPartitionEnumerable.GrabChunk_Buffered(KeyValuePair`2[] destArray, Int32 requestedChunkSize, Int32& actualNumElementsGrabbed) at System.Collections.Concurrent.Partitioner.DynamicPartitionerForIEnumerable`1.InternalPartitionEnumerator.GrabNextChunk(Int32 requestedChunkSize) at System.Collections.Concurrent.Partitioner.DynamicPartitionEnumerator_Abstract`2.MoveNext() at System.Threading.Tasks.Parallel.<>c__DisplayClass42_0`2.<PartitionerForEachWorker>b__1() at System.Threading.Tasks.Task.InnerInvoke() at System.Threading.Tasks.Task.InnerInvokeWithArg(Task childTask) at System.Threading.Tasks.Task.<>c__DisplayClass176_0.<ExecuteSelfReplicating>b__0(Object ) --- End of inner exception stack trace --- at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions) at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken) at System.Threading.Tasks.Task.Wait() at System.Threading.Tasks.Parallel.PartitionerForEachWorker[TSource,TLocal](Partitioner`1 source, ParallelOptions parallelOptions, Action`1 simpleBody, Action`2 bodyWithState, Action`3 bodyWithStateAndIndex, Func`4 bodyWithStateAndLocal, Func`5 bodyWithEverything, Func`1 localInit, Action`1 localFinally) at System.Threading.Tasks.Parallel.ForEachWorker[TSource,TLocal](IEnumerable`1 source, ParallelOptions parallelOptions, Action`1 body, Action`2 bodyWithState, Action`3 bodyWithStateAndIndex, Func`4 bodyWithStateAndLocal, Func`5 bodyWithEverything, Func`1 localInit, Action`1 localFinally) at System.Threading.Tasks.Parallel.ForEach[TSource](IEnumerable`1 source, ParallelOptions parallelOptions, Action`1 body) at Xamarin.Android.Tasks.Aot.RunParallelAotCompiler(List`1 nativeLibs) at Xamarin.Android.Tasks.Aot.<>c__DisplayClass71_0.<DoExecute>b__0() at System.Threading.Tasks.Task`1.InnerInvoke() at System.Threading.Tasks.Task.Execute() ---> (Inner Exception #0) Java.Interop.Tools.Diagnostics.XamarinAndroidException: error XA5101: Missing Android NDK toolchains directory '\toolchains'. Please install the Android NDK. at Xamarin.Android.Tasks.NdkUtil.GetNdkToolchainDirectories(String toolchainsPath, AndroidTargetArch arch) at Xamarin.Android.Tasks.NdkUtil.GetNdkToolchainPath(String androidNdkPath, AndroidTargetArch arch) at Xamarin.Android.Tasks.NdkUtil.GetNdkTool(String androidNdkPath, AndroidTargetArch arch, String tool) at Xamarin.Android.Tasks.NdkUtil.GetNdkToolPrefix(String androidNdkPath, AndroidTargetArch arch) at Xamarin.Android.Tasks.Aot.<GetAotConfigs>d__73.MoveNext() at System.Collections.Concurrent.Partitioner.DynamicPartitionerForIEnumerable`1.InternalPartitionEnumerable.GrabChunk_Buffered(KeyValuePair`2[] destArray, Int32 requestedChunkSize, Int32& actualNumElementsGrabbed) at System.Collections.Concurrent.Partitioner.DynamicPartitionerForIEnumerable`1.InternalPartitionEnumerator.GrabNextChunk(Int32 requestedChunkSize) at System.Collections.Concurrent.Partitioner.DynamicPartitionEnumerator_Abstract`2.MoveNext() at System.Threading.Tasks.Parallel.<>c__DisplayClass42_0`2.<PartitionerForEachWorker>b__1() at System.Threading.Tasks.Task.InnerInvoke() at System.Threading.Tasks.Task.InnerInvokeWithArg(Task childTask) at System.Threading.Tasks.Task.<>c__DisplayClass176_0.<ExecuteSelfReplicating>b__0(Object )<--- <---
Process 'msbuild.exe' exited with code '1'.
据我所知，我不是使用Android NDK，所以我不太明白为什么现在会收到此异常消息.但是，VSTS托管的Mac环境似乎还没有遇到这些问题，因此，我将切换回在Mac上进行构建.
I'm not - as far as I'm aware - using the Android NDK, so I don't quite understand why I'm getting this exception message now. However, the VSTS hosted Mac environment doesn't seem to experience these problems (yet), so I'm switching back to building on Mac.
进行了一些搜索，显然以上异常消息是由于Visual Studio从15.6版自动更新到最近发生的版本15.7所引起的问题(
Did some searching, and apparently the above exception messages are due to problems with the automated update of Visual Studio from version 15.6 to version 15.7, which recently took place (source). Always nice to see these things being checked global roll-out.
因此，自上次更新以来，我尝试了一些其他操作:将Xamarin.Android使用的JDK版本明确设置为版本8 ，并将JDK体系结构设置为 x64 (如此处所述)；并删除所有Android自定义渲染器，因为原始异常似乎指向VisualElementRenderer<TElement>，这是几乎所有(如果不是全部)默认渲染器和自定义渲染器的基类.但是，所有这些都无济于事，所以我怀疑抛出的异常源自Xamarin.Forms本身.
So here are some further things I've tried since the last update: explicitly setting the JDK-version used by Xamarin.Android to version 8 and the JDK Architecture to x64 (as described here); and removing all custom renderers for Android, since the original exception seems to point at the VisualElementRenderer<TElement>, which is the base class for almost all (if not all) default and custom renderers. All of this to no avail, however, so that I suspect the exception thrown derives from within Xamarin.Forms itself.
我们终于尝试将用于TFS内部构建流程的Mac作为私有构建代理添加到VSTS，这是一件非常容易的事！我们甚至不需要更改防火墙配置，因为似乎代理与服务器建立了连接(通过HTTP和HTTPS)，而不是相反(我们遵循了
We finally tried adding the Mac we use for our internal build flow in TFS as a private build agent to VSTS today, which was a surprisingly easy thing to do! We didn't even need to change our firewall configuration, as it seems that the agent makes connection with the server (across HTTP and HTTPS), not the other way around (we followed the steps described here). I would that all installations were this easy!
尽管配置私有构建代理很容易，但是无论是使用Xamarin.Android构建任务还是自定义构建脚本(我们以前在TFS内的同一台机器成功).
Notwithstanding the ease with which we configured our private build agent, we still experienced the same crash following builds, irrespective of whether we built with the Xamarin.Android build-task or our custom build script (which we had previously used on the very same machine from within TFS with success).
我们最终遵循了此处.但是，由于我刚巧将我们的Xamarin.Forms版本从2.5.1.444934版本更新到了前一天的2.5.1.527436版本，我决定尝试使用此代码运行构建.原来是行得通的！我不知道为什么，但是...我想这与重新构建无关紧要！
We did eventually bump into the solution by following up on a suggestion made here, however, something that seemed somewhat unrelated and not pertinent before. Yet, as I had coincidentally just updated the version of our Xamarin.Forms from version 2.5.1.444934 to version 2.5.1.527436 the day before, I decided to try running a build with this code. Which turned out to work! I've got no clue why though... But I guess that's less relevant than being able to build again!
推荐答案
事实证明，更新Xamarin.Forms是解决方案.
Though suggested as resolution to the same error as ours on the Xamarin forums, and something I had come across before, the age of the post and the old version of Xamarin.Forms involved made me disregard this option as less relevant to our problem. What didn't help either was that I thought we were already on the highest version of Xamarin.Forms 2.5.1, and are not quite ready to move to Xamarin.Forms 3.0 yet. Yesterday, however, I discovered there was still a revision we could upgrade within the 2.5.1-branch, which is what I did. When I then tried a build with this code, surprisingly the resulting APK turned out to run without any issue!
但是，我们不清楚更新Xamarin.Forms的原因.但是，我们确实注意到，该特定版本的 Xamarin.Forms 2.5.1.527436 是在将构建定义从TFS迁移到VSTS之前大约一周发布的.因此，可能存在某种相关性.
The reason why updating Xamarin.Forms works is unclear to us, though. We did, however, observe that this particular version of Xamarin.Forms, 2.5.1.527436, was released just about a week before I migrated our build definition from TFS to VSTS. It might therefore be that there's some correlation there.
今天Xamarin.Forms 2.5.1.527436遇到了一些麻烦，最终导致我在创建我们应用的Android版本时遇到了问题的最可能原因.也就是说，为了解决Xamarin.Forms导致的崩溃，我试图将Forms还原到我知道仍然可以使用的最新版本.但是，即使在降级之后，Xamarin.Forms的问题仍然存在.这触发了我检查项目文件，并将该应用程序的工作版本与已降级的应用程序进行了比较，尽管如此，其最终版本应该相同.
Ran into some trouble with Xamarin.Forms 2.5.1.527436 today, which has eventually led me to the most likely cause for our problems creating an Android build of our App. That is, in order to resolve a crash caused by Xamarin.Forms, I tried to revert Forms to the last version I knew still worked. However, the problem with Xamarin.Forms persisted, even after the downgrade. This triggered me to inspect the project-files and compare the working version of the App to that which had been downgraded, yet should have ended up the same notwithstanding.
事实证明，一些项目文件引用了两个不同版本的Xamarin.Forms :一个我打算使用的版本，一个我们以前使用过的版本.现在，这种混合在本地开发计算机上运行时不会引起任何问题，因为该计算机将同时安装新旧版本的Xamarin.Forms，因此不会缺少任何程序集.但是，我可以想象，在构建服务器上运行VSTS构建时，情况并非如此.此外，包含不正确的程序集引用的项目文件都是Android项目-这说明了iOS在构建时没有问题的原因！！
As it turns out some project files had references to two different versions of Xamarin.Forms: the one that I had intended to use, and the one we had been using before that. Now this mixture didn't cause any problems while running on a local development machine, since this machine would have both old and new versions of Xamarin.Forms installed and there would therefore not be any missing assemblies. However, I can imagine that this would not be the case when running a VSTS-build on a build-server. Moreover, the project files containing the incorrect assembly references were both Android projects - which explains why iOS had no trouble building...!
这篇关于Xamarin.Android APK在迁移到Visual Studio Team Services(VSTS)后崩溃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
