Visual Studio drives me crazy and I am suspecting I am doing something wrong.
This is what I do: I installed Visual Studio (Pro '08) a long time ago, I installed the Windows SDK (Win 7 x64), someone emails me a project, it fails to build.
Invariably, it can not find windows.h. While it is easy enough to include C:\Program Files\Microsoft SDKs\Windows\v7.0\Include in the project settings of every single project, I feel that this may not be the proper way to do it. Is there a way to somehow make Visual Studio globally aware of these files?
I also tried to include the above directory in the path variable but that didn't change anything.
Also, it will randomly find windows.h but not winresrc.h in the same directory.
Edit:
It was a problem with my machine. Somehow, Visual Studio thought that my Windows SDK was in the wrong place. See accepted answer and comments for the fix.
#RichieHindle solution is now deprecated as of Visual Studio 2012. As the VS studio prompt now states:
VC++ Directories are now available as a user property sheet that is added by default to all projects.
To set an include path you now must right-click a project and go to:
Properties/VC++ Directories/General/Include Directories
Screenshot:
This answer only applies to ancient versions of Visual Studio - see the more recent answers for modern versions.
You can set Visual Studio's global include path here:
Tools / Options / Projects and Solutions / VC++ Directories / Include files
To resume the working solutions in VisualStudio 2013 and 2015 too:
Add an include-path to the current project only
In Solution Explorer (a palette-window of the VisualStudio-mainwindow), open the shortcut menu for the project and choose Properties, and then in the left pane of the Property Pages dialog box, expand Configuration Properties and select VC++ Directories.
Additional include- or lib-paths are specifyable there.
Its the what Stackunderflow and user1741137 say in the answers above.
Its the what Microsoft explains in MSDN too.
Add an include-path to every new project automatically
Its the question, what Jay Elston is asking in a comment above and what is a very obvious and burning question in my eyes, what seems to be nonanswered here yet.
There exist regular ways to do it in VisualStudio (see CurlyBrace.com), what in my experience are not working properly. In the sense, that it works only once, and thereafter, it is no more expandable and nomore removable.
The approach of Steve Wilkinson in another close related thread of StackOverflow, editing the Microsoft-Factory-XML-file in the ‘program files’ - directory is probably a risky hack, as it isnt expected by Microsoft to meet there something foreign. The effect is potentally unpredictable. Well, I like rather to judge it risky not much, but anyway the best way to make VisualStudio work incomprehensible at least for someone else.
The what is working fine compared to, is the editing the corresponding User-XML-file:
C:\Users\UserName\AppData\Local\Microsoft\MSBuild\v4.0\Microsoft.Cpp.Win32.user.props
or/and
C:\Users\UserName\AppData\Local\Microsoft\MSBuild\v4.0\Microsoft.Cpp.x64.user.props
For example:
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ImportGroup Label="PropertySheets">
</ImportGroup>
<PropertyGroup Label="UserMacros" />
<PropertyGroup>
<IncludePath>C:\any-name\include;$(IncludePath)</IncludePath>
<LibraryPath>C:\any-name\lib;$(LibraryPath)</LibraryPath>
</PropertyGroup>
<ItemDefinitionGroup />
<ItemGroup />
</Project>
Where the directory ‘C:\any-name\include’ will get prepended to the present include-path and the directory ‘C:\any-name\lib’ to the library-path. Here, we can edit it ago in an extending and removing sense and remove it all, removing thewhole content of the tag .
Its the what makes VisualStudio itself, doing it in the regular way what CurlyBrace describes. As said, it isnt editable in the CurlyBrace-way thereafter nomore, but in the XML-editing-way it is.
For more insight, see Brian Tyler#MSDN-Blog 2009, what is admittedly not very fresh, but always the what Microsoft is linking to.
If you are only trying to change the include paths for a project and not for all solutions
then in Visual Studio 2008 do this:
Right-click on the name of the project in the Solution Navigator. From the popup menu select Properties. In the property pages dialog select Configuration Properties->C/C++/General. Click in the text box next to the "Additional Include Files" label and browse for the appropriate directory. Select OK.
What annoys me is that some of the answers to the original question asked do not apply to the version of Visual Studio that was mentioned.
To use Windows SDK successfully you need not only make include files available to your projects but also library files and executables (tools).
To set all these directories you should use WinSDK Configuration Tool.
This answer will be useful for those who use a non-standard IDE (i.e. Qt Creator).
There are at least two non-intrusive ways to pass additional include paths to Visual Studio's cl.exe via environment variables:
Set INCLUDE environment variable to ;-separated list of all include paths. It overrides all includes, inclusive standard library ones. Not recommended.
Set CL environment variable to the following value: /I C:\Lib\VulkanMemoryAllocator\src /I C:\Lib\gli /I C:\Lib\gli\external, where each argument of /I key is additional include path.
I successfully use the last one.
You need to make sure and have the following:
#include <windows.h>
and not this:
#include "windows.h"
If that's not the problem, then check RichieHindle's response.
Related
So I just made some c++ application, using NotificationIcon sample from Microsoft as a reference, and thus I'm stuck with the NotificationIcon.exe output file. The name is really lame and I'd like to change it. I've tried renaming the exe, renaming the solution, the project - whatever else - and my programm just exited with code 0x00 after building. What else should I try?
I tried to do the same thing, but there were a few steps I had to follow in VS2019 just to get set up. If you are not in a similar state, the rest of the answer might not apply.
Downloading the sample: I had to install the Windows 7 SDK, as the download page didn't seem to exist anymore. I'm not sure if you found it elsewhere, in which case you might be starting from different sources.
Converting the .vcproj file to .vcxproj. Visual Studio no longer supports .vcproj, and opening the solution triggered this conversion automatically.
Now, once I have a .vcxproj file, there are two routes to setting the name of the exe:
Right-click the project in VS, click Properties, and find the Target Name field. This defaults to $(ProjectName) so I would have expected that renaming the .vcxproj would have renamed the .exe file.
Edit the .vcxproj file directly, adding <TargetName>Foo</TargetName> into the section that starts with <PropertyGroup Label="Globals">
I just installed Visual Studio Community 2017 for school purposes. My lecturer gave us these instructions to use a GraphicsSDK library with VS (after we have Visual Studio installed). I ran the Tutorial.sln file he gave but I got this error.
I have followed all the steps correctly. I've been looking at other questions on StackOverflow and they said to change the Properties/Output file to $(OutDir)$(TargetName)$(TargetExt) but mine is correct.
I also noticed one line in the code which was underlined red.
/* Render here */
glClear(GL_COLOR_BUFFER_BIT);
It said that GL_COLOR_BUFFER_BIT was undefined. Not sure if this matters at all.
In older versions of Visual Studio the folder settings were part of the IDE. But in version 2017 you specify the search paths in the application itself.
If you go to your projects properties you will see a VC++ Directories section:
You need to make sure that the folders to the libraries and include files are correct (for both debug and release configurations).
Then, when you do a build it will be able to find the definitions it needs. But your question is lacking a lot of information. This is my educated solution for now.
Everything works with Qt in MSVC2013, except one thing: the DLLs are not found, because $(QTDIR) is not defined, when the local debugging environment is set.
My debugging environment settings:
PATH=$(QTDIR)\bin%3b$(PATH)
My .user file:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
<LocalDebuggerEnvironment>PATH=$(QTDIR)\bin%3b$(PATH)</LocalDebuggerEnvironment>
<QTDIR>C:\Qt\Qt5.4.1\5.4\msvc2013</QTDIR>
<DebuggerFlavor>WindowsLocalDebugger</DebuggerFlavor>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
<LocalDebuggerEnvironment>PATH="$(QTDIR)\bin%3b$(PATH)</LocalDebuggerEnvironment>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
<LocalDebuggerEnvironment>PATH=$(QTDIR)\bin%3b"$(QTDIR)\bin%3b$(PATH)</LocalDebuggerEnvironment>
<QTDIR>C:\Qt\Qt5.4.1\5.4\msvc2013</QTDIR>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
<LocalDebuggerEnvironment>PATH="$(QTDIR)\bin%3b$(PATH)</LocalDebuggerEnvironment>
</PropertyGroup>
</Project>
I don't know why, but the $(QTDIR) variable is not available to LocalDebuggerEnvironment.
It works with following debugging environment settings:
PATH=C:\Qt\Qt5.4.1\5.4\msvc2013\bin%3b$(PATH)
Is it possible to make Visual Studio handle this properly or do I have to enter the path manually?
It seems Visual Studio parses the lines from top to bottom, so with your code...
<LocalDebuggerEnvironment>PATH=$(QTDIR)\bin%3b$(PATH)</LocalDebuggerEnvironment>
<QTDIR>C:\Qt\Qt5.4.1\5.4\msvc2013</QTDIR>
...the variable $(QTDIR) is defined in the second line, and is cannot be used in the first line.
Simply switch the order so that the variable is defined before it is used:
<QTDIR>C:\Qt\Qt5.4.1\5.4\msvc2013</QTDIR>
<LocalDebuggerEnvironment>PATH=$(QTDIR)\bin%3b$(PATH)</LocalDebuggerEnvironment>
Note: Visual Studio only reads the .user file at startup, so you need to (re-)start Visual Studio after editing the file.
Thank you for your discussion of this issue. I can report that it still is extant in Qt 5.8 / QT Extension for Windows Version 2.1.1 / Visual Studio 2015. The symptoms are that entering "$(QTDIR)\bin" (the location of the Qt DLLs) as a PATH folder spec in the VStudio Project property Debugger...Environment appears to work, but actually does not.
By "appears to work" I mean that if you click on the option to examine the Debugger Environment property, and the raw form of the Environment property looks like "PATH=$(QTDIR)\bin;...;$(PATH)" the VStudio editing dialog box will helpfully inform you that that PATH string evaluates to (e.g.) "PATH=D:\TechApps\Qt\5.8\msvc2015_64b\bin;..."--just as it should if the QTDIR macro was really present and had the correct value. This is cruelly deceptive!
Because, by "really doesn't work" I mean that the PATH as actually prepared for use when launching your Qt-dependent application from within VStudio doesn't see this macro. Your beautiful PATH string is reduced to "\bin;...". You can confirm this by temporarily copying your Qt DLLs from $(QTDIR)\bin into the folder of your application executable. Your application will launch correctly. And if you examine your PATH from within your program (using e.g. getenv("PATH") in c++, you will see that your program's PATH string is missing QTDIR. (That is, it is what it would be if QTDIR were the empty string.)
FWIW, another symptom of this problem is that if you examine the VStudio list of macros, $(QTDIR) is not in the list.
The solution described above (rearranging the elements in ...vcxproj.user) appears to solve the problem. When you move the definition(s) of QTDIR earlier in that file, the PATH string actually available to the application is correct, and $(QTDIR) is present in the list of macros known to Visual Studio.
HOWEVER, I don't know whether changing the "Qt VS Tools" options, or the "Qt Project Settings," in VStudio causes the .user file to be incorrectly overwritten again.
Changing (or re-selecting) the Qt Version in the solution (Change Solutions Qt Version) fixed the issue for me.
It took many seconds to re-initialize the projects and even then I don't believe the .user file updated until I did a build of the project.
I'm rather unfamiliar with programming tools in Windows but have been forced to use VC++ 2010 Express for a project recently. We have been working on a piece of software that we didn't start and now we are reaching the finish line. Only problem is that I want to be able to set the executable icon.
Since the project is written mostly in SDL we have set the titlebar icon using the SDL_WM_SetIcon call as recommende on several sites but I still can't find any references to how to set the executable icon. All my google searches has turned up results about Visual Studio 2010 and Visual C++ 2008, neither of which seems appicable.
Since VC++ 2010 Express lacks resource editor but not resource compiler this can be done by manually creating a resource.rc file in the project directory (same as where your .vcxproj files are located), also drop in your .ico version of your icon in the same directory.
In resource.rc add the following line:
IDI_APP ICON "icon.ico"
And add the file, in VC++, to the Resource Files.
Doing this in VC++ should result in something like this to be added to your .vcxproj:
<ItemGroup>
<ResourceCompile Include="resource.rc" />
</ItemGroup>
And to your vcxproj.filters:
<ItemGroup>
<ResourceCompile Include="resource.rc">
<Filter>Resource Files</Filter>
</ResourceCompile>
</ItemGroup>
I ran into a similar situation recently with the Express edition.
I came up with a different way to approach this (see gif).
Posting it here in case someone runs into similar problem.
I've been using C/lex for a long time and would like to use F#/fslex now.
I'm comparably well off in C# and in the process of learning F#.
The only thing is that I can't see any project example or template where fslex is properly included in the Visual Studio build process.
Does anyone know where I can find one?
Lots of Greetings!
Volker
Unfortunately, there is no built-in item template for .fsl files, because FsLex is a part of PowerPack (so Visual Studio cannot expect that it will be installed). It would be definitely useful to have some template that could be installed with PowerPack!
Anyway, if you're looking for a sample project that uses FsLex (and has .fsl files as part of the project), then you can take a look at the F# source code (distribtued with the Visual Studio 2008 MSI/ZIP package). The project that contains .fsl is FSharp.Compiler.fsproj and on my installation, it can be found in C:\Programs Files\FSharp-1.9.9.9\source\fsharp\FSharp.Compiler. Surprisingly, it includes a lexer for the F# language itself :-).
To add FsLex item to the MSBUILD project (which is also Visual Studio project), it uses the following:
<FsLex Include="..\lex.fsl">
<OtherFlags>--lexlib Internal.Utilities.Text.Lexing</OtherFlags>
<Link>lex.fsl</Link>
</FsLex>
<Compile Include="lex.fs" />
In case you also needed FsYacc, here is an example (also from FSharp.Compiler.fsproj):
<FsYacc Include="..\pars.fsy">
<Module>Microsoft.FSharp.Compiler.Parser</Module>
<Open>Microsoft.FSharp.Compiler</Open>
<OtherFlags>--internal --lexlib Internal.Utilities.Text.Lexing
--parslib Internal.Utilities.Text.Parsing</OtherFlags>
<Link>pars.fsy</Link>
</FsYacc>
<Compile Include="pars.fs" />
Note that you need the FsYacc/FsLex command to invoke the custom tool, but also the Compile command which tells the compiler to include the produced fs file when building the project.
I'm using the free VS Shell until I finally threaten myself enough to finally buy the full VS, and unless I'm doing something wrong, (and I probably am) none of the normal solutions seem to work for me. What I do is add the following pre-build events to the project properties:
"C:\Program Files (x86)\FSharpPowerPack-2.0.0.0\bin\fslex.exe" "$(ProjectDir)\Lexer.fsl"
"C:\Program Files (x86)\FSharpPowerPack-2.0.0.0\bin\fsyacc.exe" "$(ProjectDir)\Parser.fsy" --module Parser
That seems to work well enough for me. Errors all go to the output window. If you're on a 32-bit machine, you would remove the (x86) from those paths.
Doing a little research it looks like they need to be separate. I found the following at this blog post ( http://blogs.msdn.com/chrsmith/archive/2008/01/18/fslex-Sample.aspx ) by Chris Smith:
Although you can add an F# Lex Specification file from the Visual Studio Add-In, to run fslex you will need to break to the command line. Fslex.exe is located in your F# distribution’s ‘bin’ directory.
Hope that helps.