I'm trying to create a Webots controller in VS2017 (through the webots software). When it loads up Visual Studio, everything is linked correctly and compiles correctly until I close VS and reopen it. Afterwards the macro of $(WEBOTS_HOME) changes to an incorrect path, which messes up the links to the files and libraries.
I tried to hard code the path in through properties editor, but it just says that all the files don't exist.
Links to error images:
Correct Macro Path
Incorrect Macro + Correct Hard Coded Path
Error From Hard Coded Path
Is there any way to change what this macro evaluates as, or a way to keep it from changing in the first place? After spending a couple hours on the internet looking for answers, I've determined that I can't add a user macro, which was my idea to replace the broken macro, because I can't access "Project Manager" Tab, only a console version.
The WEBOTS_HOME environment variable is indeed supposed to be defined (for a typical Webots installation: WEBOTS_HOME = C:\Program Files\Webots). It can be defined in your user environment variables. Doing this, it will be accessible from VS.
Related
I recently begin to use Qt and decided to use it with Visual Studio (2013).
The problem is that when i create the project the Qt classes even the most common can't be included (as QApplication) even if i had to it every Modules (core GUI...). Intellisense underline it in red saying :"cannot open source file QApplication". And when i try to run the project, it tells me that i missed some .dll. The weirdest thing is that i already manage (2 times) to make it worked, simply by creating the project without doing anything special(i think).
Moreover when i use the qtcreator it works fine but i'd like to use VS.
Sorry, i had a hard time being specific since i really don't have a clue.
In addition #drescherjm comment, you should also check that you have an system environment variable set - The variable name should be QTDIR and the path should be the path of your installation - on my system this is C:\Qt\Qt5.5.1\5.5\msvc2013.
OK, it seems i found a way to resolve the problem but i still don't get why.
It appears that if i go in the Qt options even if the path is already set, i need to select it and press ok. And then build the project and reopen it for intelisense to work. And it worked. But it's weird because i already fund the place where the qtdir variable is stored and it was alright but the project still didn't worked??
I migrated c++ solution with multiple projects from VS2010 to VS2012.
Projects have reference of libraries with path set as System variables.
Application is getting compiled and run. But Intellisense reporting errors for all symbols and header in libraries. In External Dependencies node in solution explorer, it is not showing header files of 3rd Party libraries.
Headers file with hard coded and relative paths don't have this issue.
When right clicked on Header declaration to open header files, it shows all paths specified in project by striping environment variable values. e.g.
if include paths are "C:\QT\Includes;..\..\VISLIB\Inc;$(PROBAL_SHT_LIB)\V18.05\Inc", then it will show message "File 'XX.h" not found in ....... Build system path:
C:\QT\Includes;..\..\VISLIB\Inc;\V18.05\Inc.
and strips $(PROBAL_SHT_LIB).
Also noticed that if I set new system variable, then it is not shown in "Macros". or code is not getting compiled with VS2012. To make VS2012 recognize this variable. I need to restart PC.
This was working fine with VS2010.
You should know that the frontend/parser used by intellisense is not the same as that used by the actual compiler.
They are not always updated in sync and they often have different levels of feature completeness and different bugs. Thus it is not uncommon for intellisense to complain about perfectly valid code that the real compiler will handle just fine.
That is, of course, not great - but it is a fact and noone but Microsoft can do anything about it.
I am currently using Visual Studio 2013 (Update 4) for building Qt5.4.0 projects. I use the express version so I don't use the VS plugin. My .vcxproj files a generated from .pro files using build scripts and qmake.
When debugging my projects I sometimes try to step into Qt library code. To do this I added the path to the Qt source codes to the solution properties->Debug Source Files setting like described in a former post (VS2013 debugger can not find Qt sources).
Because I have many different projects and it would be a pain to update all of them in case of a Qt update I used a system environment variable "QTSRC" pointing to that path and added the following line to the solution:
$(QTSRC)
This worked like charm some time ago (with an older update of VS and a former Qt version 5.x).
But unfortunately it does not work anymore. It seems that VS now totally ignores the system environment variable (it also does not show any errors when I check the "check entries" button in the dialog).
Does anybody know what changed here lately and what must be done to fix this? It would be very annoying to add the path hardcoded to every project (which still works) and have to do this over and over again after Qt updates.
I'd look at the Property Pages which will allow you to set user defined values that you can share across different projects:
http://msdn.microsoft.com/en-us/library/675f1588.aspx
I use them to set global include paths, but it looks like you can set almost anything there. Set things in the .User pages if you want them used for all your projects but not included in the solution or project file itself.
A good, short, guide is here:
http://www.curlybrace.com/words/2012/12/17/setting-global-c-include-paths-in-visual-studio-2012-and-2011-and-2010/
I am creating a simple C++ DLL project using Visual Studio 2008 Express Edition.
I have a few classes inside a namespace, and a few non-static functions and constructors inside it are declared with __declspec(dllexport).
All those functions are implemented.
I also have an extern "C" BOOL APIENTRY DllMain function which simply returns TRUE.
As I hit Debug(or Release), it successfully builds with no errors nor warnings.
The output folder(either "Debug/" or "Release/") gets files such as "BuildLog.htm", one ".obj" file per source file, "vc90.pdb", "vc90.idb", "[DLLNAME].dll.embed.manifest", "[DLLNAME].dll.embed.manifest.res", "[DLLNAME].dll.intermediate.manifest" but... not the DLL itself.
This is the first time I try to compile this project(so I never sucessfully compiled before) and I have little experience with C++/DLLs, although I do know standalone C++ and created Linux C shared objects before.
What am I doing wrong? Is there any particular required file that I'm missing?
I'd look up a little higher in the directory structure (the one that the solution is in) and see if your Debug/Release folders (with the DLL) are there.
I think the default is to put the actual DLLs in folders in the solution directory, not the project directory (I think the assumption is that you want all the DLLs that you build for a solution to go to the same place)
Right click on <ProjectsName> in Solution Explorer View, select Properties, go to Configuration Properties > General tab and check out the Output Directory field. The path may consist of some macros like $(SolutionDir)$(ConfigurationName) etc. Click on it, select Edit and then when a window pops up choose Macros to see what they actually mean e.g. which directory SolutionDir maps to. You can deduce the output dll's path from there.
I have a few things that I cannot find a good way to perform in Visual Studio:
Pre-build step invokes a code generator that generates some source files which are later compiled. This can be solved to a limited extent by adding blank files to the project (which are later replaced with real generated files), but it does not work if I don't know names and/or the number of auto-generated source files. I can easily solve it in GNU make using $(wildcard generated/*.c). How can I do something similar with Visual Studio?
Can I prevent pre-build/post-build event running if the files do not need to be modified ("make" behaviour)? The current workaround is to write a wrapper script that will check timestamps for me, which works, but is a bit clunky.
What is a good way to locate external libraries and headers installed outside of VS? In *nix case, they would normally be installed in the system paths, or located with autoconf. I suppose I can specify paths with user-defined macros in project settings, but where is a good place to put these macros so they can be easily found and adjusted?
Just to be clear, I am aware that better Windows build systems exist (CMake, SCons), but they usually generate VS project files themselves, and I need to integrate this project into existing VS build system, so it is desirable that I have just plain VS project files, not generated ones.
If you need make behavior and are used to it, you can create visual studio makefile projects and include them in your project.
If you want less clunky, you can write visual studio macros and custom build events and tie them to specific build callbacks / hooks.
You can try something like workspacewhiz which will let you setup environment variables for your project, in a file format that can be checked in. Then users can alter them locally.
I've gone through this exact problem and I did get it working using Custom Build Rules.
But it was always a pain and worked poorly. I abandoned visual studio and went with a Makefile system using cygwin. Much better now.
cl.exe is the name of the VS compiler.
Update: I recently switched to using cmake, which comes with its own problems, and cmake can generate a visual studio solution. This seems to work well.
Specifically for #3, I use property pages to designate 3rd party library location settings (include paths, link paths, etc.). You can use User Macros from a parent or higher level property sheet to designate the starting point for the libraries themselves (if they are in a common root location), and then define individual sheets for each library using the base path macro. It's not automatic, but it is easy to maintain, and every developer can have a different root directory if necessary (it is in our environment).
One downside of this approach is that the include paths constructed this way are not included in the search paths for Visual Studio (unless you duplicate the definitions in the Projects and Directories settings for VS). I spoke to some MS people at PDC08 about getting this fixed for VS2010, and improving the interface in general, but no solid promises from them.
(1). I don't know a simple answer to this, but there are workarounds:
1a. If content of generated files does not clash (i.e. there is no common static identifiers etc.), you can add to the project a single file, such as AllGeneratedFiles.c, and modify your generator to append a #include "generated/file.c" to this file when it produces generated/file.c.
1b. Or you can create a separate makefile-based project for generated files and build them using nmake.
(2). Use a custom build rule instead of post-build event. You can add a custom build rule by right-clicking on the project name in the Solution Explorer and selecting Custom Build Rules.
(3). There is no standard way of doing this; it has to be defined on a per-project basis. One approach is to use environment variables to locate external dependencies. You can then use those environment variables in project properties. Add a readme.txt describing required tools and libraries and corresponding environment variables which the user has to set, and it should be easy enough for anyone to set up.
Depending on exactly what you are trying to do, you can sometimes have some luck with using a custom build step and setting your dependencies properly. It may be helpful to put all the generated code into its own project and then have your main project depend on it.