Experience for a Component class library

[rynowak]

We need to define what the experience is for a class library with components. This probably can't be as simple as a empty project file for the reasons outlined below.

We have to address the following concerns:

• component libraries should be netstandard2.0 for blazor (at least for now)
• our inference of Razor targeting (version, configuration, mvc support) is based on netcoreapp version
• we shouldn't put msbuild files in a package to control the configuration because it will cause conflicts with other scenarios

A simple example of how to solve this would be something like:

<Project>
  <PropertyGroup>
    <IsComponentLibrary>true</IsComponentLibrary>
  </PropertyGroup>

....
</Project>

[rynowak]

For preview 2 we plan to update the Blazor.Build package to hide the necessary boilerplate since this template will still be a separate item in preview 2. No update yet on what the official story will be in RTM

[SteveSandersonMS]

For preview 2 we plan to update the Blazor.Build

This is done, but it's in Components.Build (which is in turn referenced by Blazor.Build for Blazor apps, but not for Razor Components apps).

[pranavkm]

I'm trying to lookup where the design notes for this was (I know we spoke about this once), but failing to come up with it. As I recall, the plan was

a) to use RazorLangVersion to light up features. This would allow us to know what feature sets to target when we introduce newer features in the future. This is particularly important for netstandard2.0 (ns2.0) targeting projects since there isn't a version number we could use to infer this. In netcoreapp targeting projects, we can use the netcoreapp version to do this.

b) For 3.0, ns2.0 targeting templates would have <RazorLangVersion>3.0</RazorLangVersion> in the projects. We would remove the .Components.Build and Blazor.Build packages since we should be able to infer all the details we need from this alone. netcoreapp3.0 targeting templates would have no package reference that adds build props or targets.

c) MVC specific features would light up based on the presence of a reference to Microsoft.AspNetCore.App. We could go further and light it up only if we think we have to work with Razor views or Razor Pages (#8161).

Does this correctly sum up what was discussed?

[rynowak]

c) MVC specific features would light up based on the presence of a reference to Microsoft.AspNetCore.App. We could go further and light it up only if we think we have to work with Razor views or Razor Pages

I think this sounds like the right thing from the user point of view, but I am not sure how you'd implement it. Right now we gather all of this information during the evaluation pass in MSBuild, and that's a really nice place to be.

[pranavkm]

Here are the MVC specific properties \ items we would have to consider moving if we relied on the presence of the shared fx:

• GenerateProvideApplicationPartFactoryAttribute
• GenerateRazorAssemblyInfo
• GenerateRazorHostingAssemblyInfo
• ProvideApplicationPartFactoryAttributeTypeName

I don't think it's important for any of these properties to be available in design-time \ vanilla evaluation.

[rynowak]

I think you're missing this stuff. https://github.com/aspnet/AspNetCore-Tooling/blob/master/src/Razor/src/Microsoft.NET.Sdk.Razor/build/netstandard2.0/Microsoft.NET.Sdk.Razor.Configuration.targets#L62

[pranavkm]

We would use the RazorLangVersion to infer that. To sum it up,

• RazorLangVersion determines configuration and behavior (such as do we compile Razor Components)
• Presence of AspNetCore.App enables MVC specific features such as the attributes we generate on the assembly. This makes it so that we don't have to disable feature sets - https://github.com/aspnet/AspNetCore/blob/master/src/Components/Build/src/targets/RazorCompilation.targets#L12-L14

[pranavkm]

Spoke to @rynowak offline and I missed the part where we need to infer two separate RazorConfiguration values for the same RazorLangVersion. So this would entail

a) Not inferring the RazorConfiguration based on TFM \ RazorLangVersion
b) Specifying RazorConfiguration in the MVC \ Razor Pages project templates:

<!-- MVC template -->

<Project Sdk="Microsoft.NET.Sdk.Web">

    <PropertyGroup>
        <TargetFramework>netcoreapp3.0</TargetFramework>
        <RazorConfiguration>MVC-3.0</RazorConfiguration>
    </PropertyGroup>
</Project>

<!-- Component template -->

<Project Sdk="Microsoft.NET.Sdk.Web">

    <PropertyGroup>
        <TargetFramework>netcoreapp3.0</TargetFramework>
    </PropertyGroup>
</Project>

<!-- Component \ Blazor class library template -->

<Project Sdk="Microsoft.NET.Sdk">

    <PropertyGroup>
        <TargetFramework>netstandard2.0</TargetFramework>
        <RazorLangVersion>3.0</RazorLangVersion>
    </PropertyGroup>
    
    <ItemGroup>
        <PackageReference Include="Microsoft.AspNetCore.Components" Version="3.0.0" />
    </ItemGroup>
</Project>

[pranavkm]

I think I have what the final draft of what the templates would look like. Would we want RazorLangVersion to be present in the MVC \ Components templates? We could infer it based on the TFM, but it does make the class library template stand out.

<!-- MVC template -->

<Project Sdk="Microsoft.NET.Sdk.Web">

    <PropertyGroup>
        <TargetFramework>netcoreapp3.0</TargetFramework>
        <RazorConfiguration>MVC-3.0</RazorConfiguration>
    </PropertyGroup>
</Project>

Versus

<!-- MVC template -->

<Project Sdk="Microsoft.NET.Sdk.Web">

    <PropertyGroup>
        <TargetFramework>netcoreapp3.0</TargetFramework>
        <RazorConfiguration>MVC-3.0</RazorConfiguration>
        <RazorLangVersion>3.0</RazorLangVersion>
    </PropertyGroup>
</Project>

[pranavkm]

One more iteration: we do not want AddRazorSupportForMvc to appear in netcoreapp3.0 targeting projects that reference the Web.SDK. It's only meant for projects targeting the Razor SDK that go on to add a reference to the Microsoft.AspNetCore.App shared fx. For netcoreapp3.0 targeting projects, here's what this needs to look like:

<!-- MVC / Razor Pages  -->

<Project Sdk="Microsoft.NET.Sdk.Web">
    <PropertyGroup>
        <TargetFramework>netcoreapp3.0</TargetFramework>
    </PropertyGroup>
</Project>

For Razor Class Libraries targeting the Razor.SDK

<!-- RCL -->

<Project Sdk="Microsoft.NET.Sdk.Razor">
    <PropertyGroup>
        <TargetFramework>netcoreapp3.0</TargetFramework>
        <AddRazorSupportForMvc>true</AddRazorSupportForMvc>
    </PropertyGroup>

    <ItemGroup>
        <FrameworkReference Include="Microsoft.AspNetCore.App" />
    </ItemGroup>
</Project>

<!-- Component class library targeting netcoreapp3.0 -->

<Project Sdk="Microsoft.NET.Sdk.Razor">
    <PropertyGroup>
        <TargetFramework>netcoreapp3.0</TargetFramework>
    </PropertyGroup>

    <ItemGroup>
        <PackageReference Include="Microsoft.AspNetCore.Components" Version="3.0.0" />
    </ItemGroup>
</Project>

For the first, we'd do this by moving the property in to the Web SDK.

[rynowak]

beans++

[pranavkm]

Fixing up MVC templates is currently blocked on #8809

[danroth27]

The only thing remaining here is to remove the AddRazorSupportForMvc property. @pranavkm Please open a separate issue to track this. Closing this issue.

[pranavkm]

Followeup tracked via #9207