Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Do build time discovery of MVC ApplicationParts #598

Merged
merged 7 commits into from
May 17, 2019
Merged

Do build time discovery of MVC ApplicationParts #598

merged 7 commits into from
May 17, 2019

Conversation

pranavkm
Copy link
Contributor

Use the result of RAR to identify dependencies that reference MVC

@pranavkm
Copy link
Contributor Author

@nguerrera would you mind reviewing the task and the target? You have way more experience here than anybody on the Razor team.

dougbu
dougbu reviewed May 15, 2019
View reviewed changes
Copy link
Member

@dougbu dougbu left a comment

Choose a reason for hiding this comment

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

eng/ and related changes look good but I didn't review the c# files

src/Razor/test/testapps/AppWithP2PReference/AppWithP2PReference.csproj Outdated Show resolved Hide resolved
@dougbu
Copy link
Member

dougbu commented May 15, 2019

@nguerrera would you mind reviewing the task and the target? You have way more experience here than anybody on the Razor team.

@pranavkm
Copy link
Contributor Author

pranavkm commented May 15, 2019 •
edited
Loading

Followup in MVC: dotnet/aspnetcore#10271

@pranavkm pranavkm requested a review from nguerrera May 15, 2019 19:46
rynowak
rynowak reviewed May 15, 2019
View reviewed changes
....Sdk.Razor/build/netstandard2.0/Microsoft.NET.Sdk.Razor.MvcApplicationPartsDiscovery.targets Outdated
<PropertyGroup Condition="'$(_ReferencesMicrosoftAspNetCoreApp)' == ''">
<_ReferencesMicrosoftAspNetCoreApp>@(FrameworkReference->AnyHasMetadataValue('Identity', 'Microsoft.AspNetCore.App'))</_ReferencesMicrosoftAspNetCoreApp>
</PropertyGroup>
</Target>
Copy link
Member

Choose a reason for hiding this comment

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

I'd like to understand more about this? What kinds of test can't we write without it?

I'm also not sure that this works.

IIRC The dependencies of _DiscoverMvcApplicationParts won't be executed unless _DiscoverMvcApplicationParts is going to be. So using the dependencies of a target to configure whether the target runs doesn't super work.

Copy link
Member

Choose a reason for hiding this comment

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

It's possible to run a target that determines whether a later target will run, but it is complex and subtle. If you can avoid that situation, please do so. If you can't, loop me back in and I'll look at it with a magnifying glass.

Copy link
Contributor Author

@pranavkm pranavkm May 15, 2019 •
edited
Loading

Choose a reason for hiding this comment

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

This was obviously incorrect, but I think the scenario it's attempting to rule out is a vanishingly small number or projects (targets Razor or Web SDK, targets netcoreapp3.0 or later, but does not reference Microsoft.AspNetCore.App. Plus in the most ordinary case, it'll end up ruling that there's nothing to do here. Removed this

rynowak
rynowak reviewed May 15, 2019
View reviewed changes
....Sdk.Razor/build/netstandard2.0/Microsoft.NET.Sdk.Razor.MvcApplicationPartsDiscovery.targets
<_MvcAssemblyName Include="Microsoft.AspNetCore.Mvc.Razor" />
<_MvcAssemblyName Include="Microsoft.AspNetCore.Mvc.RazorPages" />
<_MvcAssemblyName Include="Microsoft.AspNetCore.Mvc.TagHelpers" />
<_MvcAssemblyName Include="Microsoft.AspNetCore.Mvc.ViewFeatures" />
Copy link
Member

Choose a reason for hiding this comment

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

Do we need to list everything here and maintain that? What would happen if just listed Microsoft.AspNet.Mvc.Abstractions?

What will we do if we do a big squish in the future? Make this depend on the TFM?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What would happen if just listed Microsoft.AspNet.Mvc.Abstractions?

We want a way to avoid Mvc assemblies being treated as "ReferencesMvc" i.e. we don't want to treat Microsoft.AspNetCore.Mvc.Core as an application part.

What will we do if we do a big squish in the future? Make this depend on the TFM?

I guess so. More importantly, I think it's generally ok assemblies listed here. If in 4.0, there's only Microsoft.AspNetCore.Mvc and none of the rest, the dependency lookup is still correct since Microsoft.AspNetCore.Mvc.Core would generally never appear in your dependency graph

Copy link
Member

Choose a reason for hiding this comment

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

I assume then that this works correctly when a non-existent assembly is specified (it kinda has to).

@pranavkm
Copy link
Contributor Author

🆙 📅

rynowak
rynowak reviewed May 16, 2019
View reviewed changes
src/Razor/src/Microsoft.NET.Sdk.Razor/DiscoverMvcApplicationParts.cs Outdated

ApplicationPartAssemblyNames = assemblyNames.Count > 0 ?
assemblyNames.ToArray() :
Array.Empty<string>();
Copy link
Member

Choose a reason for hiding this comment

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

I would hope that List<>.ToArray() is smart enough to do this.

rynowak
rynowak reviewed May 16, 2019
View reviewed changes
src/Razor/src/Microsoft.NET.Sdk.Razor/DiscoverMvcApplicationParts.cs Outdated
assemblyNames.ToArray() :
Array.Empty<string>();

return !Log.HasLoggedErrors;
Copy link
Member

Choose a reason for hiding this comment

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

Will this actually happen? it's probably better if you just return true here right? Or do you have a reason to expect different.

Copy link
Member

Choose a reason for hiding this comment

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

I really like and recommend this pattern. If you're careful it's slightly inefficient but harmless. When someone makes a small mistake (logs an error but a bug keeps the error from propagating all the way back out to the Execute() return value), it prevents the super confusing "build succeeded with errors" case.

(In hindsight, it should have been void Execute() with logging an error the way to fail it. Alas.)

Copy link
Member

Choose a reason for hiding this comment

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

Zoinks! I've been overruled then 🤣

rynowak
rynowak reviewed May 16, 2019
View reviewed changes
src/Razor/src/Microsoft.NET.Sdk.Razor/DiscoverMvcApplicationParts.cs Outdated

namespace Microsoft.AspNetCore.Razor.Tasks
{
public class DiscoverMvcApplicationParts : Task
Copy link
Member

Choose a reason for hiding this comment

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

How would you feel about removing the MVC terminology from this? There's nothing MVC in it.

rynowak
rynowak reviewed May 16, 2019
View reviewed changes
src/Razor/src/Microsoft.NET.Sdk.Razor/ResolveReferenceItem.cs Outdated

namespace Microsoft.AspNetCore.Razor.Tasks
{
public class ResolveReferenceItem
Copy link
Member

Choose a reason for hiding this comment

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

internal?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Use the renamed type in tests.

@pranavkm pranavkm merged commit e79d560 into master May 17, 2019
@ghost ghost deleted the prkrishn/mvc-discovery branch May 17, 2019 20:14
@dougbu dougbu mentioned this pull request May 18, 2019
Merged
@jtkech jtkech mentioned this pull request May 21, 2019
Merged
JunTaoLuo pushed a commit to dotnet/aspnetcore that referenced this pull request May 17, 2020
@pranavkm
Do build time discovery of MVC ApplicationParts (dotnet/razor#598)
b5a7dab 
* Do build time discovery of MVC ApplicationParts
\n\nCommit migrated from dotnet/razor@e79d560
dougbu pushed a commit to dougbu/razor-compiler that referenced this pull request Nov 17, 2021
@pranavkm
Do build time discovery of MVC ApplicationParts (dotnet/razor#598)
f38de13 
* Do build time discovery of MVC ApplicationParts
\n\nCommit migrated from dotnet/razor@e79d560

Commit migrated from dotnet/aspnetcore@b5a7daba2b8f
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@rynowak rynowak rynowak approved these changes

@rainersigwald rainersigwald rainersigwald left review comments

@dougbu dougbu dougbu left review comments

@ajaybhargavb ajaybhargavb Awaiting requested review from ajaybhargavb

@NTaylorMullen NTaylorMullen Awaiting requested review from NTaylorMullen

@nguerrera nguerrera Awaiting requested review from nguerrera

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@pranavkm @dougbu @nguerrera @rynowak @rainersigwald