Open cremor opened 1 year ago
See similar issue:
Thanks, but I don't think there is a way to apply this to my situation, right? I don't need to exclude PolySharp from running in one project like in the linked issue. Instead I'd need it to run even though it thinks it doesn't need to.
I’m not sure. It sounded like the identical issue to mine so I posted the link. I had 2 viable workarounds which both worked for me, one being to ensure the TFM for all projects matched, and the other being to exclude PolySharp from the third project. If that’s viable you could do so with a ProjectReference Remove in the csproj while maintaining global package references.
I only have a single target framework (net48) and need PolySharp in all projects.
Without knowing anything how PolySharp works internally I see three possible solutions:
PolySharpIncludeGeneratedTypes
).
This would allow a fix for my problem without changing anything for existing users. But it would also require other users that have the problem to find that setting and known to enable it to fix this (complicated) problem.I had the exact same issue [InternalsVisibleTo]
in multiple referenced projects, giving the same issue as above.
My solution was as follows:
<PolySharpUsePublicAccessibilityForGeneratedTypes>true</PolySharpUsePublicAccessibilityForGeneratedTypes>
Each project gets only the polyfills needed for the TFM. You would not get per project customization, but you get the benefits of PolySharp.
Edit: If public accessibility is a problem for you see alternate steps in the comment below
This issue is preventing me from switching from the IsExternalInit and IndexRange nuget packages to PolySharp (which I would otherwise prefer as a one-stop-solution). @cremor's suggested solutions would all be acceptable for me.
@Applesauce314's public generated types workaround has the side effect of making the generated types visible to consumers of your code. If two libraries use that workaround you cannot (easily) use both of them at the same time. So that does not work for me.
@Applesauce314's public generated types workaround has the side effect of making the generated types visible to consumers of your code. If two libraries use that workaround you cannot (easily) use both of them at the same time. So that does not work for me.
@m-ringler I checked if removing <PolySharpUsePublicAccessibilityForGeneratedTypes>true</PolySharpUsePublicAccessibilityForGeneratedTypes>
and instead adding [assembly: InternalsVisibleTo("assembly.Name")]
for each project that needs the polyfills, and it worked, I think that would satisfy the need to not have the polyfills public, I did not test having multiple polyfill projects that do this, but I would expect it to work.
Is there an ideal solution to this issue yet?
I just encountered it when creating a .NET 6.0 unit test project for a library that is targeting .NET Standard 2.0 while using PolySharp. Because the library has internals visible to the unit test project, I get this error.
It seems I can work around it by excluding IsExternalInit from generation in the unit test project. I want PolySharp to handle this by default though, so this error doesn't happen.
Is there an ideal solution to this issue yet?
I just encountered it when creating a .NET 6.0 unit test project for a library that is targeting .NET Standard 2.0 while using PolySharp. Because the library has internals visible to the unit test project, I get this error.
It seems I can work around it by excluding IsExternalInit from generation in the unit test project. I want PolySharp to handle this by default though, so this error doesn't happen.
I don't know if it is "ideal", but I have been using the separate project with the default
internal accessibilty and [assembly:InternalsVisibleTo()]
for each project that uses it for a month now.
The only problem I have had so far was when I added a new project and forgot to add it to the list, spent a few minutes looking for a broken config before I remembered.
Hi, this problem is currently blocking us from using PolySharp in our larger solution. Out of available options I think having a MSBuild flag for "Always generating polyfills" is the best option here?
I would concur. And this happens a lot with unit test projects. I publish a lot (77+) of NuGet packages that multi-target net8.0;netstandard2.0;net6.0. If Always generate polyfills works well, perhaps it should be the default at least for unit test projects?
Bump. This issue also blocks PolySharp usage in our solution.
Description
If one project references two other projects that both have InternalsVisibleTo to the first project defined, the first project can't use C# features that should be enabled by PolySharp.
Reproduction Steps
<LangVersion>11.0</LangVersion>
for all projects.<ItemGroup><InternalsVisibleTo Include="ThirdProjectName" /></ItemGroup>
to the referenced projects.Expected Behavior
Should be able to compile the code.
Actual Behavior
I get compile errors about missing compiler required members.
System info
This section should contain useful info such as:
Additional context
It looks like the compiler error is missleading. The members are not missing, they are there multiple times (so the compiler sees the internal types from both referenced projects). If only one referenced project with
InternalsVisibleTo
exists then no error happens.It looks like PolySharp also sees the internal types of the other projects and doesn't generate any additional types. (It only generates the TypeForwards.) But I can actually fix the problem and compile my code when I manually add the required compiler types. Then the compiler doesn't error any more, even though it should then actually see each type 3 times. So maybe the fix for this would be to still generate the required types if the source generator only finds an internal type from another assembly in the current project?
In my actual solution I don't add PolySharp to each project individually but instead use Global Package References. But it seems like this doesn't change anything for this problem.