Encountering linker failure on macOS on partial build after changing the project TargetFrameworkVersion #2584
Assignees
Labels
Area: App+Library Build
Issues when building Library projects or Application projects.
Area: Linker
Issues when linking assemblies.
Milestone
Comments
pjcollins
added
Area: App+Library Build
|
This looks like we are not invalidating the linker cache when the build.props changes.. |
|
I could repro this on Windows when setting So there is something wrong when bumping TFV's, we should fix this and test for it since it affects Mac users. |
jonathanpeppers
added a commit
to jonathanpeppers/xamarin-android
that referenced
this issue
Jul 29, 2019
Fixes: dotnet#2584 Building a project with two different `$(TargetFrameworkVersion)`: msbuild /p:Configuration=Release /p:TargetFrameworkVersion=v4.4 msbuild /t:Configuration=Release /p:TargetFrameworkVersion=v9.0 Results in a build error: error MSB4018: The "LinkAssemblies" task failed unexpectedly. Mono.Linker.MarkException: Error processing method: 'System.Void BatchStepSensor.BatchStepSensorFragment::OnSaveInstanceState(Android.OS.Bundle)' in assembly: 'BatchStepSensor.dll' ---> Mono.Cecil.ResolutionException: Failed to resolve System.Void Android.OS.BaseBundle::PutInt(System.String,System.Int32) at Mono.Linker.Steps.MarkStep.HandleUnresolvedMethod(MethodReference reference) at Mono.Linker.Steps.MarkStep.MarkMethod(MethodReference reference) at Mono.Linker.Steps.MarkStep.MarkInstruction(Instruction instruction) at Mono.Linker.Steps.MarkStep.MarkMethodBody(MethodBody body) at Mono.Linker.Steps.MarkStep.ProcessMethod(MethodDefinition method) at Mono.Linker.Steps.MarkStep.ProcessQueue() --- End of inner exception stack trace --- at Mono.Linker.Steps.MarkStep.ProcessQueue() at Mono.Linker.Steps.MarkStep.ProcessPrimaryQueue() at Mono.Linker.Steps.MarkStep.Process() at MonoDroid.Tuner.MonoDroidMarkStep.Process(LinkContext context) at Mono.Linker.Pipeline.ProcessStep(LinkContext context, IStep step) at Mono.Linker.Pipeline.Process(LinkContext context) at MonoDroid.Tuner.Linker.Process(LinkerOptions options, ILogger logger, LinkContext& context) at Xamarin.Android.Tasks.LinkAssemblies.Execute(DirectoryAssemblyResolver res) at Xamarin.Android.Tasks.LinkAssemblies.Execute() at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext() Which is due to an outdated `Mono.Android.dll` in the `obj` directory: Target Name=_CopyIntermediateAssemblies CopyIfChanged ... Skipping C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\ReferenceAssemblies\Microsoft\Framework\MonoAndroid\v9.0\Mono.Android.dll its up to date ... ModifiedFiles: obj\Release\linksrc\BatchStepSensor.dll Reviewing the `<CopyIfChanged/>` MSBuild task, there is a code path where the copy is skipped if the source file is newer than the destination. In the case of modifying `$(TargetFrameworkVersion)` on an incremental build, a *different* `Mono.Android.dll` would have an older timestamp. The copy would be skipped. A fix here is to *also* check the size of the source and destination files, and only allow the copy to be skipped if the sizes match.
jonathanpeppers
added a commit
to jonathanpeppers/xamarin-android
that referenced
this issue
Jul 30, 2019
Fixes: dotnet#2584 Building a project with two different `$(TargetFrameworkVersion)`: msbuild /p:Configuration=Release /p:TargetFrameworkVersion=v4.4 msbuild /t:Configuration=Release /p:TargetFrameworkVersion=v9.0 Results in a build error: error MSB4018: The "LinkAssemblies" task failed unexpectedly. Mono.Linker.MarkException: Error processing method: 'System.Void BatchStepSensor.BatchStepSensorFragment::OnSaveInstanceState(Android.OS.Bundle)' in assembly: 'BatchStepSensor.dll' ---> Mono.Cecil.ResolutionException: Failed to resolve System.Void Android.OS.BaseBundle::PutInt(System.String,System.Int32) at Mono.Linker.Steps.MarkStep.HandleUnresolvedMethod(MethodReference reference) at Mono.Linker.Steps.MarkStep.MarkMethod(MethodReference reference) at Mono.Linker.Steps.MarkStep.MarkInstruction(Instruction instruction) at Mono.Linker.Steps.MarkStep.MarkMethodBody(MethodBody body) at Mono.Linker.Steps.MarkStep.ProcessMethod(MethodDefinition method) at Mono.Linker.Steps.MarkStep.ProcessQueue() --- End of inner exception stack trace --- at Mono.Linker.Steps.MarkStep.ProcessQueue() at Mono.Linker.Steps.MarkStep.ProcessPrimaryQueue() at Mono.Linker.Steps.MarkStep.Process() at MonoDroid.Tuner.MonoDroidMarkStep.Process(LinkContext context) at Mono.Linker.Pipeline.ProcessStep(LinkContext context, IStep step) at Mono.Linker.Pipeline.Process(LinkContext context) at MonoDroid.Tuner.Linker.Process(LinkerOptions options, ILogger logger, LinkContext& context) at Xamarin.Android.Tasks.LinkAssemblies.Execute(DirectoryAssemblyResolver res) at Xamarin.Android.Tasks.LinkAssemblies.Execute() at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext() Which is due to an outdated `Mono.Android.dll` in the `obj` directory: Target Name=_CopyIntermediateAssemblies CopyIfChanged ... Skipping C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\ReferenceAssemblies\Microsoft\Framework\MonoAndroid\v9.0\Mono.Android.dll its up to date ... ModifiedFiles: obj\Release\linksrc\BatchStepSensor.dll Reviewing the `<CopyIfChanged/>` MSBuild task, there is a code path where the copy is skipped if the source file is newer than the destination. In the case of modifying `$(TargetFrameworkVersion)` on an incremental build, a *different* `Mono.Android.dll` would have an older timestamp. The copy would be skipped. A fix here is to *also* check the size of the source and destination files, and only allow the copy to be skipped if the sizes match.
jonathanpeppers
added a commit
to jonathanpeppers/xamarin-android
that referenced
this issue
Jul 30, 2019
Fixes: dotnet#2584 Building a project with two different `$(TargetFrameworkVersion)`: msbuild /p:Configuration=Release /p:TargetFrameworkVersion=v4.4 msbuild /t:Configuration=Release /p:TargetFrameworkVersion=v9.0 Results in a build error: error MSB4018: The "LinkAssemblies" task failed unexpectedly. Mono.Linker.MarkException: Error processing method: 'System.Void BatchStepSensor.BatchStepSensorFragment::OnSaveInstanceState(Android.OS.Bundle)' in assembly: 'BatchStepSensor.dll' ---> Mono.Cecil.ResolutionException: Failed to resolve System.Void Android.OS.BaseBundle::PutInt(System.String,System.Int32) at Mono.Linker.Steps.MarkStep.HandleUnresolvedMethod(MethodReference reference) at Mono.Linker.Steps.MarkStep.MarkMethod(MethodReference reference) at Mono.Linker.Steps.MarkStep.MarkInstruction(Instruction instruction) at Mono.Linker.Steps.MarkStep.MarkMethodBody(MethodBody body) at Mono.Linker.Steps.MarkStep.ProcessMethod(MethodDefinition method) at Mono.Linker.Steps.MarkStep.ProcessQueue() --- End of inner exception stack trace --- at Mono.Linker.Steps.MarkStep.ProcessQueue() at Mono.Linker.Steps.MarkStep.ProcessPrimaryQueue() at Mono.Linker.Steps.MarkStep.Process() at MonoDroid.Tuner.MonoDroidMarkStep.Process(LinkContext context) at Mono.Linker.Pipeline.ProcessStep(LinkContext context, IStep step) at Mono.Linker.Pipeline.Process(LinkContext context) at MonoDroid.Tuner.Linker.Process(LinkerOptions options, ILogger logger, LinkContext& context) at Xamarin.Android.Tasks.LinkAssemblies.Execute(DirectoryAssemblyResolver res) at Xamarin.Android.Tasks.LinkAssemblies.Execute() at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext() Which is due to an outdated `Mono.Android.dll` in the `obj` directory: Target Name=_CopyIntermediateAssemblies CopyIfChanged ... Skipping C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\ReferenceAssemblies\Microsoft\Framework\MonoAndroid\v9.0\Mono.Android.dll its up to date ... ModifiedFiles: obj\Release\linksrc\BatchStepSensor.dll Reviewing the `<CopyIfChanged/>` MSBuild task, there is a code path where the copy is skipped if the source file is newer than the destination. In the case of modifying `$(TargetFrameworkVersion)` on an incremental build, a *different* `Mono.Android.dll` would have an older timestamp. The copy would be skipped. A fix here is to *also* check the size of the source and destination files, and only allow the copy to be skipped if the sizes match. ~~ _ConvertResourcesCases ~~ These changes surfaced a bug in the `_ConvertResourcesCases` target`, if `build.props` changes then: * The `_CompileResources` target runs * `_ConvertResourcesCases` is skipped... And you get a build error such as: Resources\layout\test.axml(3): error APT0000: resource drawable/IMALLCAPS (aka UnnamedProject.UnnamedProject:drawable/IMALLCAPS) not found. The solution here is to make the `Inputs` of `_CompileResources` and `_ConvertResourcesCases` the same. I also adjusted a test to check both aapt and aapt2.
jonpryor
pushed a commit
that referenced
this issue
Aug 1, 2019
Fixes: #2584 Building a project with two different `$(TargetFrameworkVersion)`: msbuild /p:Configuration=Release /p:TargetFrameworkVersion=v4.4 msbuild /t:Configuration=Release /p:TargetFrameworkVersion=v9.0 Results in a build error: error MSB4018: The "LinkAssemblies" task failed unexpectedly. Mono.Linker.MarkException: Error processing method: 'System.Void BatchStepSensor.BatchStepSensorFragment::OnSaveInstanceState(Android.OS.Bundle)' in assembly: 'BatchStepSensor.dll' ---> Mono.Cecil.ResolutionException: Failed to resolve System.Void Android.OS.BaseBundle::PutInt(System.String,System.Int32) at Mono.Linker.Steps.MarkStep.HandleUnresolvedMethod(MethodReference reference) at Mono.Linker.Steps.MarkStep.MarkMethod(MethodReference reference) at Mono.Linker.Steps.MarkStep.MarkInstruction(Instruction instruction) at Mono.Linker.Steps.MarkStep.MarkMethodBody(MethodBody body) at Mono.Linker.Steps.MarkStep.ProcessMethod(MethodDefinition method) at Mono.Linker.Steps.MarkStep.ProcessQueue() --- End of inner exception stack trace --- at Mono.Linker.Steps.MarkStep.ProcessQueue() at Mono.Linker.Steps.MarkStep.ProcessPrimaryQueue() at Mono.Linker.Steps.MarkStep.Process() at MonoDroid.Tuner.MonoDroidMarkStep.Process(LinkContext context) at Mono.Linker.Pipeline.ProcessStep(LinkContext context, IStep step) at Mono.Linker.Pipeline.Process(LinkContext context) at MonoDroid.Tuner.Linker.Process(LinkerOptions options, ILogger logger, LinkContext& context) at Xamarin.Android.Tasks.LinkAssemblies.Execute(DirectoryAssemblyResolver res) at Xamarin.Android.Tasks.LinkAssemblies.Execute() at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext() Which is due to an outdated `Mono.Android.dll` in the `obj` directory: Target Name=_CopyIntermediateAssemblies CopyIfChanged ... Skipping C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\ReferenceAssemblies\Microsoft\Framework\MonoAndroid\v9.0\Mono.Android.dll its up to date ... ModifiedFiles: obj\Release\linksrc\BatchStepSensor.dll Reviewing the `<CopyIfChanged/>` MSBuild task, there is a code path where the copy is skipped if the source file is newer than the destination. In the case of modifying `$(TargetFrameworkVersion)` on an incremental build, a *different* `Mono.Android.dll` would have an older timestamp. The copy would be skipped. A fix here is to *also* check the size of the source and destination files, and only allow the copy to be skipped if the sizes match. ~~ _ConvertResourcesCases ~~ These changes surfaced a bug in the `_ConvertResourcesCases` target`; if `build.props` changes then: * The `_CompileResources` target runs * The `_ConvertResourcesCases` target is skipped (!) And you get a build error such as: Resources\layout\test.axml(3): error APT0000: resource drawable/IMALLCAPS (aka UnnamedProject.UnnamedProject:drawable/IMALLCAPS) not found. The solution here is to make the `Inputs` of `_CompileResources` and `_ConvertResourcesCases` the same. I also adjusted a test to check both `aapt` and `aapt2`.
jonpryor
pushed a commit
that referenced
this issue
Aug 9, 2019
Fixes: #2584 Building a project with two different `$(TargetFrameworkVersion)`: msbuild /p:Configuration=Release /p:TargetFrameworkVersion=v4.4 msbuild /t:Configuration=Release /p:TargetFrameworkVersion=v9.0 Results in a build error: error MSB4018: The "LinkAssemblies" task failed unexpectedly. Mono.Linker.MarkException: Error processing method: 'System.Void BatchStepSensor.BatchStepSensorFragment::OnSaveInstanceState(Android.OS.Bundle)' in assembly: 'BatchStepSensor.dll' ---> Mono.Cecil.ResolutionException: Failed to resolve System.Void Android.OS.BaseBundle::PutInt(System.String,System.Int32) at Mono.Linker.Steps.MarkStep.HandleUnresolvedMethod(MethodReference reference) at Mono.Linker.Steps.MarkStep.MarkMethod(MethodReference reference) at Mono.Linker.Steps.MarkStep.MarkInstruction(Instruction instruction) at Mono.Linker.Steps.MarkStep.MarkMethodBody(MethodBody body) at Mono.Linker.Steps.MarkStep.ProcessMethod(MethodDefinition method) at Mono.Linker.Steps.MarkStep.ProcessQueue() --- End of inner exception stack trace --- at Mono.Linker.Steps.MarkStep.ProcessQueue() at Mono.Linker.Steps.MarkStep.ProcessPrimaryQueue() at Mono.Linker.Steps.MarkStep.Process() at MonoDroid.Tuner.MonoDroidMarkStep.Process(LinkContext context) at Mono.Linker.Pipeline.ProcessStep(LinkContext context, IStep step) at Mono.Linker.Pipeline.Process(LinkContext context) at MonoDroid.Tuner.Linker.Process(LinkerOptions options, ILogger logger, LinkContext& context) at Xamarin.Android.Tasks.LinkAssemblies.Execute(DirectoryAssemblyResolver res) at Xamarin.Android.Tasks.LinkAssemblies.Execute() at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext() Which is due to an outdated `Mono.Android.dll` in the `obj` directory: Target Name=_CopyIntermediateAssemblies CopyIfChanged ... Skipping C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\ReferenceAssemblies\Microsoft\Framework\MonoAndroid\v9.0\Mono.Android.dll its up to date ... ModifiedFiles: obj\Release\linksrc\BatchStepSensor.dll Reviewing the `<CopyIfChanged/>` MSBuild task, there is a code path where the copy is skipped if the source file is newer than the destination. In the case of modifying `$(TargetFrameworkVersion)` on an incremental build, a *different* `Mono.Android.dll` would have an older timestamp. The copy would be skipped. A fix here is to *also* check the size of the source and destination files, and only allow the copy to be skipped if the sizes match. ~~ _ConvertResourcesCases ~~ These changes surfaced a bug in the `_ConvertResourcesCases` target`; if `build.props` changes then: * The `_CompileResources` target runs * The `_ConvertResourcesCases` target is skipped (!) And you get a build error such as: Resources\layout\test.axml(3): error APT0000: resource drawable/IMALLCAPS (aka UnnamedProject.UnnamedProject:drawable/IMALLCAPS) not found. The solution here is to make the `Inputs` of `_CompileResources` and `_ConvertResourcesCases` the same. I also adjusted a test to check both `aapt` and `aapt2`.
|
Fix included in Xamarin.Android 10.0.0.40. Fix included on Windows in Visual Studio 2019 version 16.3 Preview 3. To try the preview version that includes the fix, check for the latest updates in Visual Studio Preview. Fix included on macOS in Visual Studio 2019 for Mac version 8.3 Preview 3. To try the preview version that includes the fix, check for the latest updates on the Preview updater channel. |
|
A new Release version has now been published that includes the fix for this item. Fix included in Xamarin.Android 10.0.0.43 Fix included on Windows in Visual Studio 2019 version 16.3. To get the new version that includes the fix, check for the latest updates or install the latest version from https://visualstudio.microsoft.com/downloads/. Fix included on macOS in Visual Studio 2019 for Mac version 8.3. To get the new version that includes the fix, check for the latest updates on the Stable updater channel. |
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I'm not sure if this particular scenario represents a "valid" bug per-say, but the behavior described below has started occurring somewhere between d15-9 and d16-0. This incremental build failure also only occurs when linking on macOS, and is not reproducible on Windows. Perhaps this is related to the difference in target framework versions of the app and library projects used in this repro (app currently targets v4.4 while the lib is targeting v8.1).
Steps to Reproduce
msbuild /t:SignAndroidPackage /p:Configuration=Release BatchStepSensor/BatchStepSensor/BatchStepSensor.csprojmsbuild /t:SignAndroidPackage /p:Configuration=Release BatchStepSensor/BatchStepSensor/BatchStepSensor.csprojmsbuild /t:SignAndroidPackage /p:TargetFrameworkVersion=v9.0 /p:Configuration=Release BatchStepSensor/BatchStepSensor/BatchStepSensor.csprojExpected Behavior
My third build attempt (which includes a property change) will succeed.
Alternatively, perhaps in this case the app framework version < lib framework version warning[0] just needs to be respected.$(TargetFrameworkVersion) for CommonSampleLibrary (v8.1) is greater than the $ (TargetFrameworkVersion) for your project (v4.4). You need to increase the $(TargetFrameworkVersion) for your project.
[0] warning XA0105: The
Actual Behavior
Version Information
Visual Studio Enterprise 2017 for Mac
Version 7.7.2 (build 21)
Installation UUID: 57d9d5c5-f091-4a0a-af36-7330b1af94d2
GTK+ 2.24.23 (Raleigh theme)
Xamarin.Mac 4.4.1.178 (master / eeaeb7e6)
Package version: 518000225
Mono Framework MDK
Runtime:
Mono 5.18.0.225 (2018-08/bac9fc1f889) (64-bit)
Package version: 518000225
XA Version: 9.1.103.6 (Visual Studio Enterprise)
Log File
https://gist.githubusercontent.com/pjcollins/e915663f696828abaac25e66a1fa49ca/raw/1e48937f1543223975176ec676adc46fddc8dfc1/gistfile1.txt
The text was updated successfully, but these errors were encountered: