Skip to content

Add LinkabilityChecker tool #40342

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

Merged
merged 9 commits into from
Feb 24, 2022
Merged

Add LinkabilityChecker tool #40342

merged 9 commits into from
Feb 24, 2022

Conversation

JamesNK
Copy link
Member

@JamesNK JamesNK commented Feb 21, 2022

Addresses #27384

Replicate https://github.com/dotnet/aspnetcore/tree/5760f2864016081a142642b417db17e5340a1d67/src/Components/WebAssembly/testassets/WasmLinkerTest

I've removed the wasm specific build attributes:

    <RuntimeIdentifier>browser-wasm</RuntimeIdentifier>
    <SelfContained>true</SelfContained>
    <UseMonoRuntime>true</UseMonoRuntime>
    <UsingMicrosoftNETSdkBlazorWebAssembly>true</UsingMicrosoftNETSdkBlazorWebAssembly>

For lack of anywhere else to put it, I've placed the new testassets project in Shared. @aspnet-build let me know if you'd like it moved somewhere else.

@JamesNK JamesNK requested review from a team and Pilchie as code owners February 21, 2022 22:38
@JamesNK
Copy link
Member Author

JamesNK commented Feb 21, 2022

@pranavkm After removing the wasm/mono attributes the project generates an error:

   "C:\Development\Source\aspnetcore\src\Shared\test\testassets\LinkerTest\LinkerTest.csproj" (default target) (1:7) ->
   (ILLinkTrimProjects target) ->
     ILLink : error IL1009: Assembly reference 'System.Security.Permissions' could not be resolved. [C:\Development\Source\aspnetcore\src\Shared\test\testassets\LinkerTest\LinkerTest.csproj]
     ILLink : error IL1009: Assembly reference 'System.Threading.AccessControl' could not be resolved. [C:\Development\Source\aspnetcore\src\Shared\test\testassets\LinkerTest\LinkerTest.csproj]

There are no references to those projects in aspnetcore.

Any idea what is wrong? If not, who should I talk to?

@davidfowl
Copy link
Member

You might want to also get rid of this test

public async Task LinkedApplicationWorks()

@JamesNK JamesNK requested a review from dougbu as a code owner February 22, 2022 14:41
@pranavkm
Copy link
Contributor

@JamesNK I'm gonna guess there's a reference to these assemblies in the graph somewhere (maybe a TypeForwardedTo) which requires this assemblies to be available to the trimmer. Adding these package reference appears to help here.

@pranavkm
Copy link
Contributor

FYI - I force pushed to this branch after rebasing on main

Copy link
Member

@wtgodbe wtgodbe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

src/Shared seems reasonable to me

@dougbu
Copy link
Contributor

dougbu commented Feb 22, 2022

For lack of anywhere else to put it, I've placed the new testassets project in Shared. @aspnet-build let me know if you'd like it moved somewhere else.

src/Shared seems reasonable to me

I don't feel strongly about this but what is "shared" about this project❔ Not quite understanding how it fits into this repo in the first place and where it might fit otherwise. I'd feel better if the project were in its own src/ directory than under Shared.

@JamesNK
Copy link
Member Author

JamesNK commented Feb 22, 2022

There isn't anything shared. Basically, this is a project that checks linking warnings in shipping projects. It will end up referencing most shipping projects. It's generic, but it isn't itself shared.

An alternative location I considered was /src/Tools. It is kind of a tool for checking for linker warnings and generating linker suppression.

@JamesNK
Copy link
Member Author

JamesNK commented Feb 22, 2022

FYI - I force pushed to this branch after rebasing on main

You're a ⭐

@dougbu
Copy link
Contributor

dougbu commented Feb 22, 2022

For lack of anywhere else to put it, I've placed the new testassets project in Shared. @aspnet-build let me know if you'd like it moved somewhere else.

src/Shared seems reasonable to me

I don't feel strongly about this but what is "shared" about this project❔ Not quite understanding how it fits into this repo in the first place and where it might fit otherwise. I'd feel better if the project were in its own src/ directory than under Shared.

There isn't anything shared. Basically, this is a project that checks linking warnings in shipping projects. It will end up referencing most shipping projects. It's generic, but it isn't itself shared.

