Razor Class Library Build Time Serious Regression with .NET 9 SDK

[TimPurdum]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Build time for a Razor Class Library with significant static assets (JavaScript files) is more than 4x slower with the .NET 9 SDK than with the .NET 8 SDK.

| SDK Version | 1st Build (after clean/restore) | 2nd Build |
|-------------|---------------------------------|-----------|
| 8.0.404     | 36.95 s                         | 23.90 s   |
| 9.0.100     | 143.5 s                         | 123.8 s   |

Expected Behavior

I would expect no such regression without changing code or at least target level. This appears to be driven mostly by the new ResolveProjectStaticWebAssets logic, which takes more than 50% of the length of the build, with a good bit of what's left being used by the other "StaticAsset" build steps.

Steps To Reproduce

1. Make sure you have 8.0.404 and 9.0.0 SDKs installed

2. Clone https://github.com/dymaptic/GeoBlazor

3. In the src folder, set the global.json to

   {
     "sdk": {
       "version": "8.0.0",
       "rollForward": "latestMinor"
     }
   }
   

4. Just to prove that these aren't related, you can delete or comment out all the custom Targets in dymaptic.GeoBlazor.Core.csproj (otherwise you do need npm and pwsh installed as well)

5. Navigate to src/dymaptic.GeoBlazor.Core in a terminal, and run the following commands

   dotnet clean
   dotnet restore
   dotnet build -f net8.0
   dotnet build -f net8.0
   

6. Edit the global.json file, replace 8.0.0 with 9.0.0

7. Run the commands from step 4 again

Exceptions (if any)

No response

.NET Version

No response

Anything else?

I expect this is going to be a big issue for any other libraries that wrap significant JavaScript modules. At the very least, I need a workaround to ameliorate this regression so I can move this library to .NET 9 and beyond.

[javiercn]

@TimPurdum thanks for contacting us.

We've identified some performance issues when dealing with large sets of assets. We are working on performance improvements for future SDK releases. I just tested with your project and the build seems to speed up significantly.

  dymaptic.GeoBlazor.Core net8.0 succeeded (6.3s) → bin\Debug\net8.0\dymaptic.GeoBlazor.Core.dll
  dymaptic.GeoBlazor.Core net7.0 succeeded (13.4s) → bin\Debug\net7.0\dymaptic.GeoBlazor.Core.dll
  dymaptic.GeoBlazor.Core net6.0 succeeded (13.4s) → bin\Debug\net6.0\dymaptic.GeoBlazor.Core.dll

Build succeeded in 17.0s

There's more work that is happening on the performance side of things to further optimize large asset collections. In the meantime, there are a couple of things you can do:

• Exclude from the build any asset that you don't need to ship.
• Disable static web assets during development/inner loop.
  • This will limit your ability to use MapStaticAssets in an app, but if you are producing a library, it should be fine. You can still rely on app.UseStaticFiles during development.

[TimPurdum]

@javiercn appreciate the prompt response! I was thinking I couldn't use Disable Static Assets as that sounds pretty drastic! 😅 But I will give it a go.

Cutting down our dependencies is a long term goal, but difficult to do for a library where you don't know what features the end user will use.

[TimPurdum]

@javiercn finally had a chance to test again.

• Setting <StaticWebAssetsEnabled>false</StaticWebAssetsEnabled> appears to completely break even app.UseStaticFiles, unless I'm missing something. When I set that, I can't server my entry JS file.
• Setting <CompressionEnabled>false</CompressionEnabled> doesn't seem to have much impact on the speed of the build process.

[TimPurdum]

Any news on when a speed fix will be released for .NET 9?

[tbolon]

FYI Umbraco CMS builds are significantly impacted by this problem. Quite easy to reproduce: create a blank site which references Umbraco v15.

[TimPurdum]

@javiercn any updates on this? Would the .NET 10 previews have the fix you mentioned?

[TimPurdum]

@javiercn Looking for any updates to this. We have been managing with <CompressionEnabled>false</CompressionEnabled> for development mode, and dealing with the long compiles for release mode. However, this week I tried to update our samples site https://samples.geoblazor.com to .NET 9 and the GitHub action we use to deploy to Azure will run 30 min+ on dotnet publish and then exit with no message or "task was cancelled" (with no user interaction). This seems to happen regardless of the CompressionEnabled setting, and as I've seen on other related gissues, it definitely appears that there is still compression going on when I set this value to false, based on the logs I can see.

Things I've tried so far:

