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

Suggestion #18

Open
RobertvanderHulst opened this issue Jan 22, 2024 · 4 comments
Open

Suggestion #18

RobertvanderHulst opened this issue Jan 22, 2024 · 4 comments

Comments

@RobertvanderHulst
Copy link
Contributor

When an assembly that we depend on has many other dependencies, then loading that assembly by this task may fail.

Wouldn't it be easier to add a new global InternalsVisibleTo attribute to the generated assembly that contains the name of our assembly?
Something like:

<InternalsAddAssembly Include="OurAssembly, PublicKey=0123456......ABCDEF"/>

This should generate

[assembly: InternalsVisibleTo("OurAssembly, PublicKey=0123456......ABCDEF"")]
@aelij
Copy link
Owner

aelij commented Jan 31, 2024

Sorry I'm not sure I follow. Can you give a complete example? Like assembly A uses the task, depends on assembly B, etc.

@RobertvanderHulst
Copy link
Contributor Author

I try to use this to create our own VS project system, based on the DotNet/ProjectSystem code.
One of the projects in there references the Microsoft.VisualStudio.LanguageServices Nuget package, which brings in several other Microsoft DLLs. At this moment building fails because that DLL does not load properly, because it needs its dependencies.
I suspect that happens when resolving the types and their properties.
Maybe we can avoid resolving that by simply addding our assembly to the "InternalsVisibleTo" list?

Btw: many of the Visual Studio Project System assemblies contain internal (compilergenerated) attributes, such as System.Diagnostics.CodeAnalysis.NotNullAttribute.
The list of type names inside InternalsAssemblyExcludeTypeName becomes quite long.
It would be nice if we could exclude a whole namespace from making internal types public, such as the System.Diagnostics.CodeAnalysis namespace.
Maybe add a new property and use that to filter types by namespace:
<InternalsAssemblyExcludeNamespace>System.Diagnostics.CodeAnalysis<InternalsAssemblyExcludeNamespace>

@aelij
Copy link
Owner

aelij commented Jan 31, 2024

Re InternalsAssemblyExcludeNamespace - feel free to submit a PR

As for the use case you mentioned, if I understand correctly IVT won't help here. IACTG uses Cecil to read the assembly metadata.

Can you provide a stack trace for the error? And the .csproj

@weltkante
Copy link

I think the suggestion is to offer an alternative way of generating the reference assemblies for intellisense: you often can just add an InternalsVisibleToAttribute to the referenced assembly instead of modifying the visibility of everything (which you still need to inject via Cecil) - but for runtime you also need the IgnoresAccessChecksToAttribute because you can't deploy modified assemblies with IVT injected (when they are signed the signature won't match)

The suggestion being that this approach may be easier to implement, though I don't know if at this point it is worth to switch, considering there already is an implementation of changing visibility modifiers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants