Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[build] Set $(TargetFrameworkRootPath) #79

Merged
merged 1 commit into from
Jun 14, 2016

Conversation

jonpryor
Copy link
Member

@jonpryor jonpryor commented Jun 14, 2016

@atsushieno and I are trying to figure out why src/Mono.Posix builds
for me on OS X but fails for him in a (relatively) clean Linux
environment:

CSC: error CS0518: The predefined type `System.Object' is not defined or imported

System.Object couldn't be found because System.Runtime.dll wasn't
being provided to the compiler.

Further investigation shows that the reason it built on OS X was
because OS X had a pre-existing system Xamarin.Android install, which
was being used to resolve framework directories:

# Works on OS X:
# Note: Mono.framework/External/xbuild-frameworks/MonoAndroid is a symlink
#   into Xamarin.Android.framework, i.e. the system Xamarin.Android install
Task "GetReferenceAssemblyPaths"
    Using task GetReferenceAssemblyPaths from Microsoft.Build.Tasks.GetReferenceAssemblyPaths, Microsoft.Build.Tasks.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
    Looking for framework 'MonoAndroid,Version=v1.0' in root path '/Library/Frameworks/Mono.framework/External/xbuild-frameworks'
    Found framework definition list '/Library/Frameworks/Mono.framework/External/xbuild-frameworks/MonoAndroid/v1.0/RedistList/FrameworkList.xml' for framework 'MonoAndroid,Version=v1.0'
Done executing task "GetReferenceAssemblyPaths"

# Fails on Linux:
Target _GetReferenceAssemblyPaths:
    warning : Unable to find framework corresponding to the target framework moniker 'MonoAndroid,Version=v1.0'. Framework assembly references will be resolved from the GAC, which might not be the intended behavior.

Turns Out™, the error can be reproduced on OS X by "removing" the
system Xamarin.Android install:

$ cd /Library/Frameworks/Mono.framework/External/xbuild-frameworks
$ sudo mv MonoAndroid _MonoAndroid

Task "GetReferenceAssemblyPaths"
    Using task GetReferenceAssemblyPaths from Microsoft.Build.Tasks.GetReferenceAssemblyPaths, Microsoft.Build.Tasks.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
    Looking for framework 'MonoAndroid,Version=v6.0' in root path '/Library/Frameworks/Mono.framework/External/xbuild-frameworks'
    Unable to find framework definition file '/Library/Frameworks/Mono.framework/External/xbuild-frameworks/MonoAndroid/v6.0/RedistList/FrameworkList.xml' for Target Framework Moniker 'MonoAndroid,Version=v6.0'
    Looking for framework 'MonoAndroid,Version=v6.0' in root path '/Library/Frameworks/Mono.framework/Versions/4.4.0/lib/mono/4.5/../xbuild-frameworks'
    Unable to find framework definition file '/Library/Frameworks/Mono.framework/Versions/4.4.0/lib/mono/4.5/../xbuild-frameworks/MonoAndroid/v6.0/RedistList/FrameworkList.xml' for Target Framework Moniker 'MonoAndroid,Version=v6.0'
    .../Microsoft.Common.targets:  warning : Unable to find framework corresponding to the target framework moniker 'MonoAndroid,Version=v6.0'. Framework assembly references will be resolved from the GAC, which might not be the intended behavior.
Done executing task "GetReferenceAssemblyPaths"

(Not sure why it's looking for v6.0`, but it can't find the
framework at all, so that's consistent with Linux.)

The fix is to set the $(TargetFrameworkRootPath) MSBuild property,
which is provided to the GetReferenceAssemblyPaths.RootPath
property, and allows controlling which locations are searched for
frameworks.

Unfortunately, $(TargetFrameworkRootPath) needs to be set to
bin\$(Configuration)\lib\xbuild-frameworks, which means
$(Configuration) needs to be set before
$(TargetFrameworkRootPath) is set. Furthermore, since we want to set
$(TargetFrameworkRootPath) in Configuration.props, this means that
we need to audit all locations which import Configuration.props to
ensure that $(Configuration) is set before the import.

Add $(TargetFrameworkRootPath) to Configuration.props, and audit
all uses of Configuration.props to ensure `$(Configuration) is set.

@atsushieno and I are trying to figure out why `src/Mono.Posix` builds
for me on OS X but fails for him in a (relatively) clean Linux
environment:

	CSC: error CS0518: The predefined type `System.Object' is not defined or imported

`System.Object` couldn't be found because `System.Runtime.dll` wasn't
being provided to the compiler.

