DirectXMath and Win8 SDK in VS2010 project - windows-8

I've been working in an engine in Visual Studio 2012 that supports rendering with Direct3D 9 and Direct3D 11. However I'm getting some new people to help with the project and they would prefer to work on Visual Studio 2010 because that's the version they own and use. So I decided to convert the project to be built with VS2010's v100 platform toolset.
I'm getting close to getting it to work but I can't include DirectXMath.h, necessary for the DirectXTK and some utility functions I'm using. It's part of the Windows 8 SDK and included in VS2012, but VS2010 doesn't seem to find it.
Anyone knows how to get it to be included using environment variables so that it works for everybody on the team, and in a way that works on Win7 too?
Thanks.

To make new teammates be able to code in VS2010 you have several options:
You don't need to change platform toolset to old one and rewrite your codebase. VS2010 developers can just install Windows 8 SDK, and use v110 toolset. To help them, configure "VC++ directories" in project properties as pointed in this article (change macro variables, which points to old Windows SDK, to explicit locations of new Windows SDK):
In “Executable Directories” replace $(WindowsSdkDir)binwith$(ProgramFiles)\Windows Kits\8.0\bin\x86`
In “Include Directories” add $(ProgramFiles)\Windows Kits\8.0\Include\um;$(ProgramFiles)\Windows Kits\8.0\Include\shared at
the beginning and remove $(WindowsSdkDir)include
In “Library Directories” replace $(WindowsSdkDir)lib with $(ProgramFiles)\Windows Kits\8.0\lib\win8\um\x86
In “Exclude Directories” replace $(WindowsSdkDir)include with $(ProgramFiles)\Windows
Kits\8.0\Include\um;$(ProgramFiles)\Windows Kits\8.0\Include\shared
When targeting x64, replace x86 with x64
If you really want to downgrade toolset from v110 to v100, then you will need to make use old standalone DirectX SDK. Before, Windows SDK and DirectX SDK was separate. They was merged since Windows 7 SDK. When merging, Microsoft decidede to remove some stuff and also renamed some files, for example, standalone SDK contains math in #include <xmmath.h>.
You can combine both: create multiple project/platform configurations and inmplement conditional compilation via #ifdef where VS2010 configuration will fail to find headers/compile. For example you can use C++11 features in VS2012 branch of code, but in VS2010 branch you use only C++03 features.
I would prefer first option, but it is up to you to decide.
P.S. As far as I remember, project files from VS2012 (.vcxproj) cannot be opened in VS2010 (it knows only .vcproj), so you cannot share it. You will probably want to install VS2010, make .vcproj and maintain both files. It can be pain when you change project options in one, and forget to change in other, so be careful. Also, consider to move all your team to single IDE, or at least single build system (for example, CMake).
Happy coding!

Related

Setting up cross platform development for Mono/ARM

I'm going to develop and compile C#/Mono app on Windows 7 with Visual Studio and then run this app at Linux device. I googled a lot, but one point is still confusing me - how should I set up my development environment. I have Mono for Windows installed on my laptop and now there are two possibilities:
create regular windows c#/net project which will use references from Windows\MS.NET framework, build this project using msbuild, copy and run this app on Linux
create Mono target for VS, create project which will use references from ProgFiles(x86)\Mono\lib, build this project using xbuild etc.
Which way I should choose? It seems to me, that option #2 is more preferable, but I do not understand why.
None of your solutions is very good. I would choose a 3rd one:
Develop your code with Linux, using MonoDevelop IDE.
There are many reasons why this option is the best, such as:
Mono for Windows is suboptimal: You will find some things don't work (which do work on Linux) or things that are much slower than normal.
Mono is not 100% compatible with MS.NET: Some things are unsupported in Mono (e.g. System.Management) or have too many bugs to be considered stable (e.g. WCF). So it's better that you test on Mono as soon as possible, i.e. while developing and debugging locally.
MonoDevelop is still a very good IDE which can compete with VS in some areas (e.g. Code Completion).
Well, I use myself mono on Linux/ARM and I do all my development under Visual Studio, just compiling for AnyCPU and taking a bit of care on what to use.
You can even debug your program on the target machine from Visual Studio using MonoDebugger, it starts to work decently.

How do I point CodeBlocks and Visual Studio Express 2008-2012 to custom Include and Lib directories?

This is a tricky question... I have put together a compilation of DirectX, OpenGL and Windows SDK Include and Lib files into a single directory called, "AllCode." Inside that are Lib and Lib/x64 Directories, and an Include Directory. Essentially everything from DirectX 7 to now is in there. You can check out the page I have this on here:
http://hi-techheadache.blogspot.com/p/blog-page.html
The point of this is to make it easy to compile and run code from any book. I want CodeBlocks and Visual Studio Express 2008-2012 to be pointed, as it were, to my AllCode directory, so that anytime it needs to refer to any of those files it can. I don't want any errors from missing files! I want to code something from a book like, "Programming A Multiplayer FPS in DirectX" by Vaughan Young and expect that it will compile, link and run without issue! How do I set each IDE up for this?
BTW I'm on a Windows 7 64-bit machine. All drivers updated and installed. Running the latest version of CodeBlocks, Visual Studio Express 2010 SP1 and Visual Studio Express 2012.
You can create an empty project that specifies the required settings. You want to specify include directories, and add libraries to be passed to the linker. You can save the project somewhere, and then make a new copy of it every time you need to start a new project. You could even include some boiler-plate code if appropriate.
Certainly on Visual Studio you can take this approach further and convert the project into a fully fledged template that appears in the new project dialog: http://msdn.microsoft.com/en-us/library/vstudio/s365byhx(v=vs.100).aspx. I expect that CodeBlocks has similar functionality.

How to make a Vb.net file/program To Standalone .Exe

I have a project done in VB.NET and I want to publish it for distribution. I know that when I build solution It creates an .Exe. But that requires local resorouces. If I build for release I know it works but it still needs the .Net platform installed. Is there anyway to make a true standalone .exe or something that would run on a persons computer if they do not have .NET installed. Also the ClickOnce application thing is not a wanted Solution.
Is there any converter program that can do this for me?
The .NET framework represents the basic prerequisite to run a .NET program; equivalently than having Windows installed is the prerequisite to run a Windows program. Bear in mind that any Windows version includes the .NET framework (and, actually, it tends to involve top-priority updates and thus are automatically perfomed by Windows Update in many cases). A big proportion of the programs running on Windows created during the last 10 years are built on the .NET framework; a relevant proportion of the sites (like this one, for instance) are built on ASP.NET and thus the given server has to include the .NET framework. If overall compatility is a concern for you, you might rely on a-bit-old .NET version: the latest one in VS 2010 (4.0) should be fine for most of modern computers; but you can even rely on the previous one (3.5) to be completely sure. Lastly, bear in mind that a .NET program can also be run under a OS other than Windows (Linux or MacOS, for example); although, from my past experiences, these are not too reliable situations. Nonetheless, in case of being interested in other OS, you should do some research/testing on this front to see if the available options offer what you are looking for.
SUMMARY: the exe file generated by the Visual Studio is actually what you call "standalone .exe". One of its defining features is the .NET version (which can be changed in the Project Settings); a program can only be run on computers with a .NET framework (or equivalent) equal or newer than the one on which it was built. The 4.0 version should be OK for most of new/properly-updated computers; the 3.5 .NET would work with virtually any computer (although, logically, it includes less features than the 4.0 one).
---------------------------- UPDATE AFTER COMMENTS --------------------
From some comments, I have undertood that my statement wasn't as clear as I thought and this is the reason for this update
.NET is pre-installed in Windows only since Vista. XP does not include the .NET runtime by default. The reason for not having mentioned this issue in my answer was that having a XP Windows without .NET is highly unlikely. Firstly because this is a top-priority, automatic update and thus one of the first times the computer is connected to internet "Windows Update" will take care of this. And secondly because this is the basic framework for any Microsoft programming over the last 10 years and thus a Windows computer not having it will not be able to run almost anything. With this last sentence, I don't mind that most of the programs are built on .NET, but that for a Windows-based environment most of nowadays basic requirements do include .NET.
It was also pointed out that there is some compatibility problems between different .NET versions (that various side-by-side versions were required). The basic Microsoft approach to the different .NET versions is backwards compatibility, what means that a given .NET version can run any program built with that version or older. This is theoretically right, but not always right in fact. My approach to this problem is relying on a bit old .NET version (3.5) and not using too new/untested features (e.g., WPF). If you want a for-sure overall compatible program you should work quite a lot on this front (compatibility between versions is one of most typical problem of any programming platform), instead expecting Microsoft to take care of everything. Thus, in principle, just one .NET version (the last one) has to be installed (which, on the other hand, is not the case for a big proportion of computers; for example: computer including the 3.5 version being updated, over the years, to 4.0 and 4.5 by maintaining the previous versions).
Lastly, I want to highlight that my intention with this answer is not defending any programming approach over any other one; I am just describing what is there from the point of view of your question "can I remove the .NET part?" -> no, you cannot; there is no (sensible) way to do that. If you want to rely on a different programming platform you should get informed about it (I am sure that Camilo Martin will be more than happy to help you on this front). If you prefer to rely on .NET, be sure that you can generate an overall compatible program (to be run on Windows).
Easy way to convert in .exe in VB.NET-2010:
Create New Project
Select Windows Application And Save Proper Path
Comple Project then Select File-> Save All
Select Build->Start Build
Your Project .exe Created Your Project Save Path:
Select Windows Application 1
Select bin Folder
Select Debug Folder
And in Debug folder your .exe File is ready.
Quick Basic once made and executable (.exe) directly form their VB code, but I wouldn't recommend converting to Quick Basic. You can look at Mono to see if they have anything yet. (mono allows you to use compiled vb.net in other operating systems).
Ezirit Reactor makes a single executable, but it's not free.
You can bundle .NET Framework into your distribution so that users don't have download it.
Why do you need an executable (.exe)? If the reason is for security and to minimize chances of reverse engineering, then get a good obfuscator.

How to add C++/CX library to Windows Store solution targetting Any CPU

So I have a Windows Store app using C# targeting Any CPU so that the single app will run on any Windows 8 x86/x64 desktop/tablet or ARM tablet. I need to add some special code in C++ which doesn't seemto have the option to target Any CPU. The code will compile and run both on x86/x64 and if I change the entire solution to ARM it will compile and run there too. So I'm looking for a way to make the C++ target Any CPU which I think is probably impossible. Or have the C++ library compiled multiple times (x86, x64 and ARM) and have all of them included in the appx package. I have spent about 3 hours reading Windows Store development docs on C++/CX and haven't found any way to do this yet. Of course I'll keep looking, but I'm hoping someone else has seen how to do this and can point me in the right direction.
There's no way you can create a single package targetting AnyCPU when you're calling into a native library. You need to create three different packages, one for each target architecture. When you're uploading the app to the store, you can include all three packages.
To simplify the process of building all three packages, you could create a Visual Studio extension (vsix) with all three builds of your native library. In this case the native library for the right platform will be automatically included in each package. Here's a quick tutorial on how to do it.

d3dx11.h not in Windows 8.0 kit

My development platform is windows 7 x64. I have installed VS2012 and I'd like to compile a project that includes some Dx11 code.
Specifically, it includes the following files:
#include <d3dx11.h>
#include <d3dx10.h>
and links to
#pragma comment (lib, "d3dx11.lib")
#pragma comment (lib, "d3dx10.lib")
I already have VS2011 installed on my development machine, but I wanted to try the unit testing facilities in VS2012 for native C++.
Due to having VS2011 installed and working on DirectShow code, I have the Windows 7.1 SDK installed.
VS2012 picked this up and had references to the 7.1 SDK, but compilation of my project under VS2012 with the 7.1 SDK referenced gave errors:
"warning C4005: '__useHeader' : macro redefinition"
I googled this and found a query like mine on social.msdn.microsoft.com. and the solution recommended linking with the Windows 8 kit instead of the 7.1 SDK in order to solve this problem.
The Windows 8 kit includes headers like d3d11.h, but not d3dx11.h.
How can I include d3dx11 (from the Dx SDK) along with the windows 8 kit, but without getting multiple "macro redefinition" errors?
I found the following rather annoying quote in this MSDN page.
D3DX is not considered the canonical API for using Direct3D in Windows
8 and therefore isn't included with the corresponding Windows SDK.
Investigate alternate solutions for working with the Direct3D API.
For legacy projects, such as the Windows 7 (and earlier) DirectX SDK
samples, the following steps are necessary to build applications with
D3DX using the DirectX SDK:
Modify the project’s VC++ directories as follows to use the right
order for SDK headers and libraries.
i. Open Properties for the project and select the VC++ Directories
page.
ii. Select All Configurations and All Platforms.
iii. Set these directories as follows:
Executable Directories: (On right-side drop-down)
Include Directories: $(IncludePath);$(DXSDK_DIR)Include
Include Library Directories: $(LibraryPath);$(DXSDK_DIR)Lib\x86
iv. Click Apply.
v. Choose the x64 Platform.
vi. Set the Library directory as follows:
Library Directories: $(LibraryPath);$(DXSDK_DIR)Lib\x64
Wherever "d3dx9.h", "d3dx10.h", or "d3dx11.h" are included in your
project, be sure to explicitly include "d3d9.h", "d3d10.h" and
"dxgi.h", or "d3d11.h" and "dxgi.h" first to ensure you are picking up
the newer version.
You can disable warning C4005 if needed; however, this warning
indicates you are using the older version of these headers.
Remove all references to DXGIType.h in your project. This header
doesn't exist in the Windows SDK, and the DirectX SDK version
conflicts with the new winerror.h.
All D3DX DLLs are installed onto your development computer by the
DirectX SDK installation. Ensure that the necessary D3DX dependencies
are redistributed with any sample or with your application if it is
moved to another machine.
Be aware that replacement technologies for current uses of D3DX11
include DirectXTex and DirectXTK. D3DXMath is replaced by DirectXMath.
FFS Microsoft, please don't change the API's mid-version like this!!!