• Setting CompressionEnabled to false in all projects
• Removing that setting, letting everything compress as default
• Setting /p:CompressionEnabled=false in the build and publish commands directly
• Combining build and publish steps (I saw another gissue mentioning --no-build as a potential issue)
• The failing pipeline is in our private GeoBlazor Pro repository, so I tried to reproduce it in our GeoBlazor Core open-source repo. Here is the run. Unfortunately for my purposes, the run succeeded in Core, but not in Pro. The only difference that I could see between the two setups is the depth of dependencies. Pro does not really vary from Core in structure, and the vast majority of the static assets are the same in both.
  • dymaptic.GeoBlazor.Pro.Sample.WebApp -> dymaptic.GeoBlazor.Pro.Sample.Shared -> dymaptic.GeoBlazor.Pro
  • dymaptic.GeoBlazor.Pro.Sample.WebApp -> dymaptic.GeoBlazor.Pro.Sample.Shared -> dymaptic.GeoBlazor.Core.Sample.Shared -> dymaptic.GeoBlazor.Core

I know adding /bl is a typical next step, but I'm wondering if this is worth it, as I get no logs saved from the failed step in GH actions. If there are any other settings or suggestions I'm missing, I would be very grateful for the guidance. When I do run the compressed version of the site locally, the results are impressive, and I'm very excited to be able to use that eventually!

[TimPurdum]

Update, I can now get .NET 9 GeoBlazor Pro samples to deploy using /p:CompressionEnabled=false in the command line. Still fails with no error messages on publish without that setting.

[TimPurdum]

Even though I can't share the whole repository, here is the relevant github action jobs, up to the failing step.

jobs:
  build: 
    runs-on: ubuntu-latest
    timeout-minutes: 90
    steps:
      # Checkout the repository to the GitHub Actions runner
    - name: Checkout
      uses: actions/checkout@v4
      with:
        submodules: true
        
    - name: Setup .NET
      uses: actions/setup-dotnet@v4
      with:
        dotnet-version: 9.x
        
      # Add appsettings.json to the client app
    - name: Add appsettings.json
      shell: pwsh
      run: |
        $appSettings = "{`n  `"ArcGISApiKey`": `"${{ secrets.ARCGISAPIKEY }}`",`n  `"GeoBlazor`": {`n    `"LicenseKey`": `"${{ secrets.SAMPLES_GEOBLAZOR_LICENSE_KEY }}`"`n  },`n  `"DocsUrl`": `"https://docs.geoblazor.com`"`n}"
        $appSettings | Out-File -FilePath ./samples/dymaptic.GeoBlazor.Pro.Sample.WebApp.Client/wwwroot/appsettings.json -Encoding utf8
        $appSettings | Out-File -FilePath ./samples/dymaptic.GeoBlazor.Pro.Sample.WebApp.Client/wwwroot/appsettings.Production.json -Encoding utf8
  
      # Loads all NuGet dependencies
    - name: Restore dependencies
      run: dotnet restore ./src/dymaptic.GeoBlazor.Pro/dymaptic.GeoBlazor.Pro.csproj
    
    - name: Update NPM
      uses: actions/setup-node@v4
      with:
        node-version: '>=22.11.0'
        check-latest: 'true'
    
      # This step will install the NPM dependencies and build the JS files with ESBuild
      # The assetCopy.ps1 script will copy the ArcGIS Asset files to the correct location
    - name: Copy Assets and Generate JS
      shell: pwsh
      run: |
        cd ./GeoBlazor/src/dymaptic.GeoBlazor.Core
        npm install
        npm run releaseBuild
        ./assetCopy.ps1
        cd ../../..
      
      # Copies the TypeScript files from the Core project to the Pro project
      # and then runs the ESBuild compilation step
    - name: Copy TypeScript from Core to Pro
      shell: pwsh
      run: |
        cd ./src/dymaptic.GeoBlazor.Pro
        npm install
        ./coreTypeScriptCopy.ps1 -build -release
        cd ../..
    
      # Builds the Samples project
    - name: Restore Samples
      run: dotnet restore ./samples/dymaptic.GeoBlazor.Pro.Sample.WebApp/dymaptic.GeoBlazor.Pro.Sample.WebApp.csproj 
    - name: Build Samples
      run: dotnet build ./samples/dymaptic.GeoBlazor.Pro.Sample.WebApp/dymaptic.GeoBlazor.Pro.Sample.WebApp.csproj -c Release --no-restore /p:OptOutFromProEsBuild=true /p:OptOutFromCoreEsBuild=true /p:GeneratePackage=false
    - name: Publish Samples
      run: dotnet publish ./samples/dymaptic.GeoBlazor.Pro.Sample.WebApp/dymaptic.GeoBlazor.Pro.Sample.WebApp.csproj -c Release --no-restore --no-build /p:OptOutFromProEsBuild=true /p:OptOutFromCoreEsBuild=true /p:GeneratePackage=false --output samples/dymaptic.GeoBlazor.Pro.Sample.WebApp/published