I am trying to migrate an old MFC project to VS 2012 and one of the errors I get is this one:
From what I read is that it has something to do with Help Files, which are not supported on Windows 7.
I thought that maybe Windows is searching for the hcw path so I added to the Environment Variables, but I still get the error. From the code I can see that the command is called inside .mak files:
start /wait hcw /C /E /M "hlp\$(InputName).hpj"
Anyone has an idea how can I get rod of the error ?
Just ran into the same issue. VS 6 project promoted to VS2013.
To eliminate the error. remove the Projectname.hpj file from the project.
Your project requires Microsoft Help Workshop.
Could be a problem in the post build step.
Related
I am using Visual Studio 2022.
I would like to build a project using BJFX.
It is my first BGFX project but I have some issues in the first stage.
I have this error message in the console #error "BX_CONFIG_DEBUG must be defined in build script!".
What is the build script? How can I define this so call BX_CONFIG_DEBUG script or whatever that is?
To be fair, I don't even understang the issue, except that something isn't properly defined.
Does anyone know the issue and how to fix it?
At first, I thought it was an issue occurring from the installation of Visual Studio.
I tried re-installing Visual Studio but it didn't work.
I have looked for a solution on many forums and Youtube but nothing worked for me.
The messaage you are seeing is being emmited by the BGFX headers telling you that you need to define BG_CONFIG_DEBUG. By Build Script this means however you build your code (In this case using VS2022).
I'm going to presume that you're using the GUI.
In the Solution Explorer, right click your app name and select Properties
Now open Configuration Properties->C/C++->Preprocessor:
Here you will find Preprocessor definitions add BX_CONFIG_DEBUG (each value seperated by the ; symbol.
Save settings. Thats it.
I installed Visual Studio Code 1.1 with the C/C++ extension,
opened my C++ project and tried to use "Go to definition" in vain.
The "Go to definition" is not working at all.
Example, go to definition of a class member:
int i = m_myVar;
(I opened a simpler project with one file and it was working for this one)
In the end, what I want is good indexation of my big project, is there a way to install Intellisense?
I had a the same issue: F12 and Ctrl + Click and Right Click "Go To Definition" wasn't working.
The fix for me was:
Go to Extensions
Click "Disable All Installed Extensions"
Close and Reopen VS Code
Back to Extensions and "Enable All Extensions"
Essentially enable/disable all extensions fixed the issue.
I recently came across this same issue and after trying all of the suggested solutions I could find with no success, I found this article:
https://code.visualstudio.com/docs/setup/linux#_visual-studio-code-is-unable-to-watch-for-file-changes-in-this-large-workspace-error-enospc
Basically my project grew too large and VS code was no longer able to track all files, which messed up the "go to definition" functionality.
After following the steps on the link to increase the maximum number of files to be tracked, the issue was resolved.
The correction is pretty simple (tested on Ubuntu 18.04):
Add this line:
fs.inotify.max_user_watches=524288
to the end of the file /etc/sysctl.conf
After saving, run the following command:
sudo sysctl -p
Hopefully this will be useful to someone else, this has been bothering me for the last few days.
I had a similar problem except with Python and google searches for solutions kept bringing me back to this post so I figured I'd post my solution here in the hopes that it might help other people.
I was working on a remote cluster through VScode Remote and was getting similar errors to the original question(all 'go to ___' functionality was unavailable and was even getting a 'too large to track' error) and I thought I had to increase the number of watches, which didn't end up helping.
All I needed to do was install a python interpreter on the remote VScode server. This fixed my problem.
I believe vscode 1.1 (well, 1.1.1 actually) + the C++ extension (cpptools) is as much Intellisense as we can get for now.
You should load your big project with the "open folder" function to make vscode know about the other files.
https://blogs.msdn.microsoft.com/vcblog/2016/03/31/cc-extension-for-visual-studio-code/ warns about letting the indexing finish first (red icon in lower right corner during indexing) and mentions the current limitations on the source code parsing.
It wasn't working on my laptop as well after installing a few VSCode extensions. I decided to close and re-open VSCode with administrator permission and suddenly it sorted out.
I have been trying to fix this for a long time. In the end, what worked for me was simply reinstalling VSCode, then installing the latest C/C++ extension (v0.18.1). Then, in your .vscode/c_cpp_properties.json file, under includePath, add your include folder which has all your header files.
I tried the methods mentioned in this thread none of them seemed to work for me. A simple solution that worked for me is that I closed the current workspace and created a new workspace, added the folders which I required(same as the old workspace), and saved the new workspace. Waited for a couple of minutes to index and IntelliSense is able to find definitions now.
I am using VSCode 1.52.1 on Ubuntu 20.04.
In my case, for whatever reason,c_cpp_properties.json has become set to Disabled in ~/.config/Code/User/settings.json.
Manually changing it to Enabled solved the problem.
Fixed mine by UNCHECKING C_Cpp > Default > Limit Symbols To Included Headers
Your mileage may vary. Good luck!
Have you saved your workspace? Or did you just open a folder with File->Open Folder? This question already has many answers, but none of them address this case, which was my issue.
The question is not specific enough for me to know if you are having the exact same symptoms as my case.
If:
You have not saved your workspace. vscode doesn't say "(workspace)" at the top of the window.
None of the goto functions are working, but instead report: "No ___ found for ____"
The tag parser database icon in the bottom right is always there but only reports "Parsing open files", rather than telling you how many files have been parsed.
Then:
Try saving your workspace.
If you have multiple versions of a language on your PC, specify the exact language you are using in the VScode(in my case, I am using Python, so I must specify the version to the python Interpreter in VS Code)
If you could not do it whatsoever, then uninstall all the other versions that you don't use and then if you go to VS Code, it will ask the version to be used, and you would have only one version, so when you select the version, the "Go To Definition" will be activated.
I was having a similar issue with java on Ubuntu 20.04 using OpenJDK version 11 (openjdk-11-jdk in apt). At first I didn't have the JRE installed, so I installed it and it still didn't work.
Afterwards, I went to the CTRL + SHIFT + P menu and then to Java: Configure Java Runtime, there I saw in the Java Tooling Runtime tab that /usr/lib/jvm/java-11-openjdk-amd64 was selected, changed it to /usr/lib/jvm/java-1.11.0-openjdk-amd64 just to see if it would work, and after a restart it did. I'm not sure why this is, but I hope it may help somone else.
For python ensure your code analysis settings are correct. In my case the languageServer was accidentally set to 'None'. Reverting it to 'default' or 'pylance' did the trick.
Just to inform if none of above works then
In my case i was using Kite extension in my VS code, I just disabled it and it worked. I think kite extension is blocking this feature.
OS: Linux Ubuntu 22.04
if you encountered with following error:
"The .NET Core SDK cannot be located. .NET Core debugging will not be enabled. Make sure the .NET Core SDK is installed and is on the path."
Normally Vscode remains unable to locate .Net sdk. need to set path manually.
sudo ln -s /snap/dotnet-sdk/current/dotnet /usr/local/bin/dotnet
restart omnisharp & restart vscode
No need to do anything. Just close and re-open. It will work.
I also faced similar problem. In my mac os cmnd + 'click' is used to 'go to definition' then it suddenly stoped working. If that is the case then please follow these steps:
restart vs code
restart pc
uninstall all extensions and reinstall again followed by a pc restart.
I had a similar issue with the extension C/C++ installed. I solved it by downloading an older version of the extension and upgrading to the last version. Somehow it solved the problem...
I ran into this problem today while migrating a VS2008 solution to VS2010. The problem occurred in either of the following scenarios:
Rebuild Solution
Clean followed by Build Solution
If I did a second Build after either of these, the problem did not show up. Using Google, all I really came up with was year-old blogs from Microsoft saying they are unable to reproduce the problem, or that it is fixed in a future release.
The best thing I found was here: Mikazo Tech Blog: Solve MT.exe Errors in Visual Studio 2010
In the above article it said that the problem is related to Manifest generation, and that the solution is to turn off Manifests in settings under Linker-->Manifest. I don't need Manifests for this project, but I still wasn't satisfied.
I have solved this, and am simply going to answer my own question, because I haven't found this specific error (code 31) on StackOverflow.
WARNING: This exact error can also happen as a result of having a Windows Explorer window open in the folder containing the *.exe which you are currently attempting to build.
For example: Explorer open in /.../MyProj/Debug/ while trying to build the Debug version of your code in Visual Studio.
I was angry with myself for ~10min before realizing this.
Using process monitor and dbgview I discovered msmpeng (Microsoft Security Essentials) was accessing the file, just when mt.exe wanted to have it exclusively. Excluding the development directory solved the problem.
It is still a workaround of course.
In my projects, the Intermediate and Output directories were set to:
Intermediate Dir : $(Configuration)\
Output Dir : $(SolutionDir)bin\$(Configuration)\
Under C/C++-->Output Files, I had the following:
ASM List Location : $(IntDir)\
Object File Name : $(IntDir)\
Program Database File Name : $(OutDir)\$(TargetName).pdb
Under Linker-->Manifest File, I had:
Manifest File : $(IntDir)$(TargetName)$(TargetExt).intermediate.manifest
The cure was to remove the trailing \ from my C/C++-->Output Files section (because it's already part of those variables):
ASM List Location : $(IntDir)
Object File Name : $(IntDir)
Program Database File Name : $(OutDir)$(TargetName).pdb
Normally, the double-up of using $(IntDir) or $(OutDir) with a trailing \ doesn't seem to cause trouble, even though it's bad practice. I can't remember now whether I did it by accident or if the conversion process did it, but for whatever reason, it seems to have been messing up MT.exe.
I hope this is useful to anyone else who encounters this problem. Your settings may well be different, but consider that it may be related to improperly formed filenames.
Try turning off Windows Defender (or possibly other anti-virus related software). Windows Defender is known to lock files because MT.EXE runs after the linker is finished. WD jumps in the middle to check up on the newly built EXE and locks it up for the MT.EXE.
Giving credit to https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/c5a3e2c3-fbf4-4268-a551-8cee195be586/test-case-13-for-vista-certification?forum=windowscompatibility, I found this was resolved by fixing the '-' character in the post build commandline. I believe some bad copy/paste efforts have replaced a hyphen with a dash.
deleting the "program debug database" in "debug" folder worked for me.
This problem happened when I was running the .exe in the debug folder on high priority.
Run VS as administrator. It solved the problem for me.
I have a project (*.sln) written in visual studio c 8.0. It was migrated to VC10 recently. When I choose the "Release mode", it was compiled sucessfully. But if I choose "Debug mode", the error " MSB6006 mt.exe code 31" happened.
I found that, in the debug mode, it used a wrong sub-project to startup.
After fixing the startup sub-project, it goes fine so far.
---- new status ---
This won't fix the problem. It just makes the problem disapear temporalily by rebuilding-all. Also, there are other faults caused by the migration. The "resources.h" is missed from the new project and the "winres.rc" is shorten.
In my case it was a problem with TortoiseGit. Removing Debug and Release folders from the GIT repository solved the problem.
Check if you have any anti-virus software like AVG. Exclude the manifest files in the anti-virus software exclusion list.
Look for an MSB8012 warnings. Likely you have a different output specification for the C++ output value and the Linker Output value.
Try Sysinternals/Procmon and filter on process = "mt.exe". It might tell you that a build input cannot be found.
[edit] Sorry, I out thought myself. I was using a .bat file to set environment variables that wasn't set up properly. When I went to a straight VS2005 command prompt, the configure ran fine. Sorry for the noise.[/edit]
I'm trying to compile qt-everywhere-opensource for embedded. I'm using MSVC2005. However, I guess I am confused on the process. I am getting compiler errors during the configure step. I thought the configure step was just trying to generate the needed makefiles, so I'm not sure what it is trying to compile.
I expected to modify the mkspec, but I'm not sure if during configure I should point to windows headers or sdk headers. I know during the build phase I should point to sdk headers, but I'm not getting that far.
I can change the errors by modifying INCPATH, there's also a QMAKE_INCDIR that seems to have an effect. It occurred to me that since I pulled the source, maybe configure needs to build the compiler tools, in which case I should point to MSVC headers. I also tried downloading the SDK and adding the path to it's bin folder to my path ahead of the -everywhere- source, but that didn't fix the problem and I don't want to jack up my system too much testing things.
Hope someone out there can help!
When you install Qt from source under Win32, you must:
Extend the PATH variable to include $(QTDIR)\bin, where $(QTDIR) is the directory where you installed Qt.
Open a Visual Studio command prompt in $(QTDIR); a plain old Windows command prompt won't do (unless you run vcvars.bat to load Visual Studio's environment variables; but opening a Visual Studio command prompt directly is better).
At this point, configure should run properly, after which you can run nmake.
I suggest that you clear your previous installation attempts from your system before you try these steps.
When I try to build my project I get the following message in the build window :
========== Build: 0 succeeded or up-to-date, 0 failed, 1 skipped ==========
I tried rebuilding , then building again , but it doesn't help . Is there a way to view more detailed messages ? The "skipped" part doesn't give me any info on what's wrong . I am using Visual Studio 2005 Professional Edition .
Check with the configuration manager like CMS said and make sure that you have the right platform set. A lot of the time when you use something like the MS Application Blocks the default platform is set to Itanium.
Check on your solution properties, then go to "Configuration Properties", and make sure that all the projects that you want to build, have the build flag checked:
Yet another reason why this could happen (as it happened to me):
When your VS installation is missing x64 compiler toolchain, and you're building for x64.
To solve this, find MSVS in appwiz.cpl ("Programs and Features"), click "Uninstall/Change", then go to the x64 toolchain checkbox under C++ and check it.
This recently happened to me when I tried to compile a project that was apparently orphaned from it's parent solution.
When I finally did get it to compile, it wouldn't work because some library from another project was missing (that was supposed to be part of the solution to get a successful build).
Hmmm... I remember cursing at that one once? Just guessing from my awful memory, but perhaps the output directory path doesn't exist?
I have found the solution *.sln file to be the problem.
Reverted back to a previous version and it fixed the problem.
Often the project references a project that is the actual offender, so try and build up the reference list to see where the problem is.
I generally run into that when the PC is low on resources (RAM), after closing things the build runs fine.