-
Notifications
You must be signed in to change notification settings - Fork 10.3k
Change candidate resolution logic to allow assemblies depending on shared framework. #4440
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
Conversation
…ared framework. - This is required due to how AspNet Core is included via a framework reference now. In order to properly evaluate transitive projects that target AspNet Core 3.0 we'd need some level of information that they targeted a framework reference. This happens to be a missing feature in the sdk/nuget. Also, given that all of ASP.NET is now included via a framework reference the act of finding candidate assemblies to reduce the amount of assembly loads doesn't matter as much since we went from 100s of potential assemblies to only what the application currently targets. - Fixed a test issue where calling into BasicApi tests resulted in the attempted loading of EFCore.Design. Problem is EFCore.Design wasn't a dependency of our functional test project because of PrivateAssets="true" and therefore, when we tried to find candidate assemblies we read in the BasicApiTest.deps.json but operated on the functional tests.deps.json. I could have added the EFCore.Design package to the functional test project to fix this but given that the package wasn't being used choose to remove it instead. - Removed Mvc.Analyzers from AspNetCore.Mvc because it's no longer brought in via the shared framework. This was needed because with the new approach with always loading all dll's in an applications graph we'd attempt to load Mvc.Analyzers at which point we'd explode saying we couldn't load Roslyn (it's not available at runtime anymore). - Updated tests to reflect new expectations in regards to application part type loading. Addresses #4332
@@ -22,7 +22,6 @@ | |||
<ItemGroup Condition="'$(BenchmarksTargetFramework)' == ''"> | |||
<PackageReference Include="Microsoft.AspNetCore.Authentication.JwtBearer" Version="$(MicrosoftAspNetCoreAuthenticationJwtBearerPackageVersion)" /> | |||
<PackageReference Include="Microsoft.AspNetCore.Server.Kestrel" Version="$(MicrosoftAspNetCoreServerKestrelPackageVersion)" /> | |||
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="$(BenchmarksOnlyMicrosoftEntityFrameworkCoreDesignPackageVersion)" PrivateAssets="All" /> |
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.
Fixed a test issue where calling into BasicApi tests resulted in the attempted loading of EFCore.Design. Problem is EFCore.Design wasn't a dependency of our functional test project because of PrivateAssets="true" and therefore, when we tried to find candidate assemblies we read in the BasicApiTest.deps.json but operated on the functional tests.deps.json. I could have added the EFCore.Design package to the functional test project to fix this but given that the package wasn't being used choose to remove it instead.
candidateEntry.Classification = classification; | ||
|
||
return classification; | ||
throw new InvalidOperationException(Resources.FormatCandidateResolver_DifferentCasedReference(library.Name)); |
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 assume this can still happen if you have multiple framework references in a single project so let this be.
@@ -74,34 +74,6 @@ public void ResolveAssemblies_ReturnsRelatedAssembliesOrderedByName() | |||
Assert.Equal(new[] { ThisAssembly, assembly2, assembly1, assembly3 }, result); |
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.
Removed several tests from this class that were either 1. not valuable or 2. no longer valid.
@@ -9,7 +9,6 @@ | |||
</PropertyGroup> | |||
|
|||
<ItemGroup> | |||
<ProjectReference Include="..\Microsoft.AspNetCore.Mvc.Analyzers\Microsoft.AspNetCore.Mvc.Analyzers.csproj" PrivateAssets="None" /> |
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.
Analyzers don't make their way into the shared framework anymore anyhow. Having this caused assembly load issues because the functional tests would attempt to load the analyzers project which in turn explode at runtime because there's no Roslyn. This is a more significant issue that we may want to document. Up for suggestions here.
@@ -472,23 +472,6 @@ public async Task TestingInfrastructure_InvokesCreateDefaultBuilder() | |||
Assert.Equal("true", response); | |||
} | |||
|
|||
[Fact] | |||
public async Task ApplicationAssemblyPartIsListedAsFirstAssembly() |
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.
Boat loads of assemblies now and felt like the test wasn't very valuable.
Still need to benchmark the impact this has on startup performance with @sebastienros |
When benchmarking this we ran into an issue where the benchmark app was using a super old school (project.json) invalidly packaged netstandard1.5 package and then barfed ( In the meanwhile, going to work on running a benchmark on one of the test apps that doesn't use |
So the results make me want to cry 😢
|
Abandoning this. The perf results are too scary. Working with partner teams to get the right information into the deps file. |
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.
👍
Addresses #4332