Building a `Microsoft.VisualStudio.JavaScript.SDK` on OS X results in a folder named `obj\Release`

[miguellira]

Describe the bug

When building an .esproj project on OS X the generated artifacts includes two package.g.props files. One in the obj folder and another in a similar folder that includes a backslash obj\Release:

As a result, the following .gitignore entry which excludes the folder by escaping the backslash is required:

# Weird esproj bug
obj\\Release

otherwise during a clean build of an Angular SPA template a TypeScript error similar to the one documented here is thrown.

Note: In addition, (but completely unrelated to the bug) it would be nice if the JavaScript SDK supported the new Artifacts output layout introduced in .NET 8.

To Reproduce

1. Create a folder named esproj-bug.
2. Create a .esproj file inside the folder with the following content:

<Project Sdk="Microsoft.VisualStudio.JavaScript.Sdk/1.0.2348200">
    <PropertyGroup>
        <StartupCommand>npm start</StartupCommand>
        <JavaScriptTestFramework>Jasmine</JavaScriptTestFramework>
        <ShouldRunBuildScript>false</ShouldRunBuildScript>
        <BuildOutputFolder>$(MSBuildProjectDirectory)\dist\esproj-bug\browser</BuildOutputFolder>
    </PropertyGroup>
</Project>

3. Run npm init and generate a package.json
4. Run dotnet build

Exceptions (if any)

No exception is thrown during build, however, when building an Angular v19 solution a TypeScript error is thrown if that obj\Release folder exists.

Further technical details

dotnet --info

.NET SDK:
 Version:           9.0.100
 Commit:            59db016f11
 Workload version:  9.0.100-manifests.3068a692
 MSBuild version:   17.12.7+5b8665660

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  15.3
 OS Platform: Darwin
 RID:         osx-arm64
 Base Path:   /usr/local/share/dotnet/sdk/9.0.100/

.NET workloads installed:
There are no installed workloads to display.
Configured to use loose manifests when installing new manifests.

Host:
  Version:      9.0.0
  Architecture: arm64
  Commit:       9d5a6a9aa4

.NET SDKs installed:
  9.0.100 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 9.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 9.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

Visual Studio Code

Version: 1.96.4 (Universal)
Commit: cd4ee3b1c348a13bafd8f9ad8060705f6d4b9cba
Date: 2025-01-16T00:16:19.038Z (2 wks ago)
Electron: 32.2.6
ElectronBuildId: 10629634
Chromium: 128.0.6613.186
Node.js: 20.18.1
V8: 12.8.374.38-electron.0
OS: Darwin arm64 24.3.0

[alexmg]

I am seeing the same issue described in angular/angular-cli#28936 when building on a Ubuntu (24.04.1) GitHub-hosted runner.

The error is also referring to the obj/Debug folder as described in the other issue. I thought this was strange because I was running a Release build.

It turns out that when dotnet restore is run on the solution the obj/Debug folder is being created. Then when running dotnet build --configuration Release the error occurs.

There is no --configuration argument for the dotnet restore command but you can still pass project properties. I tried passing -p:Configuration=Release to the restore and instead of the obj/Debug folder being created during the restore an obj/Release folder is created instead. Without the obj/Debug folder present during the Release build I don't get the error.

The existence of the obj/Debug folder is not causing any problem when building on Windows directly or Ubuntu inside WSL with the solution files on the mounted Windows drive.

This sounds similar to your issue @miguellira but with the opposite build configuration. You are running dotnet build without the --configuration Release argument so it is a Debug build and seems to fail because the obj/Release folder is present.

[miguellira]

@alexmg like you and @marklagendijk I also encountered the issue deploying on a GitHub Ubuntu runner.

My typical GitHub workflow follows this pattern:

dotnet restore

dotnet build --no-restore

dotnet publish --no-restore --configuration Release

and by leveraging the Artifacts output layout feature introduced in .NET 8 I have a consistent folder to zip and deploy.

My workaround works for me. Have you tried adding all configuration paths to your .gitignore file?

# Weird esproj bug
obj\\Debug
obj\\Release

[alexmg]

I copied the solution to a path on my Ubuntu distro in WSL instead of referencing the Windows drive on the /mnt/c mount. Building there I can see the same weird obj\\Debug/ and obj\\Release/ folders as you.

It seems that as long as the weird folder name aligns with the build configuration used when calling dotnet build it works fine.

Your configuration for dotnet build is using the default of Debug which aligns with the obj\\Debug/ folder created when dotnet restore is run. The dotnet publish won't be performing any work for the .esproj project even with the --configuration Release argument because it doesn't consider a different configuration a change.

Running the same commands you provided, but with the -v detailed argument on the dotnet publish command, I can see the publish step is basically a no-op. There is no restore or build being performed for the .esproj and no Angular related activity.

$ dotnet publish Foo.esproj  --configuration Release -v detailed
Restore complete (0.2s)
    Determining projects to restore...
    Nothing to do. None of the projects specified contain packages to restore.

Build succeeded in 0.4s

I believe it's the configuration being the same for the dotnet build and dotnet restore steps that is making it work for you. If you try dotnet restore and then dotnet build --configuration Release it should fail for you as well.

I don't have those paths in my .gitignore because development is done on Windows machines where they don't get created and are never committed. In my testing Angular is not taking anything in the .gitignore into consideration during the build.