[build] Allow Assembly "vendorization" #136
Merged
Conversation
This file contains 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
Context: ff73f92 Context: 061bcc2 Context: xamarin/XamarinVS#12550 Changing `$(Version)` with every commit is fun and all, but doesn't solve all problems. Commit ff73f92 works "nicely" for MSBuild tasks via [`<UsingTask/>`][0]. It doesn't work as well for "normal" assembly references in a "normal" AppDomain context, because assemblies are [normally resolved][1] via "assembly base name", *not* the full path name including directory. Thus, given `Example.dll`: csc /out:Example.dll /r:Path/To/Xamarin.Android.Tools.AndroidSdk.dll then when `Example.dll` is loaded, it will try to load `Xamarin.Android.Tools.AndroidSdk` via a `Load-by-name` method, and will load the first `Xamarin.Android.Tools.AndroidSdk.dll` loaded into the `AppDomain`/`AssemblyLoadContext`, regardless of version. There may not be a good way to control what that assembly *is*. This causes grief with our peer IDE teams, as assembly versions are still checked, but on mismatch an exception is thrown (!). Commit 061bcc2 was an attempt to address this, but proved to be incomplete. Attempt to improve matters by introducing a "vendorization" protocol: 1. Update `Directory.Build.props` to import "parent directory.override.props", so that a "parent checkout" can easily override MSBuild properties. 2. Update the `*.csproj` files so that `$(AssemblyName)` is forced to start with `$(VendorPrefix)`, and end with `$(VendorSuffix)`. This allows a parent checkout to set the `$(VendorPrefix)` and `$(VendorSuffix)` properties, which will impact the assembly filenames of all assemblies built in xamarin-android-tools. [0]: https://docs.microsoft.com/en-us/visualstudio/msbuild/usingtask-element-msbuild?view=vs-2019 [1]: https://docs.microsoft.com/en-us/dotnet/core/dependency-loading/loading-managed
jonpryor
force-pushed
the
jonp-assembly-vendorize-support
branch
from
d7aa030 to
3cdae1d
Compare
BretJohnson
approved these changes
Sep 27, 2021
jonathanpeppers
approved these changes
Sep 27, 2021
BretJohnson
pushed a commit
that referenced
this pull request
Oct 1, 2021
Context: ff73f92 Context: 061bcc2 Context: xamarin/XamarinVS#12550 Changing `$(Version)` with every commit is fun and all, but doesn't solve all problems. Commit ff73f92 works "nicely" for MSBuild tasks via [`<UsingTask/>`][0]. It doesn't work as well for "normal" assembly references in a "normal" AppDomain context, because assemblies are [normally resolved][1] via "assembly base name", *not* the full path name including directory. Thus, given `Example.dll`: csc /out:Example.dll /r:Path/To/Xamarin.Android.Tools.AndroidSdk.dll then when `Example.dll` is loaded, it will try to load `Xamarin.Android.Tools.AndroidSdk` via a `Load-by-name` method, and will load the first `Xamarin.Android.Tools.AndroidSdk.dll` loaded into the `AppDomain`/`AssemblyLoadContext`, regardless of version. There may not be a good way to control what that assembly *is*. This causes grief with our peer IDE teams, as assembly versions are still checked, but on mismatch an exception is thrown (!). Commit 061bcc2 was an attempt to address this, but proved to be incomplete. Attempt to improve matters by introducing a "vendorization" protocol: 1. Update `Directory.Build.props` to import "parent directory.override.props", so that a "parent checkout" can easily override MSBuild properties. 2. Update the `*.csproj` files so that `$(AssemblyName)` is forced to start with `$(VendorPrefix)`, and end with `$(VendorSuffix)`. This allows a parent checkout to set the `$(VendorPrefix)` and `$(VendorSuffix)` properties, which will impact the assembly filenames of all assemblies built in xamarin-android-tools. [0]: https://docs.microsoft.com/en-us/visualstudio/msbuild/usingtask-element-msbuild?view=vs-2019 [1]: https://docs.microsoft.com/en-us/dotnet/core/dependency-loading/loading-managed
BretJohnson
pushed a commit
that referenced
this pull request
Oct 1, 2021
Context: ff73f92 Context: 061bcc2 Context: xamarin/XamarinVS#12550 Changing `$(Version)` with every commit is fun and all, but doesn't solve all problems. Commit ff73f92 works "nicely" for MSBuild tasks via [`<UsingTask/>`][0]. It doesn't work as well for "normal" assembly references in a "normal" AppDomain context, because assemblies are [normally resolved][1] via "assembly base name", *not* the full path name including directory. Thus, given `Example.dll`: csc /out:Example.dll /r:Path/To/Xamarin.Android.Tools.AndroidSdk.dll then when `Example.dll` is loaded, it will try to load `Xamarin.Android.Tools.AndroidSdk` via a `Load-by-name` method, and will load the first `Xamarin.Android.Tools.AndroidSdk.dll` loaded into the `AppDomain`/`AssemblyLoadContext`, regardless of version. There may not be a good way to control what that assembly *is*. This causes grief with our peer IDE teams, as assembly versions are still checked, but on mismatch an exception is thrown (!). Commit 061bcc2 was an attempt to address this, but proved to be incomplete. Attempt to improve matters by introducing a "vendorization" protocol: 1. Update `Directory.Build.props` to import "parent directory.override.props", so that a "parent checkout" can easily override MSBuild properties. 2. Update the `*.csproj` files so that `$(AssemblyName)` is forced to start with `$(VendorPrefix)`, and end with `$(VendorSuffix)`. This allows a parent checkout to set the `$(VendorPrefix)` and `$(VendorSuffix)` properties, which will impact the assembly filenames of all assemblies built in xamarin-android-tools. [0]: https://docs.microsoft.com/en-us/visualstudio/msbuild/usingtask-element-msbuild?view=vs-2019 [1]: https://docs.microsoft.com/en-us/dotnet/core/dependency-loading/loading-managed
BretJohnson
added a commit
that referenced
this pull request
Oct 1, 2021
[d17-0][build] Allow Assembly "vendorization" (#136)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: ff73f92
Context: 061bcc2
Context: https://github.com/xamarin/XamarinVS/pull/12550
Changing
$(Version)with every commit is fun and all, but doesn'tsolve all problems. Commit ff73f92 works "nicely" for MSBuild tasks
via
<UsingTask/>. It doesn't work as well for "normal"assembly references in a "normal" AppDomain context, because
assemblies are normally resolved via "assembly base name", not
the full path name including directory.
Thus, given
Example.dll:then when
Example.dllis loaded, it will try to loadXamarin.Android.Tools.AndroidSdkvia aLoad-by-namemethod, andwill load the first
Xamarin.Android.Tools.AndroidSdk.dllloadedinto the
AppDomain/AssemblyLoadContext, regardless of version.There may not be a good way to control what that assembly is.
This causes grief with our peer IDE teams, as assembly versions are
still checked, but on mismatch an exception is thrown (!).
Commit 061bcc2 was an attempt to address this, but proved to be
incomplete.
Attempt to improve matters by introducing a "vendorization" protocol:
Update
Directory.Build.propsto import"parent directory.override.props", so that a "parent checkout"
can easily override MSBuild properties.
Update the
*.csprojfiles so that$(AssemblyName)is forcedto start with
$(VendorPrefix), and end with$(VendorSuffix).This allows a parent checkout to set the
$(VendorPrefix)and$(VendorSuffix)properties, which will impact the assembly filenamesof all assemblies built in xamarin-android-tools.