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

VS 1449000: Fix handling of satellite assemblies in ClickOnce #6665

Merged
merged 3 commits into from
Jul 19, 2021

Conversation

sujitnayak
Copy link
Contributor

@sujitnayak sujitnayak commented Jul 12, 2021

Fixes AB#1449000

Context

Satellite assemblies are not being handled correctly after ClickOnce changes for .NET Core publishing were made in VS 16.8.

Following issues have been observed post those changes:

  1. If packages publish en-us resource assembly for other locales as well, we will end up adding all of them in the ClickOnce manifest. Since the strong name signature will be identical for all these resource assemblies, we will now have multiple assemblies with identical signature in the ClickOnce manifest. This will cause CO Install to fail.

  2. The References item list can also contain resource assemblies. If these assemblies are also present in the SatelliteAssembly item list, we will now end up writing 2 entries for the same assembly in the manifest. This will cause CO install to fail.

Changes Made

When we process the References item list, we will maintain a dictionary for satellite assemblies that are getting included in the list of assemblies. Later when we process the SatelliteAssemblies item list, we will look up in this dictionary and skip the entries that are already included through the References list.

Testing

Ongoing

Notes

if (identity != null && !String.Equals(identity.Culture, "neutral", StringComparison.Ordinal))
{
// Use satellite assembly strong name signature as key
string key = identity.ToString().ToLowerInvariant();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of having to create this new string, can you use an invariant comparer on the dictionary?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changed per suggestion.

// decides to publish the en-us resource assemblies for other locales also.
if (!LauncherBasedDeployment && satelliteRefAssemblyMap.ContainsItem(item))
{
Debug.Assert(false, $"Duplicate satellite assembly '{item.ItemSpec}' skipped in _managedAssemblies");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand these asserts. Is it a bug in the task if we get to this point? If it's a bug in the user's projects or an unusual condition, I don't think the assert is appropriate.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's about unusual satellite assemblies in file/nuget references. I have removed the asserts as it's not a bug in the task.

Comment on lines 399 to 406
if (!PublishFlags.IsSatelliteIncludedByDefault(satelliteCulture, _targetCulture, _includeAllSatellites))
{
continue;
}
else
{
satelliteRefAssemblyMap.Add(item);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for readability I'd prefer

Suggested change
if (!PublishFlags.IsSatelliteIncludedByDefault(satelliteCulture, _targetCulture, _includeAllSatellites))
{
continue;
}
else
{
satelliteRefAssemblyMap.Add(item);
}
if (PublishFlags.IsSatelliteIncludedByDefault(satelliteCulture, _targetCulture, _includeAllSatellites))
{
satelliteRefAssemblyMap.Add(item);
}
else
{
continue;
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed.

continue;
}

// If we get a resource assembly in managed references, determine whether to be publish it based on _targetCulture
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be accurate to say

Suggested change
// If we get a resource assembly in managed references, determine whether to be publish it based on _targetCulture
// apply the culture publishing rules to managed references as well as satellites

?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated with tweaks.

@@ -52,6 +52,8 @@ public sealed class ResolveManifestFiles : TaskExtension
// if signing manifests is on and not all app files are included, then the project can't be published.
private bool _canPublish;
private Dictionary<string, ITaskItem> _runtimePackAssets;
// map of satellite assemblies that are included in References
private SatelliteRefAssemblyMap satelliteRefAssemblyMap = new SatelliteRefAssemblyMap();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found this name unclear later on. Maybe call it _satelliteAssembliesPassedAsReferences?

(also nit: our style is that this should start with an _)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed.

@John-Hart John-Hart requested a review from ning51 July 16, 2021 14:53
@rainersigwald rainersigwald added the merge-when-branch-open PRs that are approved, except that there is a problem that means we are not merging stuff right now. label Jul 16, 2021
@ladipro ladipro merged commit 1034dbf into dotnet:main Jul 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merge-when-branch-open PRs that are approved, except that there is a problem that means we are not merging stuff right now.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants