-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Clean up ref files to more closely match GenerateReferenceSource #26187
Comments
tbh if the netcore packager for So like: - **/ref/* (anything in a ref folder)
+ (have the projects set to produce a reference only assembly based on the code in it). That way the ref folders in the projects can be deleted. Or better yet, do not strip the documentations on the actual assemblies of those target platforms (in the case of the xml documentations not being included in the nupkg's). |
From the issue description it doesn't seems like we need infrastructure work, moving back to area-Meta. |
@stephentoub Is this required for 3.0? |
Nope. |
Here is the baseline patch that I generated for dotnet/corefx#36966: Baseline.patch.txt I think we would want to review these at the very least, as they can be impactful to some scenarios (like interop or unsafe code):
|
Tagging subscribers to this area: @safern, @ViktorHofer |
We fixed the scenarios(there was a couple of them) where it was not working, but we never did a whole sweep up. |
I think we should do another pass. I remember for stuff that was manual added into the ref src files we added a feature to specify a file with ignored APIs so that should help us get it better for complicated assemblies like System.Runtime. |
Sorry if this is offtopic but how did you guys somehow pack the ref projects with the outputs from the runtime ones in the same packages? |
We use a custom packaging system that generates then packs a nuspec. You can still do it with CSProj. See https://docs.microsoft.com/en-us/nuget/reference/msbuild-targets#targetsfortfmspecificcontentinpackage |
Triage: We want to keep this in 5.0 as we want to fix the parameter name mismatches. |
@tannergooding by building with the If you just care about net8.0, you could add the following to the root Directory.Build.targets file: <PropertyGroup>
<!-- Hook onto the TargetsTriggeredByCompilation target which only runs when the compiler is invoked. -->
<TargetsTriggeredByCompilation Condition="'$(TargetFramework)' == 'net8.0'">
$(TargetsTriggeredByCompilation);
GenerateReferenceAssemblySource
</TargetsTriggeredByCompilation>
</PropertyGroup> That enables GenAPI to run for the net8.0 TFM in all our source projects. You then just need to build allconfigurations: All that said, to provide a comprehensive response I need to add the following (listed by priority):
While we are quite short on resources at the moment, I would be happy to drive an independent effort (not tied to the current release) to make progress on these topics above. If you want to help with that @tannergooding (or anyone else), feel free to ping me offline. |
Running /t:GenerateReferenceSource leads to a ton of differences between the generated files and what we currently have for the refs. Some of the differences are by design, e.g. ifdefs, but many are not:
It would be good to clean all of this up, in order to a) do an audit to make sure nothing important is wrong, and b) make it easier in the future to use GenerateReferenceSource for minor additions without then needing to deal with a ton of noise.
The text was updated successfully, but these errors were encountered: