Would this work if you don't have the latest SDK or VS installed? Because according to this you couldn't declare the EmbeddedAttribute yourself if the compiler would have created one prior to VS 17.13. See also dotnet/roslyn#76523

Also, just to have it documented here too: @MarkKharitonov found a problem with this solution, see #50 (comment)

@cremor yeah this will work fine, I'm still using Roslyn 4.3.0, and not that new API that was added 🙂

I didn't mean the new API. I meant that quote from the PR dotnet/roslyn#76523:

Today, [...] if we need to generate it, we error if the user defines one.

I understand this as:

If you use a compiler version before VS 17.13
and
you define EmbeddedAttribute yourself (e.g. by using PolySharp with this new changes)
and
you have something in your code that would lead Roslyn to emit the EmbeddedAttribute itself

then you would get an error.

I haven't tested this. I just wanted to raise awareness.

Small suggestion. Recent Roslyn APIs have an convenience API .AddEmbeddedAttributeDefinition(), which will emit the EmbeddedAttribute type for you. As opposed to including it directly like you are in this PR. If you make including of the [Embedded] marker on all the types opt-in via an MSBuild variable, then you can also opt in having the EmbeddedAttribute at all via conditionally calling that API.

You could re-create this helper if you are not on the newer Roslyn packages: https://github.com/dotnet/roslyn/blob/51d2ed9e47364b57024f7715c2e2b2e385fe1454/src/Compilers/Core/Portable/SourceGeneration/IncrementalContexts.cs#L144

@Sergio0694 Is there anything remaining here to get this completed?

@Sergio0694 - [reposted from #50]

Seems the solution is still problematic.

Although it resolves #50 and #103, it introduces another problem:
I tested the dev/embedded-types and what I found:

The same setup: one unit-test project consumes internals from several other library projects in the same solution.

All projects use PolySharp, the unit-test project also uses it (otherwise, what's the sense).
All projects are configured with:

• PolySharpUsePublicAccessibilityForGeneratedTypes: false
• PolySharpIncludeRuntimeSupportedAttributes: true
• PolySharpUseEmbeddedAttributeForGeneratedTypes: true

The library projects have the [assembly: InternalsVisibleTo()]

Polyfills are working well in the lib projects themselves, but aren't generated in the unit-test project. Instead, it produces:

• CS0122: 'DynamicallyAccessedMemberTypes' is inaccessible due to its protection level (once per per dependency);

In addition, if any polyfills are used in the unit-test project:

• CS0246: The type or namespace name '...' could not be found (are you missing a using directive or an assembly reference?)
• CS0518: Predefined type '...' is not defined or imported
• CS0656: Missing compiler required member '.....ctor'

Please, find the minimal repro solution attached.
_test_02.zip

The archive contains the solution test_02.slnx for VS2022 with 3 projects targeted to .net481.
All 3 projects use the PolySharp. The t.test.csproj exposes the problem on build.

To reproduce the issue:

• prerequisites: build the dev/embedded-types

1. unpack the solution;
2. change the PackageReference Include="PolySharp" in the Directory.Build.props to use manually built dev/embedded-types;
3. build the solution with any predefined configuration. The build fails on the t.test.csproj;

Regards.

@ns88ns that should be fixed by #134.

@Youssef1313 just me finding some time to review and merge everything 😄