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
Migration: handle project.json "shared" key for internal types access #7514
Comments
Can you elaborate on this issue and add repro steps? |
Open the attached project. In the project.json world, the "shared": "*.cs" line in the TestLibrary project.json file allows it's internal class to be used in TestApp. After migration we cannot access the internal Helper class and the build fails. |
That's the first I've heard of that feature. 😄 Is this supported in a .csproj world yet? |
I guess we'd link them? |
There's InternalsVisibleToAttribute, but that's only to specify which friend assemblies can reference internals. I don't know of a way to say all internals are visible to all other assemblies which is what this PJ statement seems to say. I think we should just not support this feature :) |
I suspect it's probably the right to just link the files in MSBuild. In fact, that's probably what "shared" is doing. It's akin to Shared Projects in VS. Something like... <Compile Include="..\TestLibrary\Helper.cs">
<Link>Helper.cs</Link>
</Compile> |
Hmm, linking them wont be sufficient. In the old world NuGet or dotnet cli (not sure which one was responsible) would special case the packing of a project that had the "shared" property and build a nupkg that had content files that would then be copied into users projects when restored. If we simply link the cs files it doesn't fix the ability to pack and re-use the shared project. Support for "shared" was dropped in favor of NuGet/Home#3683. If there's a way we can transition the existing "shared" project to utilize the new NuGet feature then we'd be feature complete; otherwise, I'd recommend failing |
Hmmm... If I I understand you correctly it sounds like the files would also have to be linked in order to compile a project that referenced and used "shared" files from another project, correct? That is, there's two things we'd need to do in order to fully support the shared property: both linking files and doing some other work to support this new NuGet feature. Is that right? |
@DustinCampbell correct.
|
Ok, I want to clarify something here. If I have two projects: project A and Project B and project B has shared: **/*.cs in its project json. When we migrate these projects, does that mean that we need to translate that shared property in projectB into a bunch of Links in projectA? If so, I am not sure we should take this fix for RTM. This would mean that migration would require a project's dependencies project.json to still be around, so that we could inspect it and we actually removed that requirement because this can't happen in VS, since VS handles its own backup and it moves the files to backup as each project gets migrated. |
What does the old project.json based dotnet do? |
@krwq We are not going to take this for RTM. This would require the dependencies for a project to ling around so that we can look at them and see if we need to include their files. We currently can't do that because of VS, since it moves the PJ to backup individually as it migrates. We could introduce a parameter for VS to pass to us, but it does not meet the bar right now. |
This issue was moved to dotnet/cli-migrate#35 |
No description provided.
The text was updated successfully, but these errors were encountered: