Add infra to preserve customizations on package regen #1140
Conversation
|
We briefly talked about this in chat. Manual edits to NuGet.config are hard to isolate into separate files but there don't seem to be many. For the Customizations.cs, this definitely helps with new types or new members. Changing member is unfortunately not possible unless we tell GenAPI to exclude certain members (which is possible) and then add them to that secondary file. I don't think that's a good use here though as it would mean that we would need to list those symbols separately for GenAPI. Aside from that, this looks good and will definitely help with re-generating packages. |
| <ItemGroup Condition="'$(TargetFramework)' == 'netcoreapp1.1' or '$(TargetFramework)' == 'netstandard1.5'"> | ||
| <!-- Needs additional APIs that don't exist in the contract. --> | ||
| <Compile Include="$(MSBuildThisFileDirectory)Customizations.cs" /> | ||
| </ItemGroup> |
There was a problem hiding this comment.
It might be easier to just always import Customizations.cs files if they exist and put these TFM checks directly into that file. The roslyn repo often prefers that over conditioning in the project file and that worked great for them.
This would mean that the Customizations.cs would start with a #if NETCOREAPP1_1 || NETSTANDARD1_5 line.
There was a problem hiding this comment.
Hmm, I originally thought this pattern would provide more flexibility but I don't think that is necessarily the case. The pattern you suggest reduces the onboarding maintenance/ease of use. I will make this change.
3 participants
Introduced two new constructs to encapsulated customizations to the generated artifacts.
The benefit of using these files is that they will be preserved when the packages are regenerated. These constructs are not intended to support all scenarios e.g. add an attribute to a property or tweak a nuspec.
I am open to suggestions on the names of these constructs.
A number of projects were updated to utilize these new constructs.