I am trying to get custom effects in Direct2D working in my c++ project which is included in an c#/XAML solution. I have been trying to adapt the CustomPixelShader project from the D2DCustomEffects solution from the Windows-universal-samples git repo.
My problem (I think) is that they are configuring a Custom build step in the project solution to get fxc to compile the shader. When I have tried to mimic their configuration, I have noticed that in my project property pages I have an additional property - HLSL compiler - that is not present in the CustomPixelShader example project (see image).
When I try to build the project without trying to configure HLSL Compiler, I get the error
Error X1507 failed to open source file: 'd2d1effecthelpers.hlsli'
which is a file that is clearly indicated in the custom effects example as important for the shader compilation. The path to d2d1effecthelpers.hlsli is included in the Custom build step config and I have checked that the file is there. However, if I add the path to d2d1effecthelpers.hlsli to Additional include directories in the HLSL Compiler config, that error message disappears but I get other problems instead. I’m interpreting this as if the HLSL compiler tries to compile the shader, even though I really want to use a Custom build step to do that instead.
My questions are: is it possible to disable the Visual Studio HLSL compiler in any way? I have noticed that if I exclude any shader files from the project the HLSL compiler disappears from the project property page, but how to do that manually?
Alternatively, is there any documentation on the Visual Studio built-in HLSL Compiler anywhere? I haven't really found any. I have tried but failed to get the HLSL Compiler to build according to the same rules as the Custom build step from the example.
I’m using Visual Studio Community 2017 v 15.3.5.
The first thing is that Visual Studio HLSL compiler is actually fxc. If you want to compile your shader manually as a part of Custom build step then you can disable hlsl compilation performing the following steps: right click on .hlsl file in Solution Explorer; select "Properties" in context menu; change Configuration Properties -> General -> Item Type entry from HLSL compiler to Text or Does not participate in build;
I got the answer in another forum (link to answer).
Summary: right click on the .hlsl-file in the solution explorer in Visual Studio. That will result in showing the properties for that file. Under Configuration Properties -> General you can change Item Type to something other than "HLSL Compiler". Changing it to "Text" worked for me, "Does not participate in build" was suggested in the answer in the other forum. If that does not do the trick, changing the value for Exclude from build to "No" could work. For me, just changing the Item type of the .hlsl-file was enough.
This should result in the HLSL Compiler disappearing from the project property pages (see the image in the question), and the HLSL Compiler will not try to compile the .hlsl-file.
Related
I read this tutorial to try to set up Vulkan in Visual Studio. I got to the very end, compiled, and got this:
A few more screenshots:
I'm using version 1.1.114.0 while the tutorial is using 1.1.77.0, which may be at the root of the issue. However, I have not been able to find another tutorial showing how to set Vulkan up like this. How do I get Vulkan to work in Visual Studio?
I believe you must have missed a step in the tutorial. Specifically, look for the text
Next, open the editor for library directories under Linker -> General
in the linked tutorial page.
In the linker Input tab, either use a complete path to the Vulkan library (for example C:\VulkanSDK\1.1.101.0\Lib\vulkan-1.lib) or in the General tab, add the location of the library (for example C:\VulkanSDK\1.1.101.0\Lib to the Additional Library Directories entry).
If you can express the values in terms of an environment variable, then you'd want to use either VULKAN_SDK or VK_SDK_PATH, which in the above examples would resolve to C:\VulkanSDK\1.1.101.0. That way when you update your Vulkan SDK you don't need to update your project files, and they'll work on other machines that might have different versions installed.
In the long run I'd recommend switching to CMake for project generation, rather than maintaining Visual Studio project files directly. With CMake, adding a Vulkan dependency to your application is as easy as doing this:
find_package(Vulkan REQUIRED)
target_link_libraries(MyApp Vulkan::Vulkan)
You can find existing CMake-based Vulkan examples here or here.
I'm having difficulties trying to compile an opensource framework (EmulationStation) in VS2015 on Windows. I've never used any of the tools before, apart from Visual Studio - so please forgive me if these are some obvious mistakes.
The guide says i need to do like this:
Boost (you'll need to compile yourself or get the pre-compiled binaries)
Eigen3 (header-only library)
FreeImage
FreeType2 (you'll need to compile)
SDL2
cURL (you'll need to compile or get the pre-compiled DLL version)
(Remember to copy necessary .DLLs into the same folder as the executable: probably FreeImage.dll, freetype6.dll, SDL2.dll, libcurl.dll, and zlib1.dll. Exact list depends on if you built your libraries in "static" mode or not.)
CMake (this is used for generating the Visual Studio project)
(If you don't know how to use CMake, here are some hints: run cmake-gui and point it at your EmulationStation folder. Point the "build" directory somewhere - I use EmulationStation/build. Click configure, choose "Visual Studio [year] Project", fill in red fields as they appear and keep clicking Configure (you may need to check "Advanced"), then click Generate.)
This is how my CMake looks like (it says generating done)
I get alot of compilation errors in visual studio when trying to build though:
1) Cannot open include file: 'curl/curl.h': No such file or directory (compiling source file C:\Users\retropie\Documents\GitHub\EmulationStation\es-app\src\guis\GuiMetaDataEd.cpp) emulationstation C:\Users\retropie\Documents\GitHub\EmulationStation\es-core\src\HttpReq.h
Where do I get this header file from?
2) 'round': redefinition; different exception specifications (compiling source file C:\Users\retropie\Documents\GitHub\EmulationStation\es-app\src\guis\GuiMenu.cpp) emulationstation C:\Users\retropie\Documents\GitHub\EmulationStation\es-core\src\Util.h 18
I have a lot of these errors with round. Am I missing a reference to a library?
Another screendump of some of the errors from VS2015:
Hope someone can point me in the right direction.
I am currently in de same boat as you, trying to get ES building under MSVS2015.
I am also very green, so hopefully others chime in as well.
Regarding the 'round' errors, apparently the MS compiler has no knowledge of these. For this issue, and some others, the newer ES fork by Herdinger has fixed this.
As this is currently the most active ES branch out there, and has the explicit goal of consolidating at least some of the backlog of PRs from the original Aloshi git, I would suggest you use this one.
In issue #4, there is some more information on building in recent VS versions. There is also a link for the precompiled cURL libs, including the header.
Having gone that far, I am sad to say that I still do not have a succesfull build as of yet. Compiling is no problem, however linking gives me a LNK2005 error.
Hope this helps a bit. Let me know how you fare.
I'm working on a C++ project (VS 2010) using CPLEX.
I have included the required cplex libraries in the project settings as follows:
added the "additional include directories" under C/C++ > general
added the "additional library directories" under linker > general
added the .lib files as "additional dependecies" under linker > input
Everything compiles fine, however my problem is that intellisense still reports errors (red squiggly underlines) such as "cannot open source file" in the #include line, and "identifier undefined" when using variable types defined in the CPLEX library.
The only difference with other projects that don't have this behaviour is that this time I have used windows environment variables in setting the include path, i.e. the library directories and include directories are defined similar to: %CPLEX_STUDIO_DIR%\cplex\include
I have set it like this so that I can build this project on different machines without messing around in the project properties. Since CPLEX is installed separately, using relative paths to specify additional directories is not really an option.
I'd like to repeat that the project compiles, it's only the intellisense errors that are bothering me.
I know I can turn off the intellisense error reporting, but if someone has a workaround for this I'd love to hear about it.
Kind regards,
This problem is known to Microsoft:
http://connect.microsoft.com/VisualStudio/feedback/details/779874/intellisense-cant-handle-using-environemt-variable-in-include-path
The only way I know of to avoid it is to manually enter the full literal path. The bug is marked "deferred" which I think means Microsoft has regarded it not serious enough to be fixed soon.
The solution is to replace %CPLEX_STUDIO_DIR%\cplex\include with $(CPLEX_STUDIO_DIR)\cplex\include. This is the syntax Visual Studio uses for its built-in variables such as $(VCInstallDir), but it also works for environment variables (so long as they don't have the same name as a built-in variable) and is recognised by intellisense as well as the compiler.
(I realise this is an old question, but it ranks highly in search results so it could help others even if not the original poster.)
I'm porting a project from MSVS2005 to MSVS2010. I just loaded the solution in MSVS2010 and let the wizard convert the projects.
I ran into the property manager and found these property sheets (top-to-bottom):
Upgrade from VC 7.1
Microsoft.Cpp.x64(or Win32).user
Multi-byte Character Support (not editable)
Dynamic Link to MFC (not editable)
I understand the last three ones but I don't know what is the purpose of Upgrade from VC 7.1. Can someone give me a little explanation?
P.S. I found C/C++, Preprocessor, Preprocessor Definitions = _VC80_UPGRADE=0x0710;%(PreprocessorDefinitions) in property page "Upgrade from VC 7.1" but in project properties I see NDEBUG;WIN32;_LIB;%(PreprocessorDefinitions). What does all this mean? What is the _VC80_UPGRADE=0x0710 macro?
A project property sheet simply pre-sets settings for a project. Unless the project overrides the setting. Which your project does, it overrides the "Preprocessor Definitions" setting. The extra "%(PreprocessorDefinitions)" macro ensures that the definitions from the property sheets are appended and not lost.
So the definitions that the compiler sees are NDEBUG;WIN32;_LIB;_VC80_UPGRADE=0x0710
The _VC80_UPGRADE macro helps your old project to compile and run correctly on Visual Studio version 2005 or later. It is used, for one, in vc/atlmfc/include/afxres.h to ensure that the manifest resource has the correct ID.
You are skipping many VS and Windows versions so this doesn't exactly mean you'll have no problems at all. Particularly UAC can give you a headache.
In a project I'm working on FxCop shows me lots of (and I mean more than 400) errors on the InitializeComponent() methods generated by the Windows Forms designer. Most of those errors are just the assignment of the Text property of labels.
I'd like to suppress those methods in source, so I copied the suppression code generated by FxCop into AssemblyInfo.cs, but it doesn't work.
This is the attribute that FxCop copied to the clipboard.
[module: SuppressMessage("Microsoft.Globalization",
"CA1303:DoNotPassLiteralsAsLocalizedParameters",
Scope = "member",
Target = "WindowsClient.MainForm.InitializeComponent():System.Void",
MessageId = "System.Windows.Forms.Control.set_Text(System.String)")]
Anyone knows the correct attribute to suppress this messages?
PS: I'm using Visual Studio 2005, C#, FxCop 1.36 beta.
You've probably got the right code, but you also need to add CODE_ANALYSIS as a precompiler defined symbol in the project properties. I think those SuppressMessage attributes are only left in the compiled binaries if CODE_ANALYSIS is defined.
In FxCop 1.36 there is actually a project option on the "Spelling & Analysis" tab that will supress analysis for any generated code.
If you don't want to turn analysis off for all generated code, you need to make sure that you add a CODE_ANALYSIS symbol to the list of conditional compilation symbols (project properties, Build tab). Without this symbol defined, the SupressMessage attributes will be removed from the compiled code so FxCop won't see them.
The other problem with your SuppressMessage attribute is that you are listing a "Target" of a specific method name (in this case WindowsClient.MainForm.InitializeComponent():System.Void) and listing a specific "Scope". You may want to try removing these; otherwise you should add this SuppressMessage to each instance of the method.
You should also upgrade to the RTM version of FxCop 1.36, the beta will not automatically detect the newer version.
Module level suppression messages need to be pasted into the same file as the code that is raising the FxCop error before the namespace declaration or in assemblyinfo.cs. Additionally, you will need to have CODE_ANALYSIS defined as a conditional compiler symbols (Project > Properties > Build). Once that is in place, do a complete rebuild of project and the next time you run FxCop the error should be moved to the "Excluded in Source" tab.
Also, one small tip, but if you are dealing with a lot of FxCop exclusions it might be useful to wrap a region around them so you can get them out of the way.