I am a student who has gotten a part time job embedded system programming. I am given a program the company uses, and asked to understand it. This is a working program. Therefore, the project can be built and flashed on ESP32 by the developers with no problem. So, the code and CMake files should have no issues. However, I cannot build the program either with VSCode extension nor with idf.py. In fact, I cannot build esp-idf examples from the official website, either.
Note: I am new to StackOverflow as well as to ESP32, so sorry if I made any mistakes here. If this post is problematic in any way, please inform me.
The error message from the terminal is shown here
I was initially using VSCode on Windows 10 (Windows is not activated). At first, ESP extension was completely failing to start the building process because it could not locate the tools. I was getting "could not be located" errors for all the tools. Below is a list of what I did in this setting:
I had v5.0.0 for esp-idf downloaded from Espressif server. I deleted it and tried v4.3.3 and then I tried to download from Github server. I downloaded the requirements for idf.py scripting environment and completed the settings for it as described by the Espressif's documentation.
I manually set the environment variables for IDF_PATH and PATH for both the user and for the system.
After 2, the initial error was gone. Unfortunately, I had a new error which indicated that ".elf" file for the project output could not be found. I do not exactly recall the error but if it is integral to the problem's solution I can try to replicate this issue.
I tried to delete and reinstall VSCode. I tried running VSCode with admin authority.
I tried changing the IDF_TOOLS_PATH in the VSCode esp-idf extension configurations from ".espressif" to "esp\esp-idf".
At this point, I moved to try to build the project on Ubuntu 22.04.1 LTS:
In Ubuntu, I got the fatal error: esp_event.h: No such file or directory error.
It does not seem to be a common issue and I could not find much about it online.
I followed the Linux setup steps in the documentation. It said that only step 1 (Downloading the prerequisites) was necessary for the VSCode extension.
I decided to try the "master branch" from esp-idf configurations as well. After I downloaded the master branch, the error changed to the current version: 'fatal error: esp_wifi.h: No such file or directory'
I also tried the idf.py in Ubuntu but I got the same error.
Both in Ubuntu and in Windows, the Doctor Command returns nothing. It does not even open the terminal or any window. I am not sure what it should return but some online discussions were asking about its return so I wanted to note it here.
Edit: When I tried the examples on Ubuntu, they actually build just fine. Doctor Command also works with examples.
However, the main code has still issues. Initially, I assumed I made some mistakes with esp-idf configurations. But, perhaps that was not the case.
I had the same problem and ended up editing my project's CMakeLists.txt. When I added "esp_wifi" to the "REQUIRES" list, it worked for me:
idf_component_register(
SRCS "main.c"
INCLUDE_DIRS res
EMBED_FILES res/settings.html
REQUIRES esp_wifi
)
Okay, so I'm trying to code & upload to an Arduino with VS Code (Visual Studio Code). When I try to upload or verify my Arduino code, this error pops up:
If you cannot see that, it says:
[Starting] Verify sketch - ir_remote\ir_remote.ino [Warning] Output path is not specified. Unable to reuse previously compiled files. Verify could be slow. See README. Arduino: This application was configured to use a bundled Java Runtime Environment but the runtime is missing or corrupted. [Error] Exit with code=1
Help will be greatly appreciated. I started messing around with the Arduino a few weeks ago, and I've been using VS Code for a long time.
ALSO:
Code works completely fine on Arduino IDE, I want to be able to code and upload to an Arduino with VS Code.
I also tried posting this on the Arduino Forum, and no one replied.
I was able to solve the issue sharing here to help,
I installed Arduino from MS App Store, and i got exactly same error, i uninstalled the Arduino and downloaded installer from Arduino web site, i installed Arduino set the path by pointing to in VS Code settings > extensions > Arduino Configurations > Arduino Path, paste here path to installation folder. And it was all good.
Under project files .vscode folder be sure arduino.json has path set to
"output": "../ArduinoOutput",
Remember that you have to select Development board, Programmer and Serial Port as well in VS Code IDE.
Please View
https://maker.pro/arduino/tutorial/how-to-use-visual-studio-code-for-arduino
Abolfazl Danayi 5 months ago
Salaam
I had the same problem and after following the very nice instructions of the author and what Jack said, I found this:
Add "output": "./build" (or wherever you want) to your ".vscode/arduino.json" file, just as Jack mentioned.
Delete ".vscode/c_cpp_properties.json" file. (If you don't do this, the intellisense won't work).
Build the project again (via verification or upload buttons).
Enjoy (And hope the bests for me in the case your problem is done following this routine!)
I have installed pycparser that parses C code.
Using pycparser I want to parse an open source project, namely PostgreSQL(version-11.0). I have build it using Visual Studio Express 2017 compiler suite. However, during compilation it cannot find some header files, namely windows.h and winsock2.h.
While looking at the directory structure of the build PostgreSQL, I find that it does not have these header files. How to fix this issue?
Also a strange error occurred as:
postgresql/src/include/c.h:363:2: error: #error must have a working
64-bit integer datatype
Note: I am using Windows 10 64-bit platform and postgresql-11.0
The steps are as follows:
I downloaded visual studio 2017, Windows-10 SDK, Active Perl as described in the steps to build from source in PostgreSQL.
After this I open the developer command prompt of Visual Studio and navigate to the folder postgresql-11.0/src/tools/msvc
Use command "build" to build postgresql. The build process was successful, but still windows.h and winsock2.h was not found in directory structure of PostgreSQL.
I don't know pycparser, but your problem probably has two aspects to it:
You didn't give pycparser the correct list of include directories. The header files you mention are not part of PostgreSQL.
Maybe you can get the list from the environment of the Visual Studio prompt. I don't have a Windows here to verify that.
The error message means that neither HAVE_LONG_INT_64 nor HAVE_LONG_LONG_INT_64 are defined.
Now pg_config.h.win32, which is copied to pg_config.h during the MSVC install process, has the following:
#if (_MSC_VER > 1200)
#define HAVE_LONG_LONG_INT_64 1
#endif
Since you are not using MSVC, you probable don't have _MSC_VER set, which causes the error.
You could define _MSC_VER and see if you get to build then.
Essentially you are in a tight spot here, because pycparser is not a supported build procedure, so you'll have to dig into the source and fix things as you go. Without an understanding of the PostgreSQL source and the build process, you probably won't get far.
I am trying to figure out how to package an unchanged fork of VS Code.
My first steps were to follow the electron application distubution documentation, which has not been successful. I also found this post, where another user had the same question. However, the vscode-win32 gulp task seems to have been replaced by x64 and ia32 versions, and when I try running these tasks they generate an out-vscode folder as opposed to a full electron project.
This led me to believe that I can use this new out folder (as well as node modules, packages.json, etc.) with the electron release being used by VS Code to mimic the resources/app folder from the installed version of VS Code in Program Files, however when I try running electron.exe using this method I get:
The factory method of "vs/code/electron-main/main" has thrown an exception TypeError: Path must be a string. Received undefined
In short, I have been struggling with this for a couple of days, and I am out of ideas. If anyone has packaged the project and can offer a suggestion for how to do so, I would really appreciate it.
SOLVED
The issue seemed to be due to being branched off of master as opposed to release. I'd assume there are changes in main that aren't accounted for in the gulp task.
For anyone confused by my post, the expected behavior for a successful build is for a folder named VSCode-win32-x64 to be generated in the directory where your vscode clone is located.
I'm getting the following error when attempting to install a nuget package into a standard .NET framework 4.7 project:
The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
I'm using Visual Studio 2017 15.3.3 Enterprise (latest and greatest).
Given that this is my package, I have full control over the source code. The interesting part is that I have used this package in the past with no changes in the name, but for this go round, I rebuilt it to add a feature and am now getting this error.
Even more interesting is that I have packages from the same library, with the same namespace conventions, with longer names, that work just fine and have installed into this same project with no problems at all.
I have already tried shrinking the package name, shrinking the class names within the package itself, cleaning out the build directory, cleaning out the package home from the nuget server (it's a local server with the latest nuget.server installed which otherwise works just fine), and even clearing out the bin directory of the project in question, clearing out ALL the bin directories of ALL the ancestors to the "offending" package, clearing out the package cache, rebooting the computer and rebuilding the entire nuget package chain from scratch, all to no avail. I was told by one of the MS MVP's that "they fixed that". Apparently not.
Any help would be appreciated here, I'm at my wit's end and have run out of ideas to try.
Thanks.
OK, big Thank You #danmosemsft who suggested digging around with the SysInternals process monitor. After fiddling with it for a bit, I finally figured out how to narrow the result set to just file activity. What I noticed, and the nuget engineers should TAKE NOTE of this: The problem was NOT a too-long project name, rather, nuget was attempting to update a package that was no longer there. Why it went away is a mystery yet to be solved. I normally stay out of the packages directory and do not fuss with the packages.config file. I think that this might have to do with my impatience waiting for VS to start, load all the goodies and then allow me to perform a "Manage NuGet packages" - update all. I remember seeing an update to either NUnit or FluentAssertions that wanted to perform some additional file activity aside from just installing the next version, a script I believe. Can't speak to it with assurance, I wasn't paying that much attention as third party updates usually "just work". I didn't see the "finished" line from NuGet so I think that was the root of my problem. Rather than wait until VS has settled down, I pushed it a bit (hey, the buttons responded so there shouldn't be any problems...).
As a result, the packages directory was absolutely chock full of old stuff that did NOT belong there. So, I manually cleaned up all the cruft, manually cleaned up the packages.config file, restarted VS, waited for it to settle down, performed my NuGet updates and viola! no problem - HAVING NOT CHANGED ANY OF THE ANCESTRAL PACKAGE NAMES BY EVEN A SINGLE CHARACTER.
So, what do I conclude from this? It is my belief, and the guys that actually build nuget and nuget.server should take a closer look at the errors being thrown, such that I think that the error is not so much a path too long error, rather it's a "hey, I didn't find the file I expected so the file name is full of junk (and probably too long now) so I'll throw an error that says it's too long and quit". It's seemingly a failure to handle a missing package/package directory that is causing this particular problem
I solved my problem by ensuring that all the package directories were clean of all junk and rebuilding from a clean source. My problem is now solved.
Thanks to all of you that responded.
Update: While the above contributed to the solution, it was NOT the answer. Here is the sequence of events that led to this problem and it's ultimate resolution.
The solution was created in the C:\User\Sam\Documents\Visual Studio 2017\Projects directory with the specified name of AWE.Lib.ADO.MsSqlSvr.ServerEntityHandler. This worked just fine, no errors. However due to a change in naming scheme from on high, the root directory for this project was changed from "C:\User\Sam\Documents\Visual Studio 2017\Projects" to "C:\User\Sam\Documents\Visual Studio 2017\Projects\DotNet_4.7\AWE 8.x". No problem, I thought - given that a co-worker who also happens to be a MS MVP had told me that all naming length restrictions had been removed in VS 2017. So...I moved the project from it's current home to the directory specified. Compiles just fine, brings in UPDATED BUT ALREADY INSTALLED nuget packages just fine, etc.
Or so I thought. When I needed to add a NEW (one that had not been a part of the solution before) nuget package to the mix, I received the above error. Turns out that the new name of the receiving solution is a few characters longer than VS will accept - the naming length restrictions are STILL IN PLACE.
How did I finally solve the problem: After struggling with this, I threw my hands up and decided to start all over again - a true File | New. So, I started with a new solution named as follows:
"C:\Users\Sam\Documents\Visual Studio 2017\Projects\DotNet_4.7\AWE 8.x\AWE.Lib.ADO.MsSqlSvr.HndlrServerEntity"
THIS GENERATES AN ERROR - name too long. I wondered at Nuget's error in that it specifies that the name should be less than 248 characters in length or 260 maximum.
What I am allowed to use iaw the new solution dialog is this: "C:\Users\Sam\Documents\Visual Studio 2017\Projects\DotNet_4.7\AWE 8.x\AWE.Lib.ADO.MsSqlSvr.HndlrServerEnt", for a total of 106 characters in length. If the directory is shortened, I can add to the length of the name. If I shorten the length of the actual solution name, again, VS'll accept it. So long as the total length of directory plus solution name is less than or equal to 106 characters, there isn't a problem.
The nasty bit comes from creating the solution in one location and having it work in all respects just fine, moving said solution to a different directory, still having it function in all respects (I did NOT need to add any new nuget packages yet), then trying to add a new nuget package to the mix after the move. THAT is what triggered the above nuget error.
So...the ultimate "fix", use a shorter name as it seems that 106 characters is the limit despite what the error messages are saying (and what the MS MVP was told/told me).
There is another reason for this error message by the compiler.
While building , make sure the source code is placed at a folder location which is less than 260 characters long.
For example, a path like C:\Users\User\source\Services\Exp\Sample-web-application-indot-net-displaying-RestAPI\Sample-web-application-indot-net-displaying-RestAPI\SportsStore is around 150 characters long but there are sub folders in the solution which in turn have source code files and so on.
Sometimes the overall length of the path of some files breaches the 260 character length.
I think the future versions of Visual Studio would have a bigger length allowance. Until then, we can make sure that our file names are not too long.
I was running into the same issue after I moved a project to another folder. In my case I closed VS renamed the .vs folder in root to 1.vs (effectively removing it) and re-opend my project.
In my case, I was first trying to install a package using Manage Nuget Packages for Solutions and was getting this error. Then I tried installing same package using Package Manager Console and it worked fine. I again uninstalled that package and tried installing using Manage Nuget Packages for Solutions and this time it worked fine as well.
Well in my experience all i had to do is move the entire project to my c: drive, delete unnecessary folders to ensure the path would be shorter. Done deal.
This error comes to me when I tried to copy the project folder to OneDrive and the problem is that OneDrive is not uploading long name files.
I've fixed this issue by just copying the project folder then paste it in the new laptop using USB.
I wish this could help
Move the folder of the project to a folder within a few levels from the root dir. For example the Desktop and voila.
Try to close Solution from File->Close Solution and opening it again.
For my case uninstalling, installing, or even updating NuGet packages, nothing was working but reopening(sometimes you can also close and open Visual Studio again) the Solution did the magic.