[One .NET] fixes for satellite assemblies #5044
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jonathanpeppers
force-pushed
the
destinationsubdirectory
branch
2 times, most recently
from
18f77c5 to
33adda2
Compare
Context: dotnet#5040 In trying to enable our F# MSBuild tests, one fails with: GenerateCompressedAssembliesNativeSourceFiles Xamarin.Android.Common.targets(1933,3): error XAGCANSF7004: System.ArgumentException: An item with the same key has already been added. Key: [FSharp.Core.resources.dll, Xamarin.Android.Tasks.CompressedAssemblyInfo] at System.Collections.Generic.TreeSet`1.AddIfNotPresent(T item) at System.Collections.Generic.SortedDictionary`2.Add(TKey key, TValue value) at Xamarin.Android.Tasks.GenerateCompressedAssembliesNativeSourceFiles.GenerateCompressedAssemblySources() at Xamarin.Android.Tasks.GenerateCompressedAssembliesNativeSourceFiles.RunTask() at Xamarin.Android.Tasks.AndroidTask.Execute() Looking at some of the item groups earlier: C:\src\xamarin-android\packages\xamarin.android.fsharp.resourceprovider\1.0.1\lib\monoandroid81\Xamarin.Android.FSharp.ResourceProvider.Runtime.dll ... DestinationSubPath = Xamarin.Android.FSharp.ResourceProvider.Runtime.dll ... C:\src\xamarin-android\packages\fsharp.core\4.7.2\lib\netstandard2.0\cs\FSharp.Core.resources.dll ... DestinationSubDirectory = cs\ DestinationSubPath = cs\FSharp.Core.resources.dll ... C:\src\xamarin-android\packages\fsharp.core\4.7.2\lib\netstandard2.0\de\FSharp.Core.resources.dll ... DestinationSubDirectory = de\ DestinationSubPath = de\FSharp.Core.resources.dll ... Two instances of `FSharp.Core.resources.dll` is causing the above exception. Should we be using the `%(DestinationSubDirectory)` and `%(DestinationSubPath)` item metadata? Currently, we have some behavior for architecture-specific .NET assemblies: * `%(AbiDirectory)` is set for x86, armeabi-v7a, etc. * `%(IntermediateLinkerOutput)` is set to a full path taking `%(AbiDirectory)` into account. To clean things up here, we should just use `%(DestinationSubDirectory)` coming from dotnet/sdk and `%(DestinationSubPath)` and remove the item data that we invented. Other changes: * Usage of `%(AbiDirectory)` can use `%(DestinationSubDirectory)` or `%(DestinationSubPath)` where appropriate. * Any usage of `%(IntermediateLinkerOutput)` can use `$(MonoAndroidIntermediateAssemblyDir)%(DestinationSubPath)` instead. * The `<ResolveAssemblies/>` (legacy) and `<ProcessAssemblies/>` MSBuild tasks no longer need the `IntermediateAssemblyDirectory` property. * A new check was needed in `<ProcessAssemblies/>` to make sure we don't append `%(DestinationSubDirectory)` for the same assembly multiple times.
jonathanpeppers
force-pushed
the
destinationsubdirectory
branch
from
33adda2 to
fb9e5d5
Compare
Member
Author
|
There is a problem here, let me look into it: |
Member
Author
|
After more review, a build step is failing due to the gradle prints this: And it causes the |
dellis1972
approved these changes
Sep 1, 2020
jonathanpeppers
added a commit
to jonathanpeppers/java.interop
that referenced
this pull request
Sep 3, 2020
Context: dotnet/android#5044 (comment) Context: https://docs.microsoft.com/visualstudio/msbuild/exec-task An env var can break the build such as running the following powershell: > $env:FOO="`nFoo.cs(123,1) error: oh dear!" A `\n` new line in the string is required to hit an issue. This results in a confusing build error: (_BuildJava target) -> EXEC : Foo.cs(123,1) error : oh dear! `gradlew -d` emits every environment variable, and if there is a line that looks like an MSBuild error it will emit the error. We can set `IgnoreStandardErrorWarningFormat="true"` to disable this behavior. This could commonly happen on CI systems, if a commit message contains an error message. In the case of Azure DevOps, `%BUILD_SOURCEVERSIONMESSAGE%` will contain the full commit message. I also fixed the `_CleanJava` target that was not running at all. `java-source-utils.csproj` now properly cleans now.
jonpryor
pushed a commit
to dotnet/java-interop
that referenced
this pull request
Sep 8, 2020
Context: dotnet/android#5044 (comment) Context: https://docs.microsoft.com/visualstudio/msbuild/exec-task An env var can break the build such as running the following powershell: > $env:FOO="`nFoo.cs(123,1) error: oh dear!" A new line in the string is required to hit an issue. (```n`` is PowerShell-ese for a `\n` newline.) This results in a confusing build error: (_BuildJava target) -> EXEC : Foo.cs(123,1) error : oh dear! `gradlew -d` prints every environment variable, and if there is a line that looks like an MSBuild error then `msbuild` will emit the error. We can set `IgnoreStandardErrorWarningFormat="true"` to disable this. This could commonly happen on CI systems, if a commit message contains an error message. In the case of Azure DevOps, `%BUILD_SOURCEVERSIONMESSAGE%` will contain the full commit message. I also fixed the `_CleanJava` target that was not running at all. `java-source-utils.csproj` now properly cleans now.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context: #5040
In trying to enable our F# MSBuild tests, one fails with:
Looking at some of the item groups earlier:
Two instances of
FSharp.Core.resources.dllis causing the aboveexception. Should we be using the
%(DestinationSubDirectory)and%(DestinationSubPath)item metadata?Currently, we have some behavior for architecture-specific .NET
assemblies:
%(AbiDirectory)is set for x86, armeabi-v7a, etc.%(IntermediateLinkerOutput)is set to a full path taking%(AbiDirectory)into account.To clean things up here, we should just use
%(DestinationSubDirectory)coming from dotnet/sdk and%(DestinationSubPath)and remove the item data that we invented.Other changes:
%(AbiDirectory)can use%(DestinationSubDirectory)or%(DestinationSubPath)where appropriate.%(IntermediateLinkerOutput)can use$(MonoAndroidIntermediateAssemblyDir)%(DestinationSubPath)instead.
<ResolveAssemblies/>(legacy) and<ProcessAssemblies/>MSBuild tasks no longer need the
IntermediateAssemblyDirectoryproperty.