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

Compiler support for IgnoresAccessChecksToAttribute #20870

Closed
wants to merge 1 commit into from

Conversation

aelij
Copy link
Contributor

@aelij aelij commented Jul 13, 2017

The IgnoresAccessChecksToAttribute is the reverse of the InternalsVisibleToAttribute - it allows an assembly to declare assemblies whose internals would be visible to it. The attribute class isn't declared in the BCL but is recognized by the CLR (Desktop >= 4.6 and Core), i.e. you can declare it in your code and it would work.

This PR adds compiler support for this attribute, just like IVT.

Motivation:

  • It would help a lot of scenarios where we usually turn to Reflection (which is severely limited and slow) or, if we're lucky and the sources are available, copy the code.
  • A lot of developers are willing to rely on unpublished APIs, taking the risk they might break without notice in future versions. Compiler support means that this would be much safer.
  • There's so much useful code (even within Roslyn) that remains internal because publishing and supporting a stable API is a very hard and slow process. Entity Framework went so far as to publish their internal types as public, in a dedicated namespace, while providing no forward compatibility guarantee.

Alternatives:

  • Create a build task to generate reference assemblies for the compiler which transforms the internal types and members to public (e.g. using Cecil), and then apply the attribute.

PS - I now realize I probably should've started with an issue. I wanted to get a POC working and it turned out to be pretty simple. Let me know if I should open one instead.

@jcouv jcouv added Area-Compilers Community The pull request was submitted by a contributor who is not a Microsoft employee. labels Jul 13, 2017
@jcouv jcouv added this to the 15.5 milestone Jul 13, 2017
@jcouv
Copy link
Member

jcouv commented Jul 13, 2017

Thanks for the PR.

FYI @gafter @dotnet/roslyn-compiler This is a community contribution to allow a compilation to have full access to types and members in a specific assembly ([IgnoresAccessChecksToAttribute("assemblyName")]).

Two things:

  • we'll have to check with LDM on the feature itself, since this raises language design questions. The next meeting is 2 weeks from now, if I recall correctly. The process is described on the csharplang repo: basically, (1) write a proposal, (2) identify an LDM member who supports/champions it, (3) review it in LDM.
  • regarding the CI checks: the CI infrastructure actually builds the compiler once, and the resulting compiler (called "bootstrap") is used to build the solution. It looks like the bootstrap compiler is crashing. I think the way to reproduce this process locally is build/scripts/cibuild.cmd.
14:44:12 
D:\j\workspace\windows_debug---f1572675\Binaries\Bootstrap\Microsoft.CSharp.Core.targets(84,5): error MSB6006: "csc.exe" exited with code -1073741571. [D:\j\workspace\windows_debug---f1572675\src\VisualStudio\IntegrationTest\TestSetup\VisualStudioIntegrationTestSetup.csproj]

Note, there is an IgnoresAccessChecksToAttribute in CoreRT, which is not part of the public API at this point.

Had a quick chat with Neal, he mentioned an alternative way we could approach this: using a new kind of reference instead (from the command-line or Compilation API), which would mean "this reference is part of my program" (since the language cares about what is inside versus external to a "program").

@jcouv
Copy link
Member

jcouv commented Jul 13, 2017

Just to clarify, don't worry about the CI errors until we hear back from LDM.

@jcouv
Copy link
Member

jcouv commented Dec 13, 2017

Notes from LDM https://github.com/dotnet/csharplang/blob/master/meetings/2017/LDM-2017-11-06.md

@Denis535
Copy link

May be you could just allow to use typeof and nameof with non-public types? This would be the golden mean.

@sharwell sharwell added the Resolution-By Design The behavior reported in the issue matches the current design label Aug 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Compilers cla-already-signed Community The pull request was submitted by a contributor who is not a Microsoft employee. Resolution-By Design The behavior reported in the issue matches the current design
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants