As the title says, I'm getting assertion errors for files located on the D:\ drive, but my install is plain vanilla C:\ drive.
Assertion failed: ... [File:D:\build...
This is because you're using the nonfull source Unreal Engine.
For nonfull source Unreal, I know with Unreal's config for Visual Studio Code they use a source file map to map to your system's Unreal Engine path for debugging purposes. I'm sure they also do this with other IDE/Editors whenever possible.
Currently there's a bug with the Window's Unreal config for VSCode. In launch.json, where the soureFileMap setting is, they forgot to escape the '\' causing a malformed json file.
I do fix this in my VSCode extension for people who do use VSCode.
https://gist.github.com/boocs/f63a4878156295b6e854cac68672f305
Unfortunately I haven't tested if it works, just escaping the '\', because I'd need to find code that causes that exception.
Related
I'm using Microsoft Visual Studio Professional 2017 to build a project that uses the Poco libraries.
Background:
Don't know if this is pertinent, but I'll just mention that I manually downloaded and built Poco (and all the other libs needed), and everything went fine for years. Now I switched to using Miniconda3 to manage my libraries, installing Poco via conda install -c conda-forge poco and changing the relevant include paths from
$(POCO_DIR)/Foundation/include
$(POCO_DIR)/Util/include
...
to just
$(CONDA_LIBS)/include
with the system variable $(CONDA_LIBS) = D:\CodeLibraries\conda_libs\Library. This CONDA_LIBS directory exists and contains an include/Poco/ subdirectory with all the Poco header files and subdirs.
Problem:
The project compiled fine. I got a linker error, and while digging into this I found some odd behavior of Visual Studio 2017:
When I'm moving the cursor to an #include directive using any Poco header file, e.g.
#include "Poco/DateTime.h"
I can usually type CTRL+SHIFT+G to open and jump to the file in question.
This doesn't work anymore, and I get a popup telling me
D:\CodeLibraries\conda_libs\Library\include\oco\atetime.h
Cannot open file.
Note the missing letters in \(P)oco\(D)atetime.h. Note, also, that a file is found, but cannot be opened.
When I try this with a header file in a subdirectory like
#include "Poco/JSON/Parser.h"
I get the message
D:\CodeLibraries\conda_libs\Library\include\oco\son\rser.h
Cannot open file.
Note the missing letters "P", "J", and "Pa"(?!) in (P)oco\(J)SON\(Pa)rser.h.
Additional information:
The same error pops up when I drag-and-drop a Poco header file from the Windows Explorer into Visual Studio (!)
I can open these files from the Open File dialog (CTRL+O)
I can still use the CTRL+SHIFT+G shortcut to open my own header files in my project, and to open other library header files like gdal.h or boost headers
if I #include "oco/ateTime.h" (note the missing letters) and attempt to open it via CTRL+SHIFT+G I get the expected message "File 'oco/ateTime.h' not found in current source file's directory or in build system paths", with the paths listed below including D:\CodeLibraries\conda_libs\Library/include.
Question:
Any idea why both the CTRL+SHIFT+G shortcut and the drag-and-drop operation fail for Poco header files?
EDIT:
Please note:
I'm not asking about generic "File not found" errors: I can usually handle my include and lib paths quite well, thank you
slashes and backslashes can be used pretty much interchangedly in Visual Studio for the last couple of years at least
"Cannot open File" error could be due to a misconfiguration in your project include and source paths or due to a third-party extension or maybe even due to a corrupt/buggy IDE, but it has nothing to do with linker errors as you have also mentioned. You have also confirmed that the files are getting compiled, so this is surely some issue with the IDE's built-in code navigator or an extension.
With respect to linker errors, the project Configurations, lib target, library & header file versions you are referring to should match while linking against third-party libraries.
These are some general checklists for linking third-party libraries:
Runtime library: MT, MTd, MD, MDd, etc
Character set: Unicode or Multibyte
Target compiler
Target Machine
Subsystem
Whether the third-party library being used has additional dependencies, and you are properly linking the exact version of them.
These are checklists specific to POCO:
POCO version you are referring to in header files vs linker path
configurations.
OpenSSL version you are linking your project against, if you are
using SSL, Crypto and NET modules of POCO.
The same setup on my machine (but with VisualStudio 2019 configured for VisualStudio 2017 target) works just fine.
Odd.
When I returned to the office today, I wanted to look into this again to see if I could find out more about IntelliSense not finding POCO headers and about the odd dropping-characters thing in the error message, but it works now:
yes, I can once more jump to a POCO header file by moving my cursor to the #include line and hitting CTRL+SHIFT+G.
No idea if it was restarting VS that fixed this, or fixing the linker error -- which was trivial, BTW, and I might even have done at the side that while writing this question. Unfortunately I either didn't recheck for broken IntelliSense behaviour after the linker fix, or didn't bother recording that IntelliSense still was broken afterwards.
So: no real closure, I'm afraid.
EDIT: Ramesh Kambadaasan's answer suggests that a workaround might be to delete the IntelliSense DB file(s) and to restart VS to force a project re-parse. I'll try that next time.
In Windows you should use "\" as a directory seperator, not "/".
My guess is that VS replaces your "/" with "\", then the first letter of every word is an unescaped character.
Try to replace your "/" with "\\".
I have VS 2013 Update 4 and I am trying out TS for the first time.
I can't the compiler to do its job, I get a 'Command "tsc" is not valid' error in the Command Window.
I have verified that I did have the correct PATH entry and that it pointed to the correct location for tsc.exe. I have tried closing/opening the command window and restarting VS as others have suggested.
Automatic TS compiling is also not working. I have tried excluding and re-adding the .ts file and turning on compile module not part of project.
Any ideas what else I can try?
Edit: Automatic compilation is actually working. I was assuming that the resulting js file would show up in the project tree so I could add it to my html. It does not. The .js file is created, even if you see no evidence within VS. If you drag the .ts file into your code window, it actually adds the .js file.
There are a few interesting points to note...
Check your PATH... I know you already did this, because you mention it in your question, but really double check it. Manually browser to c:\Program Files (x86)\Microsoft SDKs\TypeScript\ and see what your most recent version is. Then check that your PATH variable points to that folder. You sometimes have to restart to get the PATH variable refreshed everywhere it gets used.
Don't expect to find JavaScript files in Visual Studio. This has been the case since v0.9.5. They are like DLLs - you don't browse them, edit them, or check them into version control.
Still a problem? Open a command prompt (in the solution context) and try tsc -v. This not only checks your PATH is right, it will tell you which version it is pointing to. Maybe you still have the old path to tsc as well as the new one in your PATH variable.
I'm using SDL in VS2013 and I'm trying to load an image from the folder that my working directory should be using a relative path. Which is where the .vcxproj files are. However I discovered that the working directory is not the folder it should be, it is actually in C:\Windows\System32. I have realised that this is only the case when I go to linker, system and then change the subsystem to CONSOLE. In a WINDOWS subsystem it uses the correct working directory. Why is this happening and how do I fix it?
I think it may have something to do with VS2013 using cmd.exe which is in the system32 folder but I cannot be certain and would not know how to fix it even if that is the case.
Hmm...I don't think I've ever had that problem, and I always write with the console window. Have you tried just making a new project to see if maybe something got set in your properties by accident or something? I would give that a try, or maybe re-install SDL..? That's weird, sorry I don't have better advice!
Sorry for what seems like a silly question: But I've never, ever worked with boost, until tonight, and I'm finding that getting it configured seems to be harder to use than it should be.
I wanted experiment with it tonight. So I downloaded the zip file, and unzipped it to a directory here:
F:/boost_1_44_0
Then I created an empty c++ project in visual studio 2010 (not using pch either). So all I wanted to do was to include a header file. But not even a silly thing like that seems to work. Now I've been using visual studio for years, though at work we are still stuck on vs 2008 (That is another story). So usually what you do is set an include directory, and then you can include files in at will right?
So I set the global include directory to include the boost root. i.e. Property Manager -> My configuration (debug|win32) -> Microsoft.Cpp.Win32.user -> Common Properties -> C++ Directories -> Include Directories. There I added my path to f:/boost_1_44_0.
I also went to the project properties and set the C++ include directory for the project to point to the boost root like in vs 2008.
I then added a silly include declaration like so:
#include <boost/lambda/lambda.hpp>
But, amazingly it fails to compile!!! with the following error:
Error 1 error C1083: Cannot open include file: 'boost/type_traits/transform_traits.hpp': No such file or directory f:\boost_1_44_0\boost\lambda\core.hpp 25 1 test_boost
Which when I double click it, it opens up in f:\boost_1_44_0\boost\lambda\core.hpp, and takes me to this line:
#include "boost/type_traits/transform_traits.hpp"
So I have no idea what's happening. Is visual studio just not delivering up my global include paths that I set? It seems also that the include directive in core.hpp should be using angle brackets and not quotes.
If I'm doing something wrong what?
EDIT:
!! SOLVED !!
Before I didn't have all the files unzipped. I don't know what happened. So I re-downloaded the zip file, and unzipped it again. This time the zip file took much longer to unzip, and it extracted much more files: Including the missing files.
Problem solved, my hello world app compiles just fine now.
The behaviour of compilers in locating header files is implementation defined for both the <> and "" variants.
However, based on this page for VC2010, it appears the quoted form searches a superset of the angle bracket form so I'm not sure that's the problem.
I suppose it would be a silly question to ask if the following file actually existed?
f:\boost_1_44_0\boost\type_traits\transform_traits.hpp
So, a couple of investigative jobs:
Make sure that f:\boost_1_44_0\boost\type_traits\transform_traits.hpp exists.
Try changing your top-level include to use quotes.
Try changing the include in f:\boost_1_44_0\boost\lambda\core.hpp to use angle brackets.
Make sure you try all four possibilities for those last two.
Is f: a network-mounted drive? What happens if you put it all on c:?
That last one is just in case Windows is doing some shenanigans under the covers :-)
While it's a bit overkill for this, learning to use SysInternals' Process Monitor will pay off over time. It will show you what files are actually opened, and which attempts failed. Look where Visual Studio tries to read transform_traits.hpp from, and you'll probably have the answer.
I have copied a whole project onto my PC, both into My Documents/Visual Studio and into inetpub/wwwroot, but when I try to open the project in Visual Studio, it tries to open just 1 file .vssproj and gives me error messages, like : "The project file cannot be loaded. The application for project ... is not installed.". What am I doing wrong?
If VS 2005 has not been upgraded to Service Pack 1 then a web application project (rather than a website) will give this error.
I had this same exact error when double-clicking on the file as opposed to going to VS and using its menu to open it. It seems a problem with file associations.
As others have said, without knowing a specific error it's hard to help. However, the sln and csproj files are just text files, you can always just open them up in notepad and do a search and replace on any obvious path problems. It's often quicker than creating a new project and adding all the files / references.
Without telling the specific error you're getting it's hard to help, but I'm guessing the file paths in the project file are incorrect. Try creating a new project and manually adding the files and see if you get the same errors.
Without the specific error messages, it's tough to be sure, but if you have an entire solution from your source machine rather than just a single project, you may want to try copying that over instead.