Feature request: Add switch to include private members in PE symbols

[bkoelman]

In Roslyn v1.0, private fields/properties/methods (and nested types) are not exposed by calls like INamedTypeSymbol.GetMembers(), in case such a type was constructed from a referenced assembly instead of source code.

For the project I'm currently working on (backporting a Roslyn-based analyzer into FxCop rules for use in previous versions of Visual Studio), I would like a switch to become available in Roslyn vNext, to include private members.

For example, when exposed through MetadataReferenceProperties, I could write code like:

private static CSharpCompilation CreateCompilation(AssemblyNode assemblyNode)
{
    SyntaxTree tree = CSharpSyntaxTree.ParseText(" ");

    MetadataReferenceProperties referenceProperties =
        MetadataReferenceProperties.WithPrivateMembers;

    IEnumerable<MetadataReference> assemblyReferences = new[]
    {
        MetadataReference.CreateFromFile(assemblyNode.Location, referenceProperties),
        MetadataReference.CreateFromFile(typeof (object).Assembly.Location)
    };

    string outputAssemblyFileName = Path.GetFileName(Path.GetTempFileName()) + ".dll";

    return CSharpCompilation.Create(outputAssemblyFileName,
        options: new CSharpCompilationOptions(OutputKind.DynamicallyLinkedLibrary),
        syntaxTrees: new[] { tree }, references: assemblyReferences);
}

[bkoelman]

@shyamnamboodiripad

[shyamnamboodiripad]

cc @AlekseyTs @jaredpar

[tmat]

This is also gonna be needed to support #r! scripting directive (add a reference with internals visible).

[AlekseyTs]

Would making CompilationOptions.MetadataImportOptions public address the gap?

[tmat]

@AlekseyTs We will need to do this per-reference for scripting, not per-compilation.

[bkoelman]

@AlekseyTs Thanks for pointing out CompilationOptions.MetadataImportOptions, I was unaware of its existence. To investigate, I tried setting it through reflection. Most things are working for me that way, but I ran into something of which I'm not sure is correct.

Making this public would be nice. But a have an acceptable workaround at the moment. So holding this off in favour of doing what's needed for scripting would be fine by me.