Further investigation shows that the reason it built on OS X was
because OS X had a pre-existing system Xamarin.Android install, which
was being used to resolve framework directories:

	# Works on OS X:
	# Note: Mono.framework/External/xbuild-frameworks/MonoAndroid is a symlink
	#   into Xamarin.Android.framework, i.e. the system Xamarin.Android install
	Task "GetReferenceAssemblyPaths"
		Using task GetReferenceAssemblyPaths from Microsoft.Build.Tasks.GetReferenceAssemblyPaths, Microsoft.Build.Tasks.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
		Looking for framework 'MonoAndroid,Version=v1.0' in root path '/Library/Frameworks/Mono.framework/External/xbuild-frameworks'
		Found framework definition list '/Library/Frameworks/Mono.framework/External/xbuild-frameworks/MonoAndroid/v1.0/RedistList/FrameworkList.xml' for framework 'MonoAndroid,Version=v1.0'
	Done executing task "GetReferenceAssemblyPaths"

	# Fails on Linux:
	Target _GetReferenceAssemblyPaths:
		warning : Unable to find framework corresponding to the target framework moniker 'MonoAndroid,Version=v1.0'. Framework assembly references will be resolved from the GAC, which might not be the intended behavior.

Turns Out™, the error can be reproduced on OS X by "removing" the
system Xamarin.Android install:

	$ cd /Library/Frameworks/Mono.framework/External/xbuild-frameworks
	$ sudo mv MonoAndroid _MonoAndroid

	Task "GetReferenceAssemblyPaths"
		Using task GetReferenceAssemblyPaths from Microsoft.Build.Tasks.GetReferenceAssemblyPaths, Microsoft.Build.Tasks.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
		Looking for framework 'MonoAndroid,Version=v6.0' in root path '/Library/Frameworks/Mono.framework/External/xbuild-frameworks'
		Unable to find framework definition file '/Library/Frameworks/Mono.framework/External/xbuild-frameworks/MonoAndroid/v6.0/RedistList/FrameworkList.xml' for Target Framework Moniker 'MonoAndroid,Version=v6.0'
		Looking for framework 'MonoAndroid,Version=v6.0' in root path '/Library/Frameworks/Mono.framework/Versions/4.4.0/lib/mono/4.5/../xbuild-frameworks'
		Unable to find framework definition file '/Library/Frameworks/Mono.framework/Versions/4.4.0/lib/mono/4.5/../xbuild-frameworks/MonoAndroid/v6.0/RedistList/FrameworkList.xml' for Target Framework Moniker 'MonoAndroid,Version=v6.0'
		.../Microsoft.Common.targets:  warning : Unable to find framework corresponding to the target framework moniker 'MonoAndroid,Version=v6.0'. Framework assembly references will be resolved from the GAC, which might not be the intended behavior.
	Done executing task "GetReferenceAssemblyPaths"

(Not sure why it's looking for *v6.0*`, but it can't find the
framework at all, so that's consistent with Linux.)

The fix is to set the `$(TargetFrameworkRootPath)` MSBuild property,
which is provided to the [`GetReferenceAssemblyPaths.RootPath`][0]
property, and allows controlling which locations are searched for
frameworks.

Unfortunately, `$(TargetFrameworkRootPath)` needs to be set to
`bin\$(Configuration)\lib\xbuild-frameworks`, which means
`$(Configuration)` needs to be set *before*
`$(TargetFrameworkRootPath)` is set. Furthermore, since we want to set
`$(TargetFrameworkRootPath)` in `Configuration.props`, this means that
we need to audit all locations which import `Configuration.props` to
ensure that `$(Configuration)` is set before the import.

Add `$(TargetFrameworkRootPath)` to `Configuration.props`, and audit
all uses of `Configuration.props` to ensure `$(Configuration) is set.

[0]: https://msdn.microsoft.com/en-us/library/microsoft.build.tasks.getreferenceassemblypaths.rootpath.aspx
@jonpryor jonpryor force-pushed the jonp-TargetFrameworkRootPath branch from 14bd115 to 3bba98e Compare June 14, 2016 15:58
@atsushieno atsushieno merged commit 255a569 into dotnet:master Jun 14, 2016
radical pushed a commit that referenced this pull request May 8, 2018
Commit dfed286 updated Cecil to Cecil 0.10.0-beta1-v2, which has
multiple API incompatibilities with Cecil 0.9.6.

Unfortunately, some of these incompatibilities were hidden by use of
the `.Cast<T>()` extension method, which was used because older
versions of Cecil didn't use generics at all, so the `.Cast<T>()` was
present to provide types.

Types which became wrong with Cecil 0.10.0.

The result is that when
[building xamarin-android with a newer Java.Interop][0],
[things broke][1]:

	jcw-gen: System.InvalidCastException: Unable to cast object of type 'Mono.Cecil.InterfaceImplementation' to type 'Mono.Cecil.TypeReference'.
	  at (wrapper castclass) System.Object:__castclass_with_cache (object,intptr,intptr)
	  at System.Linq.Enumerable+<CastIterator>c__Iterator17`1[TResult].MoveNext () [0x00059] in /private/tmp/source-mono-4.4.0-c7sr1/bockbuild-mono-4.4.0-branch-c7sr1/profiles/mono-mac-xamarin/build-root/mono-x86/external/referencesource/System.Core/System/Linq/Enumerable.cs:916
	  at System.Linq.Enumerable+WhereSelectEnumerableIterator`2[TSource,TResult].MoveNext () [0x00078] in /private/tmp/source-mono-4.4.0-c7sr1/bockbuild-mono-4.4.0-branch-c7sr1/profiles/mono-mac-xamarin/build-root/mono-x86/external/referencesource/System.Core/System/Linq/Enumerable.cs:282
	  at System.Linq.Enumerable+WhereEnumerableIterator`1[TSource].MoveNext () [0x00062] in /private/tmp/source-mono-4.4.0-c7sr1/bockbuild-mono-4.4.0-branch-c7sr1/profiles/mono-mac-xamarin/build-root/mono-x86/external/referencesource/System.Core/System/Linq/Enumerable.cs:147
	  at System.Linq.Enumerable+<SelectManyIterator>c__Iterator2`2[TSource,TResult].MoveNext () [0x0009a] in /private/tmp/source-mono-4.4.0-c7sr1/bockbuild-mono-4.4.0-branch-c7sr1/profiles/mono-mac-xamarin/build-root/mono-x86/external/referencesource/System.Core/System/Linq/Enumerable.cs:424
	  at Java.Interop.Tools.JavaCallableWrappers.JavaCallableWrapperGenerator..ctor (Mono.Cecil.TypeDefinition type, System.String outerType, System.Action`2 log) [0x00332] in /Users/builder/jenkins/workspace/xamarin-android-pr-builder/xamarin-android/external/Java.Interop/src/Java.Interop.Tools.JavaCallableWrappers/Java.Interop.Tools.JavaCallableWrappers/JavaCallableWrapperGenerator.cs:144
	  at Java.Interop.Tools.JavaCallableWrappers.JavaCallableWrapperGenerator..ctor (Mono.Cecil.TypeDefinition type, System.Action`2 log) [0x00000] in /Users/builder/jenkins/workspace/xamarin-android-pr-builder/xamarin-android/external/Java.Interop/src/Java.Interop.Tools.JavaCallableWrappers/Java.Interop.Tools.JavaCallableWrappers/JavaCallableWrapperGenerator.cs:60
	  at Java.Interop.Tools.App.GenerateJavaCallableWrapper (Mono.Cecil.TypeDefinition type, System.String outputPath) [0x0001f] in /Users/builder/jenkins/workspace/xamarin-android-pr-builder/xamarin-android/external/Java.Interop/tools/jcw-gen/App.cs:78
	  at Java.Interop.Tools.App.Main (System.String[] args) [0x00265] in /Users/builder/jenkins/workspace/xamarin-android-pr-builder/xamarin-android/external/Java.Interop/tools/jcw-gen/App.cs:66

Remove use of `.Cast<T>()`: it's superfluous now that Cecil uses
generics (and has for ages...), and it's use introduces bugs.

[0]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android-pr-builder/164/
[1]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android-pr-builder/162/consoleText
jonpryor added a commit to jonpryor/xamarin-android that referenced this pull request Apr 30, 2020
Changes: dotnet/android-tools@12f52ac...f5fcb9f

  * dotnet/android-tools@f5fcb9f: [Xamarin.Android.Tools.AndroidSdk] Add support for cmdline-tools (dotnet#83)
  * dotnet/android-tools@f473ff9: [AndroidSdkWindows] Guard against exception checking registry (dotnet#79)
  * dotnet/android-tools@36d7fee: JetBrains OpenJDK 11 detection (dotnet#82)
jonpryor added a commit to jonpryor/xamarin-android that referenced this pull request May 7, 2020
Changes: dotnet/android-tools@12f52ac...f5fcb9f

  * dotnet/android-tools@f5fcb9f: [Xamarin.Android.Tools.AndroidSdk] Add support for cmdline-tools (dotnet#83)
  * dotnet/android-tools@f473ff9: [AndroidSdkWindows] Guard against exception checking registry (dotnet#79)
  * dotnet/android-tools@36d7fee: JetBrains OpenJDK 11 detection (dotnet#82)
jonpryor added a commit that referenced this pull request May 7, 2020
Changes: dotnet/android-tools@12f52ac...f5fcb9f

  * dotnet/android-tools@f5fcb9f: [Xamarin.Android.Tools.AndroidSdk] Add support for cmdline-tools (#83)
  * dotnet/android-tools@f473ff9: [AndroidSdkWindows] Guard against exception checking registry (#79)
  * dotnet/android-tools@36d7fee: JetBrains OpenJDK 11 detection (#82)
jonpryor added a commit that referenced this pull request May 8, 2020
Changes: dotnet/android-tools@12f52ac...23c4fe0

  * dotnet/android-tools@23c4fe0: [Xamarin.Android.Tools.AndroidSdk] Add support for cmdline-tools (#83)
  * dotnet/android-tools@cf9d325: [AndroidSdkWindows] Guard against exception checking registry (#79)
  * dotnet/android-tools@310c5cf: JetBrains OpenJDK 11 detection (#82)
@github-actions github-actions bot locked and limited conversation to collaborators Feb 2, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants