-
Notifications
You must be signed in to change notification settings - Fork 561
[monodroid] Properly process satellite assemblies #7823
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
Changes from all commits
24a7e81
b475944
dab54df
1b1df89
dde53ee
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -265,7 +265,9 @@ void AddEnvironment () | |
| HashSet<string> archAssemblyNames = null; | ||
| HashSet<string> uniqueAssemblyNames = new HashSet<string> (StringComparer.OrdinalIgnoreCase); | ||
| Action<ITaskItem> updateAssemblyCount = (ITaskItem assembly) => { | ||
| string assemblyName = Path.GetFileName (assembly.ItemSpec); | ||
| // We need to use the 'RelativePath' metadata, if found, because it will give us the correct path for satellite assemblies - with the culture in the path. | ||
| string? relativePath = assembly.GetMetadata ("RelativePath"); | ||
| string assemblyName = String.IsNullOrEmpty (relativePath) ? Path.GetFileName (assembly.ItemSpec) : relativePath; | ||
|
Comment on lines
+268
to
+270
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do you have a In other places we used I think we should just check which one we should use everywhere. /cc @dellis1972 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. These are the relevant entries for statellite assemblies as passed to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Note that it isn't just a path - it's the de-facto assembly name. The runtime will ask us to load an assembly named There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we should be ok to use There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We have some logic that sets I don't think There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @jonathanpeppers yeah, |
||
| if (!uniqueAssemblyNames.Contains (assemblyName)) { | ||
| uniqueAssemblyNames.Add (assemblyName); | ||
| } | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we still need to change this to use
%(DestinationSubPath)? I thought we saw that architecture-specific assemblies could also hit a similar issue?Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, architecture specific assemblies are handled correctly (if they didn't, we'd see this issue much earlier).
DestinationSubPathwould only make matters worse - because I would have to know which is arch-specific assembly and which is a satellite assembly, to treat the prefix differently.RelativePathappears to be unambiguous for this purpose.