-
Notifications
You must be signed in to change notification settings - Fork 53
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
[jnimarshalmethod-gen] Update the originating assembly #300
[jnimarshalmethod-gen] Update the originating assembly #300
Conversation
Update the originating assembly instead of creating a *new* one, called `<AssemblyName>-new.dll` I expected I would need to load the originating assembly in the separate AppDomain, but instead it was enough to load it with cecil with reading parameters having `ReadWrite = true`. Because the referenced assemblies might not be writable, we need to keep loading them as read only, thus with default `ReadWrite = false`. For that I added new method to our cecil assembly resolver, to add existing assembly definition to its cache. We first read the originating assemblies as *ReadWrite* and add them to the resolver cache.
Question: can this be changed to instead:
This would remove the need to explicitly remove the |
I plan to add an option to do that. This PR is not related to |
) Commit 8898bc1 put too much faith into `$(MSBuildProjectDirectory)). The problem is that `$(MSBuildProjectDirectory)` *isn't necessarily* the path to `Directory.Build.props`; it's the directory for the `.csproj` being built! The *intent* for 8898bc1 is that e.g. `xamarin/xamarin-android` should be able to create a `Java.Interop.override.props` file alongside the `Java.Interop` git submodule, and the Java.Interop build would use the overrides within `Java.Interop.override.props`. That didn't happen; due to using `$(MSBuildProjectDirectory)`, the build may instead attempting to import e.g. `Java.Interop/src/Java.Interop.override.props`! Project "$(MSBuildProjectDirectory).override.props" was not imported by "…/external/Java.Interop/Directory.Build.props" at (6,3), due to false condition; (Exists('$(MSBuildProjectDirectory).override.props')) was evaluated as (Exists('…/xamarin-android/external/Java.Interop/src/Java.Interop.override.props')). Oops. Fix the `<Import/>` expressions so that we instead try to import: $([System.IO.Path]::GetDirectoryName($(MSBuildThisFileDirectory))).override.props We need `$(MSBuildThisFileDirectory)`, as that's the easiest way to get the checkout directory -- the directory containing `Directory.Build.props` -- but `$(MSBuildThisFileDirectory)` always ends in a directory separator character. Remove the directory separator character by using `Path.GetDirectoryName()`. This allows e.g. the `Java.Interop.csproj` build to appropriately import `Java.Interop.override.props`.
…873) Commit 8898bc1 put too much faith into `$(MSBuildProjectDirectory)). The problem is that `$(MSBuildProjectDirectory)` *isn't necessarily* the path to `Directory.Build.props`; it's the directory for the `.csproj` being built! The *intent* for 8898bc1 is that e.g. `xamarin/xamarin-android` should be able to create a `Java.Interop.override.props` file alongside the `Java.Interop` git submodule, and the Java.Interop build would use the overrides within `Java.Interop.override.props`. That didn't happen; due to using `$(MSBuildProjectDirectory)`, the build may instead attempting to import e.g. `Java.Interop/src/Java.Interop.override.props`! Project "$(MSBuildProjectDirectory).override.props" was not imported by "…/external/Java.Interop/Directory.Build.props" at (6,3), due to false condition; (Exists('$(MSBuildProjectDirectory).override.props')) was evaluated as (Exists('…/xamarin-android/external/Java.Interop/src/Java.Interop.override.props')). Oops. Fix the `<Import/>` expressions so that we instead try to import: $([System.IO.Path]::GetDirectoryName($(MSBuildThisFileDirectory))).override.props We need `$(MSBuildThisFileDirectory)`, as that's the easiest way to get the checkout directory -- the directory containing `Directory.Build.props` -- but `$(MSBuildThisFileDirectory)` always ends in a directory separator character. Remove the directory separator character by using `Path.GetDirectoryName()`. This allows e.g. the `Java.Interop.csproj` build to appropriately import `Java.Interop.override.props`.
…873) Commit 8898bc1 put too much faith into `$(MSBuildProjectDirectory)). The problem is that `$(MSBuildProjectDirectory)` *isn't necessarily* the path to `Directory.Build.props`; it's the directory for the `.csproj` being built! The *intent* for 8898bc1 is that e.g. `xamarin/xamarin-android` should be able to create a `Java.Interop.override.props` file alongside the `Java.Interop` git submodule, and the Java.Interop build would use the overrides within `Java.Interop.override.props`. That didn't happen; due to using `$(MSBuildProjectDirectory)`, the build may instead attempting to import e.g. `Java.Interop/src/Java.Interop.override.props`! Project "$(MSBuildProjectDirectory).override.props" was not imported by "…/external/Java.Interop/Directory.Build.props" at (6,3), due to false condition; (Exists('$(MSBuildProjectDirectory).override.props')) was evaluated as (Exists('…/xamarin-android/external/Java.Interop/src/Java.Interop.override.props')). Oops. Fix the `<Import/>` expressions so that we instead try to import: $([System.IO.Path]::GetDirectoryName($(MSBuildThisFileDirectory))).override.props We need `$(MSBuildThisFileDirectory)`, as that's the easiest way to get the checkout directory -- the directory containing `Directory.Build.props` -- but `$(MSBuildThisFileDirectory)` always ends in a directory separator character. Remove the directory separator character by using `Path.GetDirectoryName()`. This allows e.g. the `Java.Interop.csproj` build to appropriately import `Java.Interop.override.props`.
Update the originating assembly instead of creating a new one,
called
<AssemblyName>-new.dll
I expected I would need to load the originating assembly in the
separate AppDomain, but instead it was enough to load it with cecil
with reading parameters having
ReadWrite = true
.Because the referenced assemblies might not be writable, we need to
keep loading them as read only, thus with default
ReadWrite = false
.For that I added new method to our cecil assembly resolver, to add
existing assembly definition to its cache. We first read the
originating assemblies as ReadWrite and add them to the resolver
cache.