I installed the Windows 8 SDK (which is supposed to include the DirectX SDK).
But my directX stuff is not working (See this question about that).
But on a seperate question, I wanted to ask where all the DirectX SDK stuff is supposed to be after you install the Windows 8 SDK.
If the answer is "lots of places" then lets go with this one file: d3dcompiler_43.dll
I found the answer here: http://msdn.microsoft.com/en-us/library/windows/desktop/ee663275.aspx
It says:
Any project that uses run-time shader compilation must have D3DCOMPILER_46.DLL copied to the local executable path for the project. This DLL is available in this sub-directory of the Windows SDK installation under %ProgramFiles(x86)%\Windows Kits\8.0\Redist\D3D\ where is x86 and x64.
Related
This C++/WinRT announcement states "What this also means is that you no longer need to wait for us to update GitHub following the release of a new Windows SDK. Indeed, we will no longer be publishing the updated headers on GitHub at all since you can get them directly from the Windows SDK."
However if one delves one click further one finds that the "Windows 10 Preview Build of the SDK [is] to be used in conjunction with Windows 10 Insider Preview (Build 17025 or greater)" and "Installation on an operating system that is not a Windows 10 Insider Preview build is not supported and may fail."
Right now must one install a Windows Insider Preview of Windows 10? This is either a scary and lengthy process or straight impossible depending on one's admin rights.
Or can one grab the SDK and use the C++/WinRT bits on a box with a standard Windows 10 build?
Is the easiest route for some aspects of the C++/WinRT toolchain still GitHub?
How about if one is developing on a non-Windows-10 box, e.g. Windows 7? Zillions of commercial developers are in this situation and aren't in control of that.
Will the situation change and if so when?
Going forward does one wait for periodic updates to SDK previews, and if so how does one consume them?
Preview versions of the Windows SDK will not install on a non-Insider build of Windows. This is a restriction of the Windows SDK and not specific to C++/WinRT. In the long run (once RS4 ships) this won’t be a problem since you’ll be able to install the final Windows SDK for RS4 without this restriction.
In the short term, you need an Insider build of Windows to install the SDK, but you can then use that to target previous versions of Windows. I’m not sure whether it would work on Windows 7, but I don’t think that any developer using C++/WinRT would care to use Windows 7 when the Windows Runtime isn’t even available on that version of Windows at all.
The cppwinrt.exe compiler also relies on Windows 10 APIs to function. While this isn’t a dependency of code built with C++/WinRT, it is a requirement for building C++/WinRT components. Of course, the resulting binaries can then be executed on older versions of Windows, provided you handle light-up in the usual ways, such as with delay-loading.
I'm getting a DLLNotFoundException in standalone builds on some windows machines, others work perfectly. Dll file is definitely in the plugins folder, copied it to the projectName_Data folder too but no difference.
Also attempted to add dll to streaming assets folder and set new path (Environment.SetEnvironmentVariable) as above but that didn't work either.
Using Unity 4.5.5 btw
Any help at all would be greatly appreciated!!!
What I found is that the error DllNotFoundException is, in some circumstances, very misleading. Unity is not to blame for this because when something goes wrong with dll loading, Unity simply doesn't have that dll in memory and tells you so.
As Keysosaurus says, Visual C++ Redistributable must be installed for your standalone version to work and in most cases this solves the trouble but there can be other reasons like third party dependencies.
In case you are using third party libraries then you must also copy all the needed DLLs or SOs to your executable's folder.
For example I am working with OpenNI 2 and when I build I immediately copy all files from C:\Program Files (x86)\OpenNI2\Redist folder to the folder that contains the .exe. Not doing this results in DllNotFoundException.
Also don't forget that DLLs (and SOs) must match the architecture you are targeting so if you are targeting x64 (64 bit) then your DLL must be x64 too and if you try to use a x86 (32 bit) DLL Unity will be confused and will not load that giving you the same error.
As a side note bear in mind that Unity 5 comes both in 32 and 64 bit versions. In order to run your game in Unity Editor, all third party libraries must be present in both x86 and x64 (in Unity's conventional folders) or at least the one that matches you Unity Editor's architecture.
I discovered that the problem was that players needed Visual C++ redistributable installed, which can be downloaded here:
https://www.microsoft.com/en-gb/download/details.aspx?id=40784
I have some .NET code that I am looking into porting into being a Windows Store app.
This code does a few different things and one of the things it does has a dependency on being compiled as x86 instead of AnyCPU.
Is this going to be a problem? Can a Metro app be compiled as x86 and still be distributed on the Windows Store? Is being compiled as x86 going to stop it from being able to run in Windows RT? Would I have to come up with a version without this subset of functionality to run in Windows RT? If I can get the code into its own assembly can I just have the Windows RT version not use it? (so, the main executable is AnyCPU and this one assembly is x86).
Can a Metro app be compiled as x86 and still be distributed on the Windows Store?
Yes. However, it would only be installable for x86 installations.
Is being compiled as x86 going to stop it from being able to run in Windows RT?
Since Windows RT is designed to run only on ARM CPUs, compiling for x86 will stop it from being able to run on Windows RT.
Would I have to come up with a version without this subset of functionality to run in Windows RT? If I can get the code into its own assembly can I just have the Windows RT version not use it?
You could use conditional compilation symbols to include/exclude functionality as required in your code. https://stackoverflow.com/a/6587823/61385 shows an example of how to do this.
Just compile whatever libs you need and when you upload to app store just upload the one you want to. Check your apppackages folder and look for the .appxupload files.
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!!!
I'm developing a C#/WPF app that talks to a USB device using some custom 32 bit dlls. It's developed as an x86 app, and installed with WIX. When I install the package on a 64-bit machine, the program files get installed to Program Files (x86) as I expect.
The dlls are installed to the SystemFolder using WIX. On 32-bit machines, this means C:\Windows\System32. On 64-bit, they end up in C:\Windows\SysWOW64. This is ok, but when I run my app, it is unable to find the dlls (it uses them via [DllImport...]).
So, what is the right way to make my app find the dlls, whether they are in System32 or SysWOW64?
Thanks
Tom
If it is a default C# app, it will automatically be a 64 bit app on 64 bit Windows (C3 defaults to 32 bit on 32 bit Windows). Go into the project properties in your development app and explicitly set the architecture (I think; I don't have Studio up right now) to 32 bit. If it is running as a 64 bit app, it won't be able to use your 32 bit DLLs.
Please check if the dll in application is of the same version as that in the sys32 or wow64 folder depending on your version of windows.
You can check that from the filesize of the dlls.
Eg: I faced this issue because my libeay.dll file in system32 had a different dll than my libeay.dll file in openssl application. I copied the one in sys32 into openssl and everything worked well.