-
Notifications
You must be signed in to change notification settings - Fork 528
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
[Xamarin.Android.Build.Tasks] ILRepack the NuGet.* Tasks Dependencies. #1694
Conversation
`ResolveAssemblies` is throwing the following error on a newer mono (2018-04). error : Could not load file or assembly 'NuGet.ProjectModel, Version=4.6.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. This is because we took a dependency on NuGet.ProjectModel 4.6 and the newer mono has 4.7. This results in the error above. Now we cannot always be sure which version of the NuGet assemblies will be installed since users are able to upgrade mono independently. So this PR will use the `ILRepack` NuGet to package up the dependencies we need so that `Xamarin.Android.Build.Tasks` contains all the correct assemblies it needs.
Why don't we just copy This is what we had to do with |
@jonpryor because we don't know what versions the IDE's might load. And if the API changes ...boom! |
If you had correct/expected version next to the assembly Mono will load them side by side if they are strongly signed |
@marek-safar so we could ship the version of Nuget.Project we use if they are Strong Signed? @jonpryor do we Strong Sign our stuff on Mac and Windows? |
Yes, that's what does not allows you do to. You can load multiple versions of assemblies with the same name. Now it has its own prons and cons |
|
|
@dean, @alanmcgovern, @marek-safar: As per @alanmcgovern's last comment,
I'm hesitant to prefer IL Repacking in an OSS context because it makes it harder to "see" where assemblies "come from" and have the user plausibly replace them. This may just be me "overthinking" things. |
The upstream assemblies aren't signed. We could look into strongnaming the copy that the Xamarin.Android buildsystem wants to ship and also all other assemblies which then need to be strongnamed, but ILRepack has been the in-production mechanism for solving this for Xamarin.iOS and Xamarin.Mac for the last few months: xamarin/xamarin-macios#3168 . In an opensource context it's still easy for someone to replace arbitrary assemblies. If they understand what they're doing ilrepacking a new assembly will be easy. If they don't understand what they're doing then they probably shouldn't be replacing binaries inside a build system :p |
ResolveAssemblies
is throwing the following error ona newer mono (2018-04).
This is because we took a dependency on NuGet.ProjectModel 4.6 and
the newer mono has 4.7. This results in the error above.
Now we cannot always be sure which version of the NuGet assemblies
will be installed since users are able to upgrade mono independently.
So this PR will use the
ILRepack
NuGet to package up the dependencieswe need so that
Xamarin.Android.Build.Tasks
contains all thecorrect assemblies it needs.