-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Add references to System.IO.Pipes.AccessControl #24457
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
Conversation
When adding the reference to System.IO.Pipes.AccessControl for the compiler server to use on CoreCLR, I unified the pathway for the desktop and CoreCLR server access control code. This means that System.IO.Pipes.AccessControl needed to be added as a dependent DLL for desktop too, but I forgot to do that. This change adds System.IO.Pipes.AccessControl as a dependent DLL in all the places where the build task is deployed.
| packageVersion, | ||
| isNative:=native IsNot Nothing, | ||
| isFacade:=frameworkAssemblies IsNot Nothing)) | ||
| isFacade:=frameworkAssemblies IsNot Nothing OrElse packageName = "System.IO.Pipes.AccessControl")) |
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.
curious why this is special?
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.
@jasonmalinowski Can you clarify here?
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.
@heejaechang It's not, the condition should more generally be rewritten. This is a tactical fix.
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.
One of the happiest days of my future self is deleting this file.
|
@MattGertz for escrow approval |
|
@agocke Escrow issues need to be submitted to me via VSO bugs. |
|
retest windows_release_vs-integration_prtest please |
|
the appdomain unloaded exception happened. |
…ild task (true on desktop)
|
@jaredpar After testing on desktop it looks like I needed to adjust the load policy slightly. Can you take a look and sign off again? |
|
@MattGertz I've added an escrow VSO bug for this PR: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/557536 |
* Add UseCultureAttribute to help with culture-dependent unit tests * Disable NuGet package restore in Visual Studio for Roslyn.sln * Add named argument for literal * Fix behavior for NET46 and NETCOREAPP2_0 * Revert "moved waiter from diagnostics.dll to features.dll where all interface… (#24120)" This reverts commit 823d973. * Add references to System.IO.Pipes.AccessControl (#24457) When adding the reference to System.IO.Pipes.AccessControl for the compiler server to use on CoreCLR, I unified the pathway for the desktop and CoreCLR server access control code. This means that System.IO.Pipes.AccessControl needed to be added as a dependent DLL for desktop too, but I forgot to do that. This change adds System.IO.Pipes.AccessControl as a dependent DLL in all the places where the build task is deployed.
Customer scenario
The VS build is currently broken.
When adding the reference to System.IO.Pipes.AccessControl for the
compiler server to use on CoreCLR, I unified the pathway for the desktop
and CoreCLR server access control code. This means that
System.IO.Pipes.AccessControl needed to be added as a dependent DLL for
desktop too, but I forgot to do that. This change adds
System.IO.Pipes.AccessControl as a dependent DLL in all the places where
the build task is deployed.
Bugs this fixes
https://devdiv.visualstudio.com/DevDiv/_workitems/edit/557536
Workarounds, if any
None.
Risk
This change mirrors our behavior for System.IO.Pipes pretty closely. Since any scenario which
needs System.IO.Pipes.AccessControl should also require System.IO.Pipes, it's unlikely that we've
missed a deployment scenario if we cover every scenario where System.IO.Pipes is deployed.
Overall, this change should be validated by RPS.
Performance impact
Without this change, the compiler server does not work on desktop.
Is this a regression from a previous update?
Yes.
Root cause analysis
The bootstrap process we use to test the compiler server in Roslyn is not exactly the same
as the binary layout we use in VS. In addition, we have multiple files which duplicate the
same information about binary layout. @jasonmalinowski has a PR (#22845) to help address the duplication issue. I have filed an issue
(#24456) to move our bootstrap
code closer to the VS layout, which should help catch these issues earlier.
How was the bug found?
RPS Failure