An alternative location I considered was /src/Tools. It is kind of a tool for checking for linker warnings and generating linker suppression.

src/Tools/ would work for me. Other options might be src/Testing/test/ or src/CheckLinkability/.

@pranavkm
Copy link
Contributor

@JamesNK / @dougbu I was playing around with this change and came up with pranavkm@0a96a3d. The idea is to use ProjectReferenceProvider items to find projects that are part of the shared framework and are trimmable. This negates the need to maintain a separate list of trimmable projects.

Thoughts?

@dougbu
Copy link
Contributor

dougbu commented Feb 23, 2022

I … came up with pranavkm@0a96a3d. The idea is to use ProjectReferenceProvider items to find projects that are part of the shared framework and are trimmable. This negates the need to maintain a separate list of trimmable projects.

The idea sounds reasonable though I suggest things may be simpler if the metadata were collected when we run CodeGen.proj rather than added in a new corner of our infrastructure and re-generated every time trimmability is tested. Put another way, I agree w/ the direction but suggest getting there by a slightly different route.

The targets in CodeGen.proj and the supporting bits at the bottom of ResolveReferences.targets could easily be extended to collect $(IsTrimmable) information. I leave it up to you whether you want to generate a brand new file in eng/ or add the information to one of eng/ProjectReferences.props or eng/SharedFramework.Local.props.

More generally, I'd like to be fairly sure we do not limit checking assemblies are trimmable to the shared framework projects. I could see us wanting to ensure something that ships only in a package is and remains trimmable.

@JamesNK
Copy link
Member Author

JamesNK commented Feb 23, 2022

@pranavkm I've moved the app to tools. Feel free to apply your changes.

I added a couple of projects, up until I hit one that generated trim warnings: Microsoft.AspNetCore.Http.Abstractions. I fixed some warnings, most are still around. I want to double-check the warnings show up in build.

@@ -136,7 +137,8 @@ public void SetValue(object instance, object? value)
/// <param name="typeInfo">The type info to extract property accessors for.</param>
/// <returns>A cached array of all public properties of the specified type.
/// </returns>
public static PropertyHelper[] GetProperties(TypeInfo typeInfo)
public static PropertyHelper[] GetProperties(
Copy link
Member Author

@JamesNK JamesNK Feb 23, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think PropertyHelper in general is incompatible with trimming.

@@ -95,6 +95,7 @@ public RouteValueDictionary()
/// property names are keys, and property values are the values, and copied into the dictionary.
/// Only public instance non-index properties are considered.
/// </remarks>
[RequiresUnreferencedCode("RouteValueDictionary uses reflection to generate the route values.")]
public RouteValueDictionary(object? values)
Copy link
Member Author

@JamesNK JamesNK Feb 23, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we might want new public API ctors for RouteValueDictionary.

public RouteValueDictionary(object? values);
+public RouteValueDictionary(IDictionary<string, object> values);

Copying values from a IDictionary is fine. Copying values via reflection from public properties seems incompatible with trimming.

@Tratcher Tratcher removed their request for review February 23, 2022 18:55
@pranavkm
Copy link
Contributor

@JamesNK lets do this in two passes - we can get this change in once we resolve the current failure and I'll send a PR to use @dougbu's suggestion to find projects that are interesting to test.

@pranavkm pranavkm mentioned this pull request Feb 23, 2022
@@ -12,7 +12,7 @@ Microsoft.AspNetCore.Http.Features.FeatureCollection
<IsAspNetCoreApp>true</IsAspNetCoreApp>
<GenerateDocumentationFile>true</GenerateDocumentationFile>
<PackageTags>aspnetcore</PackageTags>
<Nullable>enable</Nullable>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is nullable being removed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nullable is now turned on by default for all projects. Removing because it's redundent.

@JamesNK JamesNK changed the title Add LinkerTest project Add LinkabilityChecker tool Feb 23, 2022
@JamesNK JamesNK merged commit e0110ad into main Feb 24, 2022
@JamesNK JamesNK deleted the jamesnk/linkertest branch February 24, 2022 04:15
@ghost ghost added this to the 7.0-preview3 milestone Feb 24, 2022
@amcasey amcasey added area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions and removed area-runtime labels Aug 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants