Visual Studio Cross-Platform CMake - Includes aren't picked up, intellisense is upset about it - c++

I have a C++ project set up something like this:
Linux box:
/home/me/.vs/SomeBigProjectDir
/opt/DependencyOne
/opt/DependencyTwo
Windows:
Local copy of the source
I've set up the cross-platform connection in Visual Studio, and am able to trigger builds on the remote host no problem. However, Intellisense gets upset about #includes - it claims that it can't find any of the included files specified.
Visual Studio has been told to invoke CMake with -DDependencyOne=/opt/DependencyOne and -DDependencyTwo=/opt/DependencyTwo. It's a bit yucky, but we're halfway through migrating off of autotools (these were previously in a configure script), and I don't see how they'd interfere with this. Having these more cleanly packed into some CMake file is an upcoming task.
Sample CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(3.14)
PROJECT(MyProject)
include_directories(${CMAKE_SOURCE_DIR})
if (DependencyOne)
include_directories(${DependencyOne}/include)
endif()
if (DependencyTwo)
include_directories(${DependencyTwo}/include)
endif()
#blah
add_subdirectory(SubDirOne)
add_subdirectory(SubDirTwo)
#etc
#various targets are declared in subdirectories
The project itself contains many targets, most of which has a dependency on DependencyOne.
If I run a build, Visual Studio happily rsyncs across any file changes, triggers the build on the remote, and it completes without issue. In addition, it has copied back all of the includes to local (on Windows), where they live in \AppData\Local\Microsoft\Linux\HeaderCache\1.0<some numbers>\opt\DependencyOne, for example. So, it clearly knows about them as includes.
Intellisense does not seem to want to believe that these files exist, and I can not find where to tell it to look to find them. Having red squiggles on tons of code that uses these dependencies is just unhelpful, and there is no way to F12 into the header file.
I've tried adding the remote include directories to the remoteCopyAdditionalIncludeDirectories within CMakeSettings.json on Visual Studio to no avail.
I've also tried looking around the internet, but Microsoft helpfully called Visual Studio and Visual Studio Code very similar names, and it's tough to find results specifically for Visual Studio that relate to this type of problem.
Other maybe-relevant information:
Visual Studio 2019 16.9.2
CMake 3.14.6
Red Hat Enterprise Linux 7
Edit:
I re-read through this and thought I could add a little more detail.
To my understanding, in CMake, using include_directories will result in compilers being happy with the following:
include_directories(/opt/dependency/include)
for:
opt
-dependency
--include
---Dep
----SomeHeader.h
----AnotherHeader.h
#include <Dep/SomeHeader.h> //works anywhere that the include_directories() statement applied
In this case, there is that above-mentioned directory living in AppData. The root of the issue is that intellisense doesn't have the sense to look in that directory, despite the project "knowing" that includes are there (it copied the headers over). Because this is a CMake project, there is no CppProperties.json to edit to manually add the paths, at least, not one that I have found.
Edit:
This appears to be a repeat of a bug reported here: https://developercommunity.visualstudio.com/t/Intellisense-in-CMake-setup-does-not-rea/957818. I was quick to judge all headers as causing intellisense to fail - it is only those that have a '.' character in their path. I have reported this to Microsoft.

Related

Compiling Qt projects in Qt/MsBuild format without Qt VS Tools installed

I have many Qt projects in Visual Studio, using the new Qt/MsBuild format provided by the Qt VS Tools. When compiling in my development environment, where I have the Qt VS Tools installed, everything works flawlessly (compiling from IDE and from command line).
We have a computer dedicated to nightly builds, where only the compiler and msbuild are available (no IDE nor Qt VS Tools are installed).
When compiling the projects in such computer we get an error:
QtMsBuild: could not locate qt.targets, qt.props; project may not build correctly.
Followed by several lines such as
e:********\Preferences.h(4): fatal error C1083: Cannot open include file: 'ui_Preferences.h': No such file or directory
(Project contains Preferences.ui).
How can I solve such errors when Qt VS Tools are not installed?
One solution provided by the Tools' creators is to copy %LOCALAPPDATA%\QtMsBuild into each project directory. But we are talking about hundred of projects. Doing manually, and more on, pushing them as part of the project itself doesn't sound very elegant.
One option would be to add a pre-build step that copies it from a common place into each project (and adding a **/QtMsBuild line to each .gitignore file). Again, looks like too much work.
When looking at the .vcxproj file for the Qt project you find this fragment (the reason for the solution provided by creators):
<PropertyGroup Condition="'$(QtMsBuild)'=='' or !Exists('$(QtMsBuild)\qt.targets')">
<QtMsBuild>$(MSBuildProjectDirectory)\QtMsBuild</QtMsBuild>
</PropertyGroup>
So, the simplest solution (without being able to install the tools), is to copy the %LOCALAPPDATA\QtMsBuild directory (from a system with the Tools installed) into the night computer (in any common place, but I decided to keep the location used by the tools) and then setting an environment variable:
set QtMsBuild=%LOCALAPPDATA%\QtMsBuild
PS: do not add double quotes to the variable (at least I had problems with them, so VS couldn't find the files).
Update 9-14-2020
I'm not sure on which version it started, but Qt projects created with (at least) the v2.5.2 Qt VS Tools fails to compile indicating that the Qt version has not been set. To solve so, you can
Copy the Registry entries from a computer with tools installed, located at HKCU\SOFTWARE\Digia\Versions.
If you will rely on a single Qt version (but that may be update globally for all projects), you can skip the Registry and just set the Qt version of all projects to $(DefaultQtVersion) (the same used in past project formats) and define an environment variable pointing to the directory of the version: set DefaultQtVersion=c:\Qt\Qt_5_15_0\Win32, for example.
I had problems in my case setting up $Env:QtToolsPath="$Env:QT_PATH\bin" fixed the problem. (It was not finding qmake for some checks). This, I think, is required when using QtMsBuild v3.3
Not sure if this info is 100% correct but may help someone.
For me to use MsBuild with Qt using QtMsBuild (not installing Visual Studio and/or VS plugins), I need to set up:
Example (PowerShell):
- $Env:PATH="$Env:MSBUILD_PATH;$Env:PATH"
- $Env:QT_PATH="D:\BuildTools\Qt\5.15.1\msvc2019_64"
- $Env:QtMsBuild="D:\BuildTools\Qt\QtMsBuild303" #303 Against visual studio project version
- $Env:QtToolsPath="$Env:QT_PATH\bin" #Support QtMSBuild , At desktop is done by the plug in
- $Env:PATH="$Env:QtMsBuild;$Env:PATH"
- $Env:PATH="$Env:QT_PATH\bin;$Env:PATH"
I hit this and got it working.
I followed #cbuchart 's advice; but needed to do a little more/different.
So here is what I did. I copied %LOCALAPPDATA%\QtMsBuild to my repo. I then edited my .vcxproj with a text editor. I adjusted the line that looks like:
<QtMsBuild Condition="'$(QtMsBuild)'=='' OR !Exists('$(QtMsBuild)\qt.targets')">$(MSBuildProjectDirectory)\QtMsBuild</QtMsBuild>
To be:
<QtMsBuild Condition="'$(QtMsBuild)'=='' OR !Exists('$(QtMsBuild)\qt.targets')">$(MSBuildProjectDirectory)\..\QtMsBuild</QtMsBuild>
Depending on the relative location of where your project(s) are to the copied QtMsBuild directory you might want to adjust this. In my case the .vcxproj was in a directory one level from the directory that contains the QtMsBuild directory I copied.
Next in the QtMsBuild/Qt.props file I added the following:
<PropertyGroup>
<DefaultQtVersion>$(MSBuildThisFileDirectory)\..\Qt5.15.0\msvc2019_64</DefaultQtVersion>
<QtToolsPath>$(DefaultQtVersion)\bin</QtToolsPath>
</PropertyGroup>
That was added right after the opening Project tag in that file.
This was as #cbuchart mentioned something might have changed. I didn't do the Registry idea; but added those lines instead. I think it is possible to add them to a different file that gets imported before Qt.props if desired.
Now as for what this "Qt5.15.0\msvc2019_64" is; you'll need the tools, includes, libraries from a computer with Qt installed in order to build (also DLLs if your build needs to run the executable (i.e. tests)). This might be a lot of files so you can reduce it some if you know what you are doing. It might make sense to have these be put into it's own submodule or something.
After that it should uic/moc files and ultimately build (and run).
I got too. Maybe you need update your visual studio and then restart your computer ...
problem solved. reason: install 'qt vs tools' latest version but the visual studio
not support of it.

Install pdcurses on Visual Studio 2017

I was making a 2048 game on Code::Blocks, but due to debugging problems, I move to Visual Studio Community 2017. It seems that conio.h doesn't work there, so I'm trying to switch to curses.h library.
I've read a lot of tutorials, but none of them worked for me. I visited their website and downloaded the .zip file with 384 kilobytes (KB), but I do not know what to do with these files.
Help, please?
I have found a very useful website which talks about PDCurses and its installation in Visual Studio. Even though it is for 2010/2013, it really worked for me in VS2017 — even the demo programs (with very minute changes)!
So here is the steps I did (since you already have PDCurses):
Take the developer command prompt of VS2017 community edition and type
in set PDCURSES_SRCDIR=<PDCurses Directory Location>; in my case it
was
set PDCURSES_SRCDIR=C:\pdcurses-master
Note: Here we are setting up the environment variable needed for compilation. If you need additional functionality defined by the pdcurses library, you may want to set corresponding variables in this step. For example, if you need wide character support, you can use set WIDE=1. To see what all are the options available, you can open up the make file (mentioned in next step) in any text editor and look for if conditionals.
Navigate in the command window to the directory of PDCurses/win32 (in my case C:\pdcurses-master\win32)
nmake –f vcwin32.mak
(This is the make file for PDCurses.) It will create the pdcurses.lib for our Visual Studio.
Now we need to incorporate the generated library into our project. So open up your project and go to project properties
In “VC++ Directories”, change:
Include directories: Add a new file-path to PDCurses installation directory, in my case it is C:\pdcurses-master.
Library directories: Add a new file-path to PDCurses installation library directory, in my case it is C:\pdcurses-master\win32.
In C/C++:
In “Code Generation” tab, change “Runtime Library” to “Multithreaded Debug (/MTd)”. (Usually, it is set already)
In Linker:
In “Input” tab, add pdcurses.lib to Additional Dependencies (I initially got confused - remember, it is the input tab of linker)
Click on Apply, and OK.
Then wow! I ran some sample programs (demos) from the pdcurses project and all of them worked for me with very slight modifications.
Note: I created a Windows (also known as Win32, as in Win32 API) console application with Visual Studio 2017 and loaded the project. I did include stdafx.h and compilation was successful and I was able to see the output in the terminal window.
The above website also provides a PDF document too. The instruction there starts from the downloading the pdcurses from website.
This is old news now, but it might help somebody to know that pdcurses is packaged up on vcpkg.
To use it, (assuming you have vcpkg installed, of course, (Installing vcpkg) )
vcpkg install pdcurses
and you're off to the races. vcpkg will take care of making sure the include and library paths are all set.

Linking libpqxx from Visual Studio 2015 on Windows 10

I've recently decided to try out PostgreSQL as the database platform for some C++ development I'm working on. I decided to use libpqxx as the connection library for my project, and quickly found out this would be an uphill battle to do from VS 2015 on a Windows 10 machine.
After much teeth-gnashing and nail-biting, I have gotten libpqxx to compile on Windows 10.
This leaves me with the following directory structure
Per libpqxx's documentation, I also placed a copy of libpq.dll in my project's executable directory. Please note: I have done this for both debug and release builds, tried to build both, and ended up with the same result.
All the tutorials I've seen seem to indicate that the library can be used after linking it and simply #including pqxx/pqxx, so I set up a small project to do just that. I receive the error:
fatal error C1083: Cannot open include file: 'pqxx/pqxx': No such file or directory
When attempting to build the project. I have also tried this will both debug and release builds, to no avail.
Here is a screenshot of my linker settings.
Does anyone have any suggestions for how I might be able to link and use this library from Visual Studio 2015?
As Sami Kuhmonen pointed out, this was not actually a linker error, but a compiler error. I needed to include an actual header, which Visual Studio needed to be able to find. After adding the correct folder (C:\libpqxx\include in my case) to Visual Studio's "additional include directories" setting under C\C++ -> General per drescherjm's suggestion, the program compiles just fine.
For future reference:
I did also run into unresolved external linker errors after solving the initial issue. This is because you need to make sure to also link to ws2_32.lib and libpq.lib. You also need to copy some other DLL files that libpq also relies on into your libpqxx lib folder. On my system, I believe these were ssleay32.dll, libeay32.dll, and libintl-8.dll. These files reside under the root of the PostgreSQL install. The DLL step is mentioned under libpqxx's INSTALL.txt file, however I believe it stated that the DLLs resided one folder under where I actually found them.
I have also faced same issue. Then I realized that I was building ,my application as a 32bit. I changed the target to x64 and it compiled successfully

Visual studio 2015 gives me errors upon creating a simple test console program

Here is the code I am using.
#include "stdafx.h"
#include <iostream>
int main() {
std::cout << "hi";
return 0;
}
When I create simple c++ console application and try to build it, this error occurs:
cannot open include file 'stdio.h': No such file or directory
Why? Shouldn't stdio.h be included as a standard library? What can I do to get it back?
edit: I have just looked into C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include directory. There is no stdio.h or stdafx.h . I really am not sure why. How can I get them back?
That's because Visual studio changed the path to C headers.
There you have the info about that: https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/
What i did to solve this is:
Go to Project->Properties->. In Configuraton Properties->VC++ Diretories->Library Directories add a path to C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10150.0\ucrt\(Choose your architecture)
And in C/C++->General->Additional include directories add a path to:
C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt
Note: The 10.0.10150.0 may vary depending on your version.
I had a similar problem upgrading an existing C project from Visual Studio 2013 to VS2017 (I'd skipped VS2015); none of the standard headers were found there either.
The accepted answer (by Cezar Azevedo de Faveri) did work for me, but it's inelegant to just jam an absolute path in the settings, especially considering someone can change the install path of both Visual Studio and the SDKs; I'd like to write code that "just works" where possible.
So I spent a little time studying how VS2017 generates a new project, and I eventually found an answer, which is that when VS2017 upgrades an existing C project, it forgets to upgrade one critical project value, and that incorrect value — the Windows SDK Version — makes the headers unable to be found:
By default, VS2017 installs the headers only for the Windows 10 UWP SDK, but it doesn't change the "Windows SDK Version" in any projects it upgrades to a version of the SDK that was actually installed! Mine were set to "8.1" after the upgrade, and there are no headers installed for Windows 8.1
So if you're upgrading an existing project, you'll have to change this setting manually to whichever version of the headers you actually have: In my case, that was by explicitly adding 10.0.14393.0 to the list (that's the version number for the Windows 10 UWP SDK headers that come with VS2017).
(The list of installed versions can be found in the C:\Program Files (x86)\Windows Kits\10\Include folder, and in the similar folders near it.)
I know I am a bit late to this but instead of messing with the path settings, in Visual Studio 2017 you can
right-click the project
select retarget projects
select the latest or any new version of windows SDK and click OK
This will automatically take care of all include paths and libraries.
#include "stdafx.h"
There is a well-known difference between the <...> and "..." includes: briefly, that the former is for library includes and the latter is for local includes.
You mention that you were looking around for stdafx.h but couldn't find it in the compiler installation. This suggests that:
You think stdafx.h is a library file (it is not, unless it's some MS-specific extension, which I doubt, although it is traditionally used as a default filename for precompiled headers by the same--if you have made one, which you almost certainly haven't).
Because of 1., you haven't made a local file stdafx.h, and therefore this include directive should fail. If it hasn't, then something fishy is happening.
As to your actual problem, I have some notes:
<stdio.h> is the C header, not the C++ one. If you're including from a C++ file (extension .cpp, probably, for MSVC), then you should use the C++ header <cstdio>. However, this shouldn't actually cause the problem.
You aren't using the stdio anyway (at least not directly). You're using iostream, which you're properly including. If that include is the one that's causing the error, then iostream is trying to include it, can't, and your compiler installation is borked.
Try the similar program:
#include <iostream>
int main() {
std::cout << "hi" << std::endl;
return 0;
}
I have just checked myself that this compiles and executes properly under Visual Studio 2015 Professional.
If this program does not compile, I suggest reinstalling Visual Studio. In my experience, this often fixes these tricky setup issues.
I faced the same issue , it got resolved when I ran vcvarsall.bat which is present at C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
Above there is provided solution is per project.
But if you don't want to reinstall VS from scratch or set the include directories and libraries on every solution you can modify Toolset.props found in:
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\Win32\PlatformToolsets\v140\Toolset.props
<PropertyGroup>
....................
<IncludePath Condition="'$(IncludePath)' == ''">$(VC_IncludePath);$(WindowsSDK_IncludePath);**C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt**</IncludePath>
.......................
<LibraryPath Condition="'$(LibraryPath)' == ''">$(VC_LibraryPath_x86);$(WindowsSDK_LibraryPath_x86);$(NETFXKitsDir)Lib\um\x86;**C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10150.0\ucrt\**</LibraryPath>
...........................
</PropertyGroup>
I had this error on VS2017 after upgrading from VS2015. I tried a clean + reinstall and it did not fix the error. The problem that I found was two-fold:
$(VC_IncludePath);$(WindowsSDK_IncludePath); was not in the default include path.
$(VC_IncludePath);$(WindowsSDK_IncludePath); was actually EXCLUDED in the default properties (how did this happen?!)
To fix for new projects:
Manually edit the following files:
%LOCALAPPDATA%\Microsoft\MSBuild\v4.0\Microsoft.Cpp.Win32.user.props
%LOCALAPPDATA%\Microsoft\MSBuild\v4.0\Microsoft.Cpp.x64.user.props
Make sure that $(VC_IncludePath);$(WindowsSDK_IncludePath); is in the IncludePath and NOT in the ExcludePath.
To fix for old projects (that don't just inherit from the above files):
Manually edit your project properties in the Solution Explorer and make sure that $(VC_IncludePath);$(WindowsSDK_IncludePath); is in the IncludePath and NOT in the ExcludePath.
I had the same problem in Visual Studio Community 2015 after installing the current Windows SDK and as Signa already wrote earlier, this can be fixed for all projects within a "Toolset.props" file (at least for VS2015) and I find this to be the most convenient solution, because this has to be done only once. I've got a few side notes, because there is something to watch out for.
For each build platform there is an own "Toolset.props" file, so both need to be modified if you want to build for 32 and 64 bit targets:
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\Win32\PlatformToolsets\v140\Toolset.props
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\x64\PlatformToolsets\v140\Toolset.props
The files are write-protected and you need to remove the write protection before you can change those files (remember to put it back on after you're done).
As of now the current SDK version is "10.0.15063.0" and you need to adjust that to the version you want to use (or to the SDK version you have installed).
Look out for the IncludePath and LibraryPath lines in those props files and add the following paths to them:
IncludePath: $(ProgramFiles)\Windows Kits\10\Include\10.0.15063.0\ucrt
LibraryPath: $(ProgramFiles)\Windows Kits\10\Lib\10.0.15063.0\ucrt\$(PlatformTarget)
Here a sample how this looks like for the 32 bit version:
// ... some XML before that ...
<PropertyGroup>
// ... executable path .....
<IncludePath Condition="'$(IncludePath)' == ''">$(VC_IncludePath);$(WindowsSDK_IncludePath);$(ProgramFiles)\Windows Kits\10\Include\10.0.15063.0\ucrt;</IncludePath>
// ... reference path ...
<LibraryPath Condition="'$(LibraryPath)' == ''">$(VC_LibraryPath_x86);$(WindowsSDK_LibraryPath_x86);$(NETFXKitsDir)Lib\um\x86;$(ProgramFiles)\Windows Kits\10\Lib\10.0.15063.0\ucrt\$(PlatformTarget);</LibraryPath>
// ... more XML ...
</PropertyGroup>
// ... even more XML ....
After running in similar problems once more with VS2017 I took a closer look at what caused all this. And the main reason was that I was still using modified user.props files. Which was for a while a solution to add global include and library paths to all projects. But this feature is deprecated by Microsoft and the content of those files should be reset.
The files I'm talking about are the user.props files in C:\Users\your_name\AppData\Local\Microsoft\MSBuild\v4.0
For testing you can simply rename (or delete if you like risks) them and restart VS. It will create empty files for those now. And if you are on Windows 10 then in most cases this is already enough to fix all your problems. Even in older VS versions (I tested with VS2010-VS2017, for even older VS versions the troubles tend to involve registry keys and don't involve this props files). Windows/VS has become now really good at finding all the system libraries (including DirectX which was the main reason we had to modify those files in the past) and adding them in the correct include order.
Also a warning as I've seen other people recomment that. Do not change any .prop installed by the SDK. If you really need to work with props then create and add your own property sheets (which can overwrite any defaults) to your project. And don't worry, those will not be checked in to source-control so you can still distribute your project to others.
If you are still on an older Windows it might not be as easy as in Windows 10, but I'll try to give some hints:
What you are missing for that concrete error is the new $UniversalCRT_IncludePath. No need to hardcode that path, that macro should contain the correct one. So add $(UniversalCRT_IncludePath); to the IncludePath in your own property which you add then to the project.
And for LibraryPath add the correct path per platform-file, like $(UniversalCRT_LibraryPath_x64); for .x64. and $(UniversalCRT_LibraryPath_x86); for .Win32.
What also might be useful when trying to fix this: You can find out the values of all the $(MACRO) variables used in the build system inside VisualStudio. They are just very well hidden: Go in properties - custom build steps - click on command line - then don't type anything but click the down button to get "edit..." - you click that - you get a dialog which has a "Macros>>" button. And that contains a list with all macro values.
Installing Visual Studio 2015 Update 3 solves this issue, both for new projects and for existing projects created before the update.
https://www.visualstudio.com/news/releasenotes/vs2015-update3-vs

Using fuzzylite in Visual Studio 2010

Has anyone done this before ? I am not able to get it to work.
Following are my steps:
Download the windows package from link
I can run qfuzzylite (gui-tool) without any problem. Now I want to use the fuzzylite lib in my Visual Studio + Qt Integration Project.
In the CMake GUI I give fuzzylite source folder as the input folder and select Visual Studio 2010 as the compiler.
I am able to generate the Visual Studio fuzzylite solution in CMake without any errors.
Then, I tried to build the Visual Studio solution, but it fails with some weird errors. However, it does generate the fuzzylite-dbg.lib file (which I need).
Then I use this lib file and the fuzzylite.dll and include the path to the Headers in the VS Project. The project builds without any errors.
Now in the code I am doing
fl::Engine* engine = new fl::Engine("simple-dimmer");
This fails with the following exception:
exception text: bad allocation
exception type: class std::bad_alloc
Thank you for your detailed steps, but the solution seems to be a bit random (or weird as you put it). Unless more information is provided about the error, I strongly discourage the use of such a solution to attempt any fix to fuzzylite.
If you are running into problems, I strongly encourage you to report the problem in the forums at http://www.fuzzylite.com, where I and others will be very happy to help you.
As for the compiling errors, fuzzylite treats warnings as errors. A warning that is being raised in fuzzylite 4.0 when compiled using Visual Studio (not from console via nmake), and potentially in previous versions, is warning C4702, which refers to unreachable code. You can fix this by adding in file fl/fuzzylite.h the following line within the #ifdef FL_WINDOWS (together other #pragmas):
#pragma warning(disable:4702) //Ignore unreachable code
If the library was not built correctly, errors are bound to happen during runtime.
Ok, got it :)
Here are the steps for future reference:
Download the windows package from link
In the CMake GUI I give fuzzylite source folder as the input folder and select Visual Studio 2010 as the compiler. Now, if you want to use the lib in Debug mode tick the FL_DEBUG box (this is where I went wrong)
Now on clicking "generate", it will generate 5 projects:
ALL_BUILD
fl-bin
fl-shared
fl-static
INSTALL
ZERO_CHECK
Now in the Project properties in fl-bin, shared and static go to the Project Properties. In C/C++ go to Preprocessor get rid of the space in FL_DATA="mm.dd.yyyy " to "mm.dd.yyyy" (weird).
The solution should build fine and will generate fuzzylite-dbg.dll and fuzzylite-dbg.lib in the lib folder.
Use these files in your VC Project by adding the fuzzy-dbg.lib as the linker input and place the dll in the solution folder. Give the path "path\to\fuzzylite\fuzzylite." to the Include Directories.
Do the same process for Release mode (don't tick the FL_DEBUG flag)