The other answers i've seen proved to be ineffective.
I'm using c++ and it gives me error(red squiggle) when i include vector or string.
It tells me that my include path is not updated so i click on the lightbulb and try to edit intellisense configurations.
In this window there's an include path section, inside the box there's this string: ${workspaceFolder}/**.
So is this string the problem?
I've tried to put in this box the following path as well:
/usr/local/include but it doesn't change anything...
Please what should i change about this include path??
What is there supposed to be in it?
Press Ctrl+Shift+P to open the Command Palette
Start typing "C/C++" and then choose Edit Configurations (UI) from the list of suggestions. This opens the C/C++ Configurations page. When you make changes here, VS Code writes them to a file called c_cpp_properties.json in the .vscode folder.
Find the Compiler path setting. VS Code will attempt to populate it with a default compiler based on what it finds on your system. For Clang on macOS, the path should look like this: /usr/bin/clang.
The Compiler path setting is the most important setting in your configuration. The extension uses it to infer the path to the C++ standard library header files. When the extension knows where to find those files, it can provide lots of useful information to you as you write code.
Set IntelliSense mode to ${default}, which on macOS is clang-x64.
You only need to modify the Include path setting if your program includes header files that are not in your workspace or in the standard library path.
On macOS, you must set the macFrameworkPath to point to the system header files.
Visual Studio code places these settings in .vscode/c_cpp_properties.json.
Original documentation here!
Related
I want to ask a question about Xcode syntax coloring (highlighting). I am working with files all the time .tcl files all the time and Xcode does not know extension and as default it opens them with "Generic" syntax coloring option. In this situation, "AppleScript" in the syntax coloring section will be very nice for files with .tcl extension to see all the colors for different things in the code. So, how can i add a new option for .tcl files or how can i change the "Generic" one which appears when i open a .tcl file in Xcode ? Is there any way to do it as defaultly open the .tcl files with "AppleScript" syntax coloring ?
Thank you for your answers...
Yes there is.
What you need to do is create a new macOS project in Xcode (I will call it SyntaxHighlighting:
Then go to Info -> Exported UTIs:
Click the plus button. Set the Identifier to something like com.umutkeskin.tcl-source.
The Conforms To section tells you what highlighting the UTI will use. You can see the full list of System-defined uniform type identifiers here. The one you want is com.apple.applescript.text.
Set the Extension to tcl. This sets the file extension that this UTI will be used on.
Now run the project, and... Viola!
I have a project where the referenced assemblies have symbol files available. Both pdb, and the source files themselves. (they are all my own libraries). The symbols are all listed in the Tools / Options / Debugging / Symbol marking their locations. Thats all fine.
But it's working with them, i'd like to know:
Is there a way in Visual studio to set a breakpoint in a file of the symbol before having to debug line by line to get to the code in question.
To be clear, if i step line by line i can eventually hit the source (because of using the symbol files) code i'm after. But some times getting to that location is not easy, because it's so nested within multiple symbol files. BUT once i eventually step deep enough and find the code, i can set the breakpoint, and from there on stop and start the main application and get to that location without trouble. The file code and all is even listed in the open file pane, for easy view.
Is there any way, if i know the file and line of code i want to break at, open that file in VS and set the breakpoint directly?
Hopefully i was clear in the description. Let me know if i need to reword.
tx
I bet the code you want to put a breakpoint is in a function (;)) so I would use a New breakpoint option from Visual Studio. This allows you to put a method name that VS should break on when entering the method (so basically on the first { after the function name).
After pressing CTRL+B you will be presented with the dialog
Here you specify a function name you want to put a breakpoint on.
You can just specify just the name (like. AppendText) or fully qualified name (with namespace - System.Windows.Forms.TextBoxBase.AppendText). If you want to narrow it down to a specific module user module_name!function_name syntax. If needed you can specify on which of the overloaded function you want to break on.
All this info you can get by hovering over an (i) icon on this dialog.
OK. Knew there had to be a way. And it's very simple.
As stated, if you have the symbol and source available for the Nuget packages you are working with follow these steps:
open the main project in question in Visual Studio.
In VS, click File / Open File...
Under your PACKAGES Folder, locate the package for the reference you want to set breakpoint.
In that package locate the source code folder that was packaged along with the pdb file.
There you will find the source code. Now locate the file you want the breakpoint placed in. Click that file to OPEN the file in Visual Studio.
That file is now OPEN in your VS viewer, but it is not included as a new file in your project (good thing).
Place breakpoint where you want.
Run solution. Now you don't have to step through your entire solution to get to the code you wanted to review with that breakpoint!
what a relief!
XCode2 had this beautiful feature: you put the cursor on a line with a #include <file> and execute the open-quickly command (command-shift-D) and it would open the file. I can't get it to work for me in XCode3.
I have something like this
#include <folder/subfolder/HeaderFile.hh>
and when I put the cursor on this line, and open the open-quickly dialog, it automatically fills the search window with
folder/subfolder/HeaderFile.hh
but doesn't find anything. If I then remove "folder/subfolder/" then the dialog will identify HeaderFile.hh and I can open it up. But this extra deleting is so much slower just the three-key command-shift-D opening I was used to with XCode2.
If I give it the full path to this file in the search window, then it finds it:
/Users/andrew/myproject/src/folder/subfolder/HeaderFile.hh
this path will find the file. Again, I don't want to spend all my time typing out the full path.
I created this project as an external build system, and I think that's related to the problem; the xcode project lives in
/Users/andrew/myproject/xcp_dir/
and I want it to search in the "../src/" directory so that the partial path I give it (which is already present in the #include) will match the file I want to open. In XCode3, I had to create the project in the xcp_dir directory; in XCode2, I could create the project directly into the existing myproject/ directory -- maybe that's why the search is failing?
I read on a previous thread (which never answered the question) that I should set the HEADER_SEARCH_PATHS option. I tried this (setting the option to /Users/andrew/myproject/src) but it did not work.
I don't have any sense of what other options (like the HEADER_SEARCH_PATHS option) are availalbe, so if you know which one I have to set, I'd love to hear it.
Since this is an old question I'll answer it for Xcode 4 instead of 3.
As far as I know Open Quickly doesn't use anything like a search path. It seems to have use the project's codesense index and will show results from that. Querying the database doesn't have an notion of file paths, so the workflow you describe just won't work anymore.
However that's okay, because there's a better solution: Just ⌘+click on the include line and the appropriate file will be found using the same rules as the compiler uses, and opened. If you want to open the file up in an assistant, another tab or window, you can use ⇧⌘+click instead, and you'll get a little UI for easily selecting where you want the file opened.
You can also use these shortcuts to go to definitions for any identifier.
If you don't want to use the mouse you can use the command "Jump to Definition" which has the shortcut ⌃⌘J, or ⌥⌃⌘J to open the definition in the assistant editor. This also works for both normal identifiers and #included files.
I'm trying to build gtest on Visual Studio 2010. After converting the solution file, I tried to build, and I got the following warning messages.
Warning 1 warning MSB8012:
TargetPath(C:\Users\sucho\Desktop\gtest-1.5.0\msvc\gtest/Debug\gtest.lib) does not match
the Library's OutputFile property value (C:\Users\sucho\Desktop\gtest-1.5.0\msvc\gtest\
Debug\gtestd.lib).
This may cause your project to build incorrectly.
To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property
values match the value specified in %(Lib.OutputFile).
C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets
The message says I need to setup variables $(OutDir), $(TargetName) and $(TargetExt), together with property values specified in %(Lib.OutputFile).
How can I do that with Visual Studio (especially VS 2010)?
I see it. Right-click the gtest project, Properties, Configuration properties, General. Ensure that the Debug configuration is selected (upper left combo). Change the Target Name property to
$(ProjectName)d
Note the added "d" to change the name from gtest to gtestd. The warning is otherwise benign.
I think no one has the right answer, i solved this way: in project properties pages, check if linker->General->Output file match configuration properties->General->target name & configuration properties->General->target extension.
You don't need to add any 'd', of course, is more simple set to Inherit from parent or project defaults, for all 3 variables.
Example:
Linker → General → Output File = "myproject.exe"
then:
Configuration Properties → General → Target Name = "myproject"
configuration properties → General → Target Extension = ".exe"
The warning is spurious -- assuming you're using Google Test, it works just fine
You can make it go away however. Right click on the offending project and select properties. Select "Librarian" in the tree view on the left hand side, and change the "Output File" item on the right by clicking on the box next to output file, and selecting "Inherit from parent or project defaults".
The background to this is that Microsoft changed the meaning of the $(TargetName) macro. It used to mean "whatever filename you put in Linker | Output File, minus the extension". They changed it to "by default, the name of your project". (This is something you should never do, in my view; they should have added a new macro).
Whereas VS2008 and earlier were able to parse the file name out of the Linker setting, apparently they were not able to parse it out in the migration to newer versions, leaving our configurations broken.
The warning itself is probably not important, but if you use $(TargetName), say by passing it to a batch file, this change will break your batch process.
For us, the solution has been to copy the file name (minus extension) from Linker | Output File to General | Target Name, and then set Linker | Output File to "inherit from parent/default". This is because we use suffixes like "d" (for debug), "u" for Unicode, _64 for 64-bit and so forth.
On the other hand, if your output file always matches the name of the project, then all you need to do is set Linker | Output File to "inherit default" and you're done, in principle - providing that the output directory you want for your compiled file matches General | Output Directory.
This change is absolutely infuriating because it involves moving literally hundreds of settings around, all due to sheer laziness on Microsoft's part, as far as I can see.
I was just trying to compile an application in Visual Studio 2019 that I had last compiled in Visual Studio 2005. I encountered the same warning.
I thought I would show what I did visually with screen shots.
Solution Name v Target Name
As you can see, my variables were both set to Import Text:
I could have just set the $(TargetName) to ImportText to solve my issue. However, we will leave those values as they are.
Linker / General Output File
This is how I had the output file setup:
Notice that I had overridden the output target name as ImportText. This was over 10 years ago and I did not have as much experience.
General / Target Name
So all I had to do was make the same adjustment here:
Now it compiles file.
This kind of errors typically arise when upgrading old project to new version of Visual Studio (like in your case to VS2010) and also if project settings may have been manually changed (for example changing executable name). We know VS2010 uses these macros $(ProjectName) $(TargetName) $(OutDir) $(TargetExt) to control release/debug outputs but it is often mystery where to change them. We than typical resort to changing the name of output files directly through Project >> Properties. This means we now have to change the output files separately for debug and release build and if there was any dependencies, we will get error like This may cause your project to build incorrectly..
These macros/properties are VS2010 defaults but you can set them yourself in .vcproj files by editing it in notepad. Note search first for the property in the .vcproj file first, if its there than change its value, if not define it like below.
<PropertyGroup Label="My Values">
<ProjectName>New_Project_Name</ProjectName>
</PropertyGroup>
Above I have defined a new <property group> to keep these values but you can define them anywhere. I define this at the top of the file right after debug/release configuration group so its visible everywhere. Make sure your project properties are setup properly to use them correctly (they should be what is VS2010 default settings). If you have changed them you should copy it from new test project. You can of course add the other Macros you want to set values for in the above group as well.
You can also verify the new values of this macros through project properties. For example click in Configuration Properties >> General and than in 'Target Name' box. Select edit. It will bring up a dialog box with the button 'MACROS >>'. Click that and it will show you what the value of each macro is. It should correctly reflect the new values that you set in .vcproj file.
Just as Hans Passant posted, you need to modify the TargetName property manually. This is different between VS2005/2008 and VS2010. Please refer to http://social.msdn.microsoft.com/Forums/en-US/vcprerelease/thread/3c03e730-6a0e-4ee4-a0d6-6a5c3ce4343c
Is anyone aware of a way to make visual studio completely ignore a file when compiling? I have a C# solution that has a foo.config file that isn't really a standard config file - it's just a text file. During compiling VS grabs a hold of the file and bombs.
I'd like for it to act as though it's just a text file. I do not have the option of changing the name of the file.
EDIT: Please note that BuildAction does not exclude files from the compiler checking them. It simply decides if the file is compiled into the assembly, whether it's content (like a jpg or something), or whether it is a resource file. For more info: see the MSDN page.
EDIT2: Apparently, if you have a text file that is named foo.config and you have it open while building, VS2005 will pop up an error thinking that the file should be xml. However, if you close the file, VS2005 will ignore it.
Solution: Visual Studio validation causes errors if you have a non-compliant file open during build time. For an example of how to turn this off (for HTML), see Scott Guthrie's post. As Allen mentioned, you should also have the Build Action turned to "None". Unfortunately, this will not stop build errors if you have the file open.
right click > properties
Build Action: set to "None"
Edit: If you're talking about app.config, you really cant mess with the format of that, you need to put it in a different .config file.
I just double checked, VS.net doesnt care as long as its not app.config or web.config and the config file build action is set to "None", it will "error" if you have the file open but it will not cause the build to fail or keep it from building the assemblies.
Close the file and the errors will go away, similar to the errors you get about HTML markup. The displaying of these "errors" is probably a configurable setting in vs.net
The action to take depends on the solution and and file type. For instance (in VS2005), in a C++ solution I can right click on the source file name in the solution explorer and view its properties. The first "General" option is "Excluded From Build", which will allow you to exclude the file from the build process without having it excluded from the project altogether.
I pulled up a .config file in a C# solution, and found a "Build Action" option under the Advanced section. That should probably be set to "None".
Just right click on the file and choose "Exclude from project".
If you still want to see it in your project, select the project and click the "Show all files" button at the top of the solution explorer. This will show all the files in the directory tree even if they aren't actually part of the project.
Are you sure that VS compiling .config file???
You should check it's Build Action in file options and may be set it to none.