sdk: "error MSB3552: Resource file "**/*.resx" cannot be found" only in particular environments
I have a build that works on my computer but is failing in a continuous integration environment (AppVeyor) with this error:
Microsoft.Common.CurrentVersion.targets(2867,5): error MSB3552: Resource file “**/*.resx” cannot be found.
On my computer, the build output contains:
React.Core.csproj" (target "ResGen" depends on it):
Task "GenerateResource" skipped, due to false condition; ('%(EmbeddedResource.Type)' == 'Resx' and '%(EmbeddedResource.GenerateResource)' != 'false' and '$(GenerateResourceMSBuildRuntime)' != 'CLR2') was evaluated as ('Non-Resx' == 'Resx' and '' != 'false' and 'CLR4' != 'CLR2').
Task "GenerateResource" skipped, due to false condition; ('%(EmbeddedResource.Type)' == 'Resx' and '%(EmbeddedResource.GenerateResource)' != 'false' and '$(GenerateResourceMSBuildRuntime)' == 'CLR2') was evaluated as ('Non-Resx' == 'Resx' and '' != 'false' and 'CLR4' == 'CLR2').
Done building target "CoreResGen" in project "React.Core.csproj".
However, on the build server, it says:
React.Core.csproj" (target "ResGen" depends on it):
Using "GenerateResource" task from assembly "Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
Task "GenerateResource"
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2867,5): error MSB3552: Resource file "**/*.resx" cannot be found. [C:\projects\react-net\src\React.Core\React.Core.csproj]
"C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\resgen.exe" ........
It looks like EmbeddedResource.Type is incorrectly set to Resx rather than Non-Resx, but I have no idea where that comes from 😦
I also noticed a few other messages that appear on the build server that do not appear on my local build:
Culture of "" was assigned to file "**/*.resx".
Done executing task "AssignCulture".
Task "AssignCulture"
Resource file '**/*.resx' doesn't depend on any other file.
Resource file '**/*.resx' gets manifest resource name 'React.Core.__.*'.
Done executing task "CreateCSharpManifestResourceName".
Task "CreateCSharpManifestResourceName"
Creating a separate AppDomain because of error parsing "**/*.resx". Illegal characters in path
Seems like there’s some strange globbing issue going on? I’m not sure.
Steps to reproduce
Clone https://github.com/reactjs/React.NET, checkout b2cd0a4f040da24d1ed2a46d454678fd58c6f8ec, run dev-build.bat
Expected behavior
It works
Actual behavior
Example build: https://ci.appveyor.com/project/Daniel15/react-net/build/217
Environment data
dotnet --info output:
On my computer:
.NET Command Line Tools (1.0.0)
Product Information:
Version: 1.0.0
Commit SHA-1 hash: e53429feb4
Runtime Environment:
OS Name: Windows
OS Version: 10.0.16188
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\1.0.0
On AppVeyor:
.NET Command Line Tools (1.0.3)
Product Information:
Version: 1.0.3
Commit SHA-1 hash: 37224c9917
Runtime Environment:
OS Name: Windows
OS Version: 10.0.14393
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\1.0.3
Edit: Also tested with 1.0.4 on my computer, and it works properly on that version too.
.NET Command Line Tools (1.0.4)
Product Information:
Version: 1.0.4
Commit SHA-1 hash: af1e6684fd
Runtime Environment:
OS Name: Windows
OS Version: 10.0.16188
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\1.0.4
Seems like something specific to the AppVeyor build.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 33 (6 by maintainers)
Commits related to this issue
- Use newer npm on AppVeyor (as a workaround for https://github.com/dotnet/cli/issues/6561 and https://github.com/Microsoft/msbuild/issues/406), and run correct test command — committed to reactjs/React.NET by Daniel15 7 years ago
- Upgrade to Visual Studio 2017 + csproj tooling (#406) * Upgrade to Visual Studio 2017 + csproj tooling * Include workaround for https://github.com/NuGet/Home/issues/4337 (explicitly specify versio... — committed to reactjs/React.NET by Daniel15 7 years ago
Getting similar error when trying to build on Docker microsoft/aspnetcore-build:2.0
/usr/share/dotnet/sdk/2.0.0/Microsoft.Common.CurrentVersion.targets(2924,5): error MSB3552: Resource file "**/*.resx" cannot be found. [/Web.csproj]Try deleting “bin” and “obj” folder and rebuild project again. (I’m using macOS Sierra with VSCode)
Same problem with windows paths.
I noticed the following when
ls -almy src folder:drwxrwxr-x 2 user user 4096 May 16 17:29 c:\temp\data\I deleted with
rm -rf "c:\\temp\\data\\"/, updated my settings, and all is good.Thank you @mrhocuong and @cellvia.
I had
The problem was because I had in my Dockerfile
After I changed to
The problem disappeared.
Getting this in Docker build for Razor Pages app.
Base Image
@richlander @MichaelSimons
Same here on mac os. I suddenly had a
C:\dev\App\AppBytessubdirectory under my project directory holding the .csproj file.I hit this using dotnet 5.0 on Raspberry Pi 4 64-bit Ubuntu. The issue was a folder that had been created by accident called 'd:\Music', i.e. a folder name containing what would have been a drive letter on Windows. Deleting that folder fixed the issue.
dont know if this helps but i saw that msbuild or vscode (or something) was trying to create a hidden keys folder ( “.keys”) but was instead creating “.\keys” every time i run a build, i make sure to delete “.\keys” and things seem ok…
I have a .net core project are run on Windows but when I try to run the project on macOs I got the error message “error MSB3552: Resource file “**/*.resx” cannot be found”.
In my project, I have a config to store the log files in the folder
"WriteTo": [ { "Name": "RollingFileAlternate", "Args": { "logDirectory": ".\\Logs", "fileSizeLimitBytes": 10485760 } } ]At the first time I run the project, this config can run on windows and create a folder have name “Logs” but when I run on macOs it will create a folder have name “.\Logs” and it’s a hidden folder. So this is a problem, after that the project will get that error when building.
The solutions are changing the config to:
"WriteTo": [ { "Name": "RollingFileAlternate", "Args": { "logDirectory": "Logs", "fileSizeLimitBytes": 10485760 } } ]Now the project can run on macOs.Basically, cause windows use the backslash in the directory path, but macOs use the slash so when you need to build the project which coding in Windows on macOs, you should check all the code have related to files, folder, path (ex: the code to create the folder to save log files, create the folder to save upload files…etc).
For the answer of cellvia, I think he got the same problem like me. The .keys folder are created by his code and he can hotfix by the way create a keys folder already before building the project.
Hope it helps.
Getting same problem, but on second build. First time
dotnet buildis successful but second time failes with same error:dotnet --infoI had this issue building dotnet app in an Ubuntu container. I was being lazy and copying the files directly into the file system root. Would work fine for any other language, but dotnet seems to do some kind of recursive search from the build folder and some of the unexpected file types trigger this error. I solved the problem by moving to an app folder.
Same problem for me with MacOs and Rider.
To resolve :
binand obj`folder (if you don’t close rider they are automatically regenerated)I don’t try to rebuild with rider
FWIW I triggered this error when using runsettings for vstest that contained
...\buildfor test results. This created...folder which is recursive on itself and that made the path infinitely long…🔥 Before removing it copy all other content from the directory to a different location.
Removing it from Explorer will cause it to crash, because it attempts to remove recursively. Remove it from PowerShell instead, without the
-Recurseswitch by calling remove on the folder that contains the...folder:Thanks to those above who pointed out the windows path issue - I just got this when I had a merge cause my build machine to start creating some funky directories from Windows path settings. Appears the presence of such a folder is all that is needed to trigger this issue.
I’ll raise this as a new bug, as it seems it’s not resolved. (Update: logged as dotnet/cli#10995)
Reproduction steps below:
Removal of the folder resolves the issue:
More info - versions etc.
Delete the bin folder and anything inside of the wwwroot folder prior to doing to a build or publish This worked for me hope it helps
We also experience this problem with **/*.resx. It did build fine a couple of times, but then this started to occur and cleaning solution first does not work. It’s really annoying!
So I figured this out. This is due to an annoying long-standing MSBuild issue whereby it doesn’t expand wildcards at all if any paths are longer than the old-school max path length in Windows (260 characters)
https://github.com/Microsoft/msbuild/issues/406 https://github.com/Microsoft/msbuild/issues/53 http://stackoverflow.com/a/16738844/210370
This meant that the MSBuild scripts were treating
**/*.resxas a literal file name, and then complaining that the file doesn’t exist!The only “fix” for this is to reduce the length of the paths. In my case, the build server was using a very old version of
npmthat had issues with long paths. At the moment it seems like the MSBuild team are not interested in fixing it.