dotnet
MSB3552: Resource file "**/*.resx" cannot be found when there is a long path
Describe the bug
Using dotnet run with the --no-cache argument produces the following error:
/usr/local/share/dotnet/sdk/10.0.100-rc.1.25451.107/Microsoft.Common.CurrentVersion.targets(3442,5): error MSB3552: Resource file "**/*.resx" cannot be found.
dotnet run runs fine without this argument.
matt@Mac ~ % dotnet run test.cs
Hello!
matt@Mac ~ % dotnet run test.cs --no-cache
/usr/local/share/dotnet/sdk/10.0.100-rc.1.25451.107/Microsoft.Common.CurrentVersion.targets(3442,5): error MSB3552: Resource file "**/*.resx" cannot be found.
The build failed. Fix the build errors and run again.
matt@Mac ~ % ./test.cs
Hello!
matt@Mac ~ % ./test.cs --no-cache
/usr/local/share/dotnet/sdk/10.0.100-rc.1.25451.107/Microsoft.Common.CurrentVersion.targets(3442,5): error MSB3552: Resource file "**/*.resx" cannot be found.
The build failed. Fix the build errors and run again.
To Reproduce
#!/usr/local/share/dotnet/dotnet run
Console.WriteLine("Hello!");
foreach (var arg in args) {
Console.WriteLine(arg);
}
Exceptions (if any)
/usr/local/share/dotnet/sdk/10.0.100-rc.1.25451.107/Microsoft.Common.CurrentVersion.targets(3442,5): error MSB3552: Resource file "**/*.resx" cannot be found.
Further technical details
details of dotnet --info
.NET SDK: Version: 10.0.100-rc.1.25451.107 Commit: 2db1f5ee2b Workload version: 10.0.100-rc.1.25458.2 MSBuild version: 17.15.0-preview-25451-107+2db1f5ee2
Runtime Environment: OS Name: Mac OS X OS Version: 26.0 OS Platform: Darwin RID: osx-arm64 Base Path: /usr/local/share/dotnet/sdk/10.0.100-rc.1.25451.107/
.NET workloads installed: There are no installed workloads to display. Configured to use workload sets when installing new manifests.
Host: Version: 10.0.0-rc.2.25468.101 Architecture: arm64 Commit: 664567ff4c
.NET SDKs installed: 7.0.410 [/usr/local/share/dotnet/sdk] 8.0.303 [/usr/local/share/dotnet/sdk] 8.0.406 [/usr/local/share/dotnet/sdk] 9.0.100-preview.7.24407.12 [/usr/local/share/dotnet/sdk] 9.0.200 [/usr/local/share/dotnet/sdk] 10.0.100-rc.1.25451.107 [/usr/local/share/dotnet/sdk]
.NET runtimes installed: Microsoft.AspNetCore.App 7.0.20 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 8.0.7 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 8.0.13 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 9.0.0-preview.7.24406.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 9.0.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 10.0.0-rc.1.25451.107 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 10.0.0-rc.2.25468.101 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 7.0.20 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 8.0.7 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 8.0.13 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 9.0.0-preview.7.24405.7 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 9.0.2 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 10.0.0-rc.1.25451.107 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 10.0.0-rc.2.25468.101 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Other architectures found: x64 [/usr/local/share/dotnet/x64] registered at [/etc/dotnet/install_location_x64]
Environment variables: Not set
global.json file: Not found
Learn more: https://aka.ms/dotnet/info
Download .NET: https://aka.ms/dotnet/download
Did not use an IDE, just wrote the program in nano.
@msuddaby is this happening only for file-based apps (dotnet run file.cs) or project-based apps as well? It seems like an MSBuild issue, probably https://github.com/dotnet/msbuild/issues/3864 - do you have some backslashes somewhere in your file paths?
Just saw this error in the binlog, I guess that's the cause:
An exception occurred while expanding a fileSpec with globs: fileSpec: "**/*.resx", assuming it is a file name. Exception: System.AggregateException: One or more errors occurred. (The path '/Users/matt/Library/Developer/CoreSimulator/Devices/228EB2D2-048F-434D-921D-5B683D3B1A8E/data/Library/Trial/NamespaceDescriptors/v2/factorPackSets/bebdf57d-84ac-4250-b960-008c3fadfb22/factorPacks/WALLET_APP_ECOM_PAYMENT_SHEET/_refs/revlinks/link-3B6D91CB-A64D-4DCF-B309-DF423976D8EC/_refs/revlinks/link-3B6D91CB-A64D-4DCF-B309-DF423976D8EC/_refs/revlinks/link-3B6D91CB-A64D-4DCF-B309-DF423976D8EC/_refs/revlinks/link-3B6D91CB-A64D-4DCF-B309-DF423976D8EC/_refs/revlinks/link-3B6D91CB-A64D-4DCF-B309-DF423976D8EC/_refs/revlinks/link-3B6D91CB-A64D-4DCF-B309-DF423976D8EC/_refs/revlinks/link-3B6D91CB-A64D-4DCF-B309-DF423976D8EC/_refs/revlinks/link-3B6D91CB-A64D-4DCF-B309-DF423976D8EC/_refs/revlinks/link-3B6D91CB-A64D-4DCF-B309-DF423976D8EC/_refs/revlinks/link-3B6D91CB-A64D-4DCF-B309-DF423976D8EC/_refs/revlinks/link-3B6D91CB-A64D-4DCF-B309-DF423976D8EC/_refs/revlinks/link-3B6D91CB-A64D-4DCF-B309-DF423976D8EC/_refs/revlinks/link-3B6D91CB-A64D-4DCF-B309-DF423976D8EC/_refs/revlinks/link-3B6D91CB-A64D-4DCF-B309-DF423976D8EC/_refs' is too long, or a component of the specified path is too long.)
(it appears only as a message, so I overlooked it previously)
@msuddaby is this happening only for file-based apps (
dotnet run file.cs) or project-based apps as well? It seems like an MSBuild issue, probably dotnet/msbuild#3864 - do you have some backslashes somewhere in your file paths?
Only file-based apps. I am able to build and run full projects from the command line just fine using dotnet run.
I am able to build and run full projects from the command line just fine using dotnet run.
You might be having those projects in a different directory, hence not hitting that "long path" issue I described above (since file with the long path is not in that directory)?
I am able to build and run full projects from the command line just fine using dotnet run.
You might be having those projects in a different directory, hence not hitting that "long path" issue I described above (since file with the long path is not in that directory)?
Interesting! I was running the script originally from the top of my user directory /Users/matt/test.cs. Moving the script to a different folder /Users/matt/Scripts/test.cs works!
matt@Matts-MacBook-Pro Scripts % ./test.cs --no-cache -- blah
Hello!
blah
@jjonescz I'm concerned this is actually going to show up quite a bit with file-based apps as folks try to put them in locations above NPM apps, etc., that have really deep paths. We might need to think about if there's anything we can do to reduce the changes ppl hit this with file-based apps, or somehow improve the failure experience with a different message, suggesting enabling long paths in Windows, etc.
@maddymontaquila hit this today on our live stream after changing her folder name to be just 7 characters longer 🫨
Wouldn't it help if MSBuild at least reported this as a normal error and not hidden away deep inside a binlog (with non-error severity)? (If there is fear of breaking users for some reason, this could be opt-in that file-based apps would enable by default.)
Even better (again perhaps as opt-in) - could MSBuild ignore files with long paths while collecting globs and instead just display a warning to inform the user that some files were ignored and/or that they should enable long path support in Windows?
@YuliiaKovalova @dotnet/msbuild I'm curious why was this closed as "not planned"? Thanks.
@maddymontaquila hit this today on our live stream after changing her folder name to be just 7 characters longer 🫨
I'd like to hear more about this please--I'm surprised that a "normal" long path would hit it. We shouldn't really have long-path limitations in dotnet these days. The OP's case looks like a circular symlink (so an infinite path) rather than "just" a long path.
edit: though I'm curious why dotnet/msbuild#7685 didn't work in the OP's case
Wouldn't it help if MSBuild at least reported this as a normal error and not hidden away deep inside a binlog (with non-error severity)?
We have a design problem: items are usually paths but not always, and the way to express a "not path" item that has a special character in it is indistinguishable from "include a glob that fails to expand". The code is basically
if there are glob special characters:
try:
items = expand glob
catch:
items = [original_string]
And I'm pretty sure there are indeed dependencies on this in the wild :(
I'd like to hear more about this please--I'm surprised that a "normal" long path would hit it.
Yeah, curious about this too; if normal long paths shouldn't hit this, seems like much less severe issue.
The code is basically
That's what I thought, but can we tell the glob expander to ignore the "path is too long" exception and expand only the rest of the glob? (For file-based apps as opt in at least.)
can we tell the glob expander to ignore the "path is too long" exception and expand only the rest of the glob? (For file-based apps as opt in at least.)
I'm not sure I understand what you mean by this. That is what we're doing--we report the exception but don't fail and fall back to "guess it's a literal string".
I meant ignore only the file path that is too long; but still collect the rest of the paths.
Ah got it. We could probably add a mode for that but I would be a bit concerned about the implications.
Are file-based apps globbing for .resx? That . . . seems counterintuitive to me.
Are file-based apps globbing for .resx? That . . . seems counterintuitive to me.
We are trying to keep file-based apps consistent with project-based apps in most scenarios so dotnet project convert works; and also for example file-based apps which are web servers are expected to find .json files as Content items, or .razor pages, etc.
Although I guess we could make file-based apps globbing more conservative or opt in entirely. Would help with this issue, but also help with perf of https://github.com/dotnet/sdk/issues/50912 (where we wouldn't need to glob by default for our caching mechanism to work correctly), and I guess with perf in general (no globbing by default).
This is where the issue started: https://www.youtube.com/live/rrurHUfzyTY?si=8ak91AXLGGSGDNOL&t=25112 What wasn't clear at this point is that off-screen Maddy had changed the containing directory name since the last time she ran the app (earlier in the same stream). We then spend a while going round and round trying to figure out what's going on during which someone finds this issue which leads us to determine it's likely a max path issue.
I am able to build and run full projects from the command line just fine using dotnet run.
You might be having those projects in a different directory, hence not hitting that "long path" issue I described above (since file with the long path is not in that directory)?
Interesting! I was running the script originally from the top of my user directory
/Users/matt/test.cs. Moving the script to a different folder/Users/matt/Scripts/test.csworks!matt@Matts-MacBook-Pro Scripts % ./test.cs --no-cache -- blah Hello! blah
@msuddaby I also had the same issue and moving it out of my home directory fixed it as well.
@jjonescz I know macOS is very guarded about giving programs access to the base home directory. Could this be affecting the CLI and file-based programs?
I ran into a similar issue today. I have a C# project with .csproj file and one directory in that project contained a special character that made it impossible for dotnet to open that dir (I could only delete it by renaming with Total Commander and then remove).
I got the error: C:\Program Files\dotnet\sdk\10.0.101\Microsoft.Common.CurrentVersion.targets(3442,5): error MSB3552: Resource file "**/*.resx" cannot be found.
I think in general the way should be ignoring directories that cannot be entered for whatever reason in this search.
