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

Fix signing of swix project output #25850

Merged
merged 1 commit into from
Mar 31, 2018
Merged

Conversation

jaredpar
Copy link
Member

This fixes a signing regression caused be #25751. That changed us to
directly call the SWIX build props / targets vs. getting them implicitly
from the microbuild props / targets. One of the behaviors that the
microbuild props / targets had that wasn't accounted for was the signing
of the VSIX after they are constructed. Hence this lead to signing
errors on insertion.

This PR fixes that by making the following changes:

  1. Adds SWIX VSIX to SignToolData.json so they are accounted for during
    normal batch signing.
  2. Moves the SWIX build to the pre-sign portion of our build.
  3. Removes the references from VSMAN -> SWIX. These references are there
    only to enforce ordering which is unnecessary. Having them remain risks
    that building the VSMAN will cause the SWIX to be re-built which could
    possibly invalidate signing.
Ask Mode template not completed

Customer scenario

What does the customer do to get into this situation, and why do we think this
is common enough to address for this release. (Granted, sometimes this will be
obvious "Open project, VS crashes" but in general, I need to understand how
common a scenario is)

Bugs this fixes

(either VSO or GitHub links)

Workarounds, if any

Also, why we think they are insufficient for RC vs. RC2, RC3, or RTW

Risk

This is generally a measure our how central the affected code is to adjacent
scenarios and thus how likely your fix is to destabilize a broader area of code

Performance impact

(with a brief justification for that assessment (e.g. "Low perf impact because no extra allocations/no complexity changes" vs. "Low")

Is this a regression from a previous update?

Root cause analysis

How did we miss it? What tests are we adding to guard against it in the future?

How was the bug found?

(E.g. customer reported it vs. ad hoc testing)

Test documentation updated?

If this is a new non-compiler feature or a significant improvement to an existing feature, update https://github.com/dotnet/roslyn/wiki/Manual-Testing once you know which release it is targeting.

This fixes a signing regression caused be dotnet#25751. That changed us to
directly call the SWIX build props / targets vs. getting them implicitly
from the microbuild props / targets. One of the behaviors that the
microbuild props / targets had that wasn't accounted for was the signing
of the VSIX after they are constructed. Hence this lead to signing
errors on insertion.

This PR fixes that by making the following changes:

1. Adds SWIX VSIX to SignToolData.json so they are accounted for during
normal batch signing.
1. Moves the SWIX build to the pre-sign portion of our build.
1. Removes the references from VSMAN -> SWIX. These references are there
only to enforce ordering which is unnecessary. Having them remain risks
that building the VSMAN will cause the SWIX to be re-built which could
possibly invalidate signing.
@jaredpar jaredpar requested a review from a team as a code owner March 30, 2018 22:56
@jaredpar
Copy link
Member Author

CC @tmeschter, @dotnet/roslyn-infrastructure

@jcouv jcouv added this to the 15.7 milestone Mar 30, 2018
@jaredpar jaredpar merged commit 7933a9f into dotnet:dev15.7.x Mar 31, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants