Error CS2007: Unrecognized option: /analyzerconfig - visual-studio

I have a Unity project which I use Roslyn for Code Analysis and I found that you can get the warnings and errors report from console using msbuild.
In the PC I have VS 2019 version 16.6.3, it gave the following error that I will comment below and updated to version 16.11.9, thinking it was the incompatibility and still gets the error. I tried running the command described below on other PCs with other versions of VS and it works fine, but I have not been able to identify what makes the command work well.
Command:
By running the following line in Developer Command Prompt for VS 2019:
msbuild ScriptsAssembly.csproj /p:RunCodeAnalysis=true /t:Clean;Rebuild
I expect to see the total number of warnings for the project and zero errors with successful execution like this:
Instead I get the following error:
CSC : error CS2007: Unrecognized option: '/analyzerconfig:C:\Users\...\Documents\...\...\UnityProject\.editorconfig' [C:\Users\...\Documents\...\...\UnityProject\SimpleJSON
.csproj]
Done Building Project "C:\Users\...\Documents\...\...\UnityProject\SimpleJSON.csproj"
(default targets) -- FAILED.
Done Building Project "C:\Users\...\Documents\...\...\UnityProject\ScriptsAssembly.csp
roj" (Clean;Rebuild target(s)) -- FAILED.
Build FAILED.
...
"C:\Users\...\...\...\...\UnityProject\Project.csproj" (Clean;Rebuild target) (1) ->
"C:\Users\...\...\...\...\UnityProject\SimpleJSON.csproj" (default target) (2:3)
->
(CoreCompile target) ->
CSC : error CS2007: Unrecognized option: '/analyzerconfig:C:\Users\...\Documents\...\...\UnityProject\.editorconfig' [C:\Users\...\Documents\...\...\UnityProject\SimpleJS
ON.csproj]
1 Warning(s)
1 Error(s)
Time Elapsed 00:00:00.91
What I expect to see is a thousand warnings, instead of 1.
I don't know if I am missing a package to install in VS. I have seen the error that the compiler message mentions in the Microsoft documentation, but it doesn't help me much.
Any idea, or help is welcome.

Related

Access denied when building esp-idf-sys for Rust project for ESP32 on Windows 10

I'm attempting to set up this Rust template project to get started doing Rust development for ESP32: https://github.com/esp-rs/esp-idf-template
I've installed the Rustup esp toolchain, as described here: https://github.com/esp-rs/rust-build
At the Generate the Project step, I chose these parameters:
Configure project to use Dev Containers = false
ESP-IDF native build version = v4.4
Rust toolchain = esp
STD Support = true
MCU = esp32
At the Build step, I get this output (second run displayed, first run compiles a long list of dependencies before this point):
C:\Users\Me\boop\doop>cargo build
Compiling esp-idf-sys v0.31.6
error: failed to run custom build command for `esp-idf-sys v0.31.6`
Caused by:
process didn't exit successfully: `C:\Users\Me\boop\doop\target\debug\build\esp-idf-sys-cafd80a349bfdbb2\build-script-build` (exit code: 1)
--- stdout
cargo:rerun-if-env-changed=IDF_PATH
cargo:rerun-if-env-changed=ESP_IDF_TOOLS_INSTALL_DIR
cargo:rerun-if-env-changed=ESP_IDF_VERSION
cargo:rerun-if-env-changed=ESP_IDF_REPOSITORY
cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG_DEFAULTS
cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG
cargo:rerun-if-env-changed=MCU
IDF_PYTHON_ENV_PATH=C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env
PATH=C:\Users\Me\boop\doop\.embuild\espressif\tools\esp32ulp-elf\2.28.51-esp-20191205\esp32ulp-elf-binutils\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\cmake\3.23.1\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\ninja\1.10.2\;C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env\Scripts;C:\Users\Me\boop\doop\.embuild\espressif\esp-idf\release-v4.4\tools;%PATH%
Current system platform: win64
Skipping xtensa-esp32-elf#esp-2021r2-patch3-8.4.0 (already installed)
Skipping cmake#3.23.1 (already installed)
Skipping ninja#1.10.2 (already installed)
Skipping esp32ulp-elf#2.28.51-esp-20191205 (already installed)
IDF_PYTHON_ENV_PATH=C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env
PATH=C:\Users\Me\boop\doop\.embuild\espressif\tools\esp32ulp-elf\2.28.51-esp-20191205\esp32ulp-elf-binutils\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\cmake\3.23.1\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\ninja\1.10.2\;C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env\Scripts;C:\Users\Me\boop\doop\.embuild\espressif\esp-idf\release-v4.4\tools;%PATH%
--- stderr
Using managed esp-idf repository: EspIdfRemote { repo_url: None, git_ref: Branch("release/v4.4") }
fatal: No names found, cannot describe anything.
Using esp-idf v4.4.1 at 'C:\Users\Me\boop\doop\.embuild\espressif\esp-idf\release-v4.4'
fatal: No names found, cannot describe anything.
Error: Access is denied. (os error 5)
I get the same error when I choose ESP-IDF native build version = v4.3.2, although without the fatal: No names found, cannot describe anything. messages.
I get an identical error when attempting to build this Rust ESP32 demo project: https://github.com/ivmarkov/rust-esp32-std-demo
This was run as Administrator.
In my search for a solution, I found this: Why os.rename sometimes returns error access is denied python Per the top answer, I disabled "Show frequently used folders in Quick access" in File explorer, but unfortunately the build error has not changed.
What access is being denied, and what could be causing the denial, even when run as Administrator?
Secondarily, what is the cause and meaning of the fatal: No names found, cannot describe anything. messages?
I've been working through the same issue today.
It is caused by a change in the embuild dependency: https://github.com/esp-rs/embuild/commit/d8f8da228f1e1e6c105074d96617a8601092f633
Trying to write permission data to an open file causes the 'os error 5
I've submitted a PR to the project: https://github.com/esp-rs/embuild/pull/56
Now merged, cargo update and you should be good!

"The process cannot access the file 'Default.rd.xml' because it is being used by another process." on AppVeyor CI

I am doing some work on cordova-windows (https://github.com/apache/cordova-windows), which is using AppVeyor for testing on Windows. One of the things that was missing, were tests with Visual Studio 2017 (only VS2015 was used to test before). So I added those and it works like a charm - mostly.
Unfortunately we now have a very strange test failure:
https://ci.appveyor.com/project/ApacheSoftwareFoundation/cordova-windows/build/1.0.458
Started
Creating Cordova Windows Project:
Path: testcreate 応用
Namespace: com.test.app
Name: 応用
Windows project created with cordova-windows#5.1.0-dev
Building project: C:\projects\cordova-windows\testcreate 応用\CordovaApp.Windows10.jsproj
Configuration : release
Platform : x64
Patching 10 in prebuild event...
Injected base.js reference to the www/index.html
Removing /( *)(<script\s+(?:type="text\/javascript"\s+)?src="\/\/Microsoft.WinJS.2.0\/js\/base.js">\s*<\/script>)(\s*)/ from www/index.html
Removing /( *)(<script\s+(?:type="text\/javascript"\s+)?src="\/\/Microsoft.Phone.WinJS.2.1\/js\/base.js">\s*<\/script>)(\s*)/ from www/index.html
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\build\windows\release\x64\win10\CordovaApp.Windows10_1.0.0.0_x64.appx
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\build\windows\release\x64\win10\Upload\CordovaApp.Windows10_1.0.0.0_x64.appx
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0_Test\CordovaApp.Windows10_1.0.0.0_x64.appxbundle
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0\CordovaApp.Windows10_1.0.0.0_x64.appxbundle
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0_x64_bundle.appxupload
Your package has been successfully created.
Building project: C:\projects\cordova-windows\testcreate 応用\CordovaApp.Windows10.jsproj
Configuration : release
Platform : x86
Patching 10 in prebuild event...
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets(2975,5): error MSB3231: Unable to remove directory "build\windows\bld\PackageUploadLayout\". The process cannot access the file 'Default.rd.xml' because it is being used by another process. [C:\projects\cordova-windows\testcreate ??\CordovaApp.Windows10.jsproj]
C:\projects\cordova-windows\testcreate 応用\cordova\node_modules\q\q.js:155
throw e;
^
Error: C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe: Command failed with exit code 1
at ChildProcess.whenDone (C:\projects\cordova-windows\testcreate 応用\cordova\node_modules\cordova-common\src\superspawn.js:169:23)
at emitTwo (events.js:106:13)
at ChildProcess.emit (events.js:191:7)
at maybeClose (internal/child_process.js:920:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:230:5)
The relevant part is this:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets(2975,5): error MSB3231: Unable to remove directory "build\windows\bld\PackageUploadLayout\". The process cannot access the file 'Default.rd.xml' because it is being used by another process. [C:\projects\cordova-windows\testcreate ??\CordovaApp.Windows10.jsproj]
This is not happening when I run the tests locally, meaning I can in no way reproduce what is going on here.
Any idea what process could block this Default.rd.xml file or build\windows\bld\PackageUploadLayout\?
How can I find out in a CI environment like AppVeyor?
Update:
Investigated a bit more by adding /clp:Verbosity=normal to the msbuild calls that are executed.
It runs a similar msbuild call 3 times (once per architecture). The first one succeeds, but during the second one the failure occurs. Makes sense as in the first iteration the folder doesn't exist yet, which it confirms with this output: Directory "build\windows\bld\PackageUploadLayout\" doesn't exist. Skipping..
The last output before the failure then is Removing directory "build\windows\bld\PackageUploadLayout\". which matches what we get in the error message. No indicator why the removing doesn't work though.
Super strange: With /clp:Verbosity=detailed added to the msbuild call, the build actually succeeds! My guess: Because the output takes time, whatever is having a lock on the folder or file releases it.
This is not exactly an answer, but rather investigation report. It is just not enough room comments to describe it. Here is what I did:
forked your repo
created AppVeyor project
added RDP
connected with RDP
installed procmon
added filter to monitor objects which path ends with bld\PackageUploadLayout\Properties\Default.rd.xml
run npm test manually from CMD
When the same error happened I see this:
I am not sure I understand why msbuild failed this way. I opened SHARING VIOLATION event, switched to process and see this:
What catches my eye is that msbuild version is 14. Should be 15 on Visual Studio 2017 image. We have version 14 installed for specific scenarios but default one is 15 (run where msbuild and you will see C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe). I am not sure where this path is set in your scripts, but I feel if you make it run correct msbuild version this may help.

I recently create a project of OPNET 14.5 and i have been unable to run the simulation. the error is about Pipeline stage model (dpt_ecc_pon)

I installed OPNET modeler 14.5 at my laptop (OS: Windows 8).
I slightly modified a process model, and ran simulation. But I see the following errors.
<<< Recoverable Error >>>
Pipeline stage model (dpt_ecc_pon) compilation failed
Source code was unavailable to the compiler
----
<<< Recoverable Error >>>
Object repository construction failed
Pipeline stage (dpt_ecc_pon) compilation failed, no source code found.
T (0), EV (-), MOD (NONE)
----
<<< Program Abort >>>
Error encountered rebuilding repository -- unable to proceed
T (0), EV (-), MOD (NONE)
How can i overcome this?
If you create dpt_ecc_pon pipeline stage source, there are some rules to define them. Based on your error message, the dpt_ecc_pon.ps.c/cpp is not included in the model_dirs.
All source code should be included in model_dirs. Press Ctrl+Alt+P. In preference dialog, search 'model_dirs' and make sure the directory where your codes are included in the 'model_dirs'.

Good MSbuild log formatter?

we are building a very large Visual C++ 2010 solution (about 150 projects, full build takes about an hour) on a build server (Jenkins) with MSBuild. Unfortunately when a project fails, it is difficiult to find out which and why, because the console log is so long and errors are hard to find.
Is there a nice msbuild log parser or msbuild logger that nicely lists all failed projects and the error messages? The best we've found so far is the Warnings Plugin but this is pretty much useless in many cases.
I find the Log Parser Plugin very useful, though you need to provide your own parser file (in /jobs/vs_parsing_rules). I use the following, which works well for msbuild
error /[Ee]rror *:/
error /Error on line/
error /error [CM]/
error /fatal error/
error /unresolved external/
error /[aA]ccess is denied/
error /aborted/
warning /[Ww]arning *:/
warning /[Ww]arning C/
warning /WARNING/
warning /Couldn't/
warning /Can't/
warning /Cannot/
warning /ld.*unsupported/
error /[uU]ndefined symbols/
warning /[rR]eferenced from/
warning /[nN]ot found/
warning /exit status/
warning /no symbols/
error /ERROR[^A-Za-z]/
info /INFO/
start /BUILD/
Another useful parsing rules that works for msbuild:
# Divide into sections based on project compile start
start /^------/
# Compiler Error
error /(?i)error [A-Z]+[0-9]+:/
error /MSBUILD : (?i)error :/
error /\(\d+(,\d+)?\): (?i)error [A-Za-z]*:/
# Compiler Warning
warning /(?i)warning [A-Z]+[0-9]+:/

LNK1000: Internal error during IMAGE::BuildImage

I have a problem with linking in VC++ 2010. When I compile in the debug mode it's ok, but in the release mode I regular receive the error "LNK1000: Internal error during IMAGE::BuildImage".
What am I doing wrong?
It began work as soon as I have changed "Whole program optimization" option from "Use Link Time Code Generation" to "Profile Guided Optimization-Instrument".
I encountered the same error. The problem in my case was that I was "playing" with the configuration properties (Project Properties -> Configuration Properties -> General)
The 'Configuration Type' of the project was 'Dynamic Library (.dll)', but the 'Target Extension' was .lib instead of .dll.
April 2020 update
Issue with MSBuild and Docker for Windows was fixed in MSBuild 16.5 (source), so if still seeing that - just update MSVS/MSBuild to the latest version
Original answer
Check for working C compiler: C:/BuildTools/VC/Tools/MSVC/14.24.28314/bin/Hostx64/x64/cl.exe -- broken
CMake Error at C:/Program Files/CMake/share/cmake-3.16/Modules/CMakeTestCCompiler.cmake:60 (message):
The C compiler
"C:/BuildTools/VC/Tools/MSVC/14.24.28314/bin/Hostx64/x64/cl.exe"
is not able to compile a simple test program.
......
LINK : fatal error LNK1000: Internal error during IMAGE::BuildImage.FinalPhase
I was getting this error when I was running cmake in Docker for Windows inside mounted Docker volume. Solution is to copy the workspace to local Docker filesystem.
In vs2019 it works for me:
Project->Property pages->Optimization->Link Time Code Generation, change from "Use Link Time Code Generation" to "Profile Guided Optimization-Instrument"

Resources