-
Notifications
You must be signed in to change notification settings - Fork 4.9k
Cleanup netfx-specific code from projects that no longer build in netfx configurations #31818
Cleanup netfx-specific code from projects that no longer build in netfx configurations #31818
Conversation
…onals from System.IO.Compression.csproj
….InteropServices.RuntimeInformation.csproj
…aphy.Algorithms.csproj
<PropertyGroup> | ||
<AssemblyName>System.Runtime.Serialization.Xml</AssemblyName> | ||
<IsPartialFacadeAssembly>true</IsPartialFacadeAssembly> | ||
<IsPartialFacadeAssembly>true</IsPartialFacadeAssembly> <!-- actually it looks more like a 100% facade to me now?... --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ViktorHofer I'm going to delete that comment, but yes, I just wanted to point that out in case that means there's some way to simplify this project/assembly...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
right, that's why I pinged my colleagues who should know if there's a way to do so.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We still need to be able to build it from source so this project needs to stay. PartialFacade just means "potentially" partial. We actually have plenty of full facades in the repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ericstj Thanks for clarifying!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I can delete the <Reference>
and <ProjectReference>
bits of the project now though, now that there's no code which would need the references to compile.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I can delete the and bits of the project now though, now that there's no code which would need the references to compile.
Well, that didn't work for some reason that I don't understand yet. I'll roll it back.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason why that didn't work is that when we make it a facade, we generate some code that will create the type forwards on the assembly. If you remove all the references, then that generated code won't compile, which is why we still need at least the required references to make that generated source to compile.
<Compile Include="System\Data\Common\IDbColumnSchemaGenerator.cs" /> | ||
</ItemGroup> | ||
<ItemGroup Condition="'$(TargetGroup)' != 'netfx'"> | ||
<ItemGroup> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd join groups with the same condition and same items types (or no condition) - make sure to sort it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@krwq I am not sure that everything was already actually sorted alphabetically, (e.g. why does Xml subfolder come beforeData? Maybe there is another convention in operation here?) but I am fine with keeping it tidy by merging groups, and maintaining approximate 'sortedness'.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hope this is satisfactory now.
…me.Serialization.Xml and System.Security.SecureString.
…em.Runtime.Serialization.Xml and System.Security.SecureString." This reverts commit 7de0b76.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I already went through the changes last week and just looked at the new commits. Thanks a lot for doing this! The changes look good 👍
Please solve the conflicts and when CI is green I'm happy to merge. |
</ItemGroup> | ||
<ItemGroup Condition="'$(TargetGroup)' != 'netfx'"> | ||
<Compile Include="System.Net.Sockets.netcoreapp.cs" /> | ||
</ItemGroup> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIT: Given that System.Net.Sockets.netcoreapp.cs
will be included every time, perhaps we should just fold the contents into System.Net.Sockets.cs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds nice, but just a little bit more involved than I wanted this to be, so hope its OK if I pass on that one!
<ItemGroup Condition="'$(TargetGroup)' != 'netfx'"> | ||
<Compile Include="System.Net.Sockets.netcoreapp.cs" /> | ||
</ItemGroup> | ||
<ItemGroup> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIT: No need for an extra <ItemGroup>
here, since we can simply use the Compile one for ProjectReference as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I must disagree. We keep Compile items separate from ProjectReferences in corefx.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yup you are right, didn't notice that it was ProjectReferences on the other ItemGroup.
#if uapaot | ||
private const string FrameworkName = ".NET Native"; | ||
#elif netfx || win8 | ||
#elif win8 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right in your comment, looks like win8
can be removed as well, but I'm fine with scoping your PR to just netfx for now, and do another pass later for other unused configurations.
<Reference Include="System.Runtime.Serialization" /> | ||
</ItemGroup> | ||
<ItemGroup Condition="'$(TargetGroup)' != 'netfx'"> | ||
<ItemGroup> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIT: Same here, just use the previous ItemGroup
for cleanliness
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably need Compile items separate from ProjectReferences here too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
right.
<ItemGroup Condition="'$(TargetGroup)'=='netfx'"> | ||
<Reference Include="mscorlib" /> | ||
<Reference Include="System.Runtime.Serialization" /> | ||
<Compile Include="System\Runtime\Serialization\ISerializationSurrogateProvider.cs" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't we delete this file from our source as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like we still need this one. In the old project, instead of the source file being included unconditionally, it was being conditionally included for both 'netfx' true and non-'netfx' targets. Now it will become just an unconditional include.
</Compile> | ||
</ItemGroup> | ||
<ItemGroup Condition=" '$(TargetsWindows)' == 'true' and '$(IsPartialFacadeAssembly)' != 'true'"> | ||
<ItemGroup Condition=" '$(TargetsWindows)' == 'true' "> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIT: Extra space between single quote and double-quote
<Configurations>netcoreapp-Unix-Debug;netcoreapp-Unix-Release;netcoreapp-Windows_NT-Debug;netcoreapp-Windows_NT-Release;uap-Windows_NT-Debug;uap-Windows_NT-Release;uapaot-Windows_NT-Debug;uapaot-Windows_NT-Release</Configurations> | ||
</PropertyGroup> | ||
<ItemGroup Condition="'$(TargetGroup)'=='netfx'"> | ||
<Compile Include="System\Threading\DeferredDisposableLifetime.cs" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why didn't we delete this file as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good one, I don't think we need it!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a few easy comments to address, but overall this looks great and ready to go! Thanks so much for helping cleaning this up! 😄
Thanks a lot for the help @TimLovellSmith 👍 |
…d in netfx configurations (dotnet#31818)" This reverts commit 21eb9aa89fae41b73f87c073abd95041ecf1b0e0. Signed-off-by: dotnet-bot <[email protected]>
…d in netfx configurations (#31818)" This reverts commit 21eb9aa89fae41b73f87c073abd95041ecf1b0e0. Signed-off-by: dotnet-bot <[email protected]>
…fx configurations (dotnet/corefx#31818) * Remove Crc32Helper.Managed.cs and '$(TargetGroup)' == 'netfx' conditionals from System.IO.Compression.csproj * Remove netfx conditionals from System.Data.Common.csproj * Remove netfx conditionals from System.Diagnostics.StackTrace.csproj * Remove 'netfx' and 'net46' conditionals from System.Net.Http.csproj * Remove 'netfx' conditionals from System.Net.Sockets.csproj * Remove 'netfx', 'net462' and 'net47' conditionals from System.Runtime.InteropServices.RuntimeInformation.csproj * Remove 'netfx' conditionals from System.Runtime.Serialization.Primitives.csproj * Remove 'netfx' conditionals from System.Runtime.Serialization.Xml.csproj * Remove 'netfx' and 'net47' conditionals from System.Security.Cryptography.Algorithms.csproj * Remove 'netfx' conditionals from System.Security.SecureString.csproj * Remove 'netfx' conditionals from System.Threading.Overlapped.csproj * Remove 'netfx' conditionals from System.Xml.XPath.XDocument.csproj * Trim out unused source file DeferredDisposableLifetime.cs Commit migrated from dotnet/corefx@6a0ecec
This is to fix #31712. It removes several old interop-only source files, and a bunch of conditional logic around '$(TargetGroup)' == 'netfx' (or 'net45', 'net46', 'net47') for those projects where configuration.props no longer actually includes any such configurations.
Side note 1: this resulted in deleting all source files for System.Runtime.Serialization.Xml, System.Threading.Overlapped, and System.Security.SecureString. I'm not sure if that means it will merit some additional cleanups.
Side note 2: while I was doing this, it looked to me like we might possible be able to cleanup some 'win8' conditionals in some projects too, but I didn't try that.