I have installed Windows SDK on my Windows 10 laptop. However, there are assembly references to Microsoft.DirectX, Microsoft.DirectX.Direct3D, Microsoft.DirectX.Direct3DX and Microsoft.DirectX.DirectInput in my code. These are generating the error - The type or namespace name directx does not exist in the namespace Microsoft when i compile my code. Do I have to point my code to the directx header files that are installed within the Windows SDK. These are available at C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\cppwinrt\winrt\impl. If so, how do I point my code there. The directx files there are Windows.Graphics.DirectX.0, Windows.Graphics.DirectX.1 and so on and so forth. Should these be referenced instead of Microsoft.DirectX, Microsoft.DirectX.Direct3D, Microsoft.DirectX.Direct3DX and Microsoft.DirectX.DirectInput. If so, how?
The Microsoft.DirectX.* assemblies are the legacy Managed DX 1.1 assemblies that only shipped in the legacy DirectX SDK. They have nothing at all to do with the Windows Runtime APIs or C++/WinRT language projections. They never shipped in any Windows 10 SDK and are only deployed by the legacy DXSETUP package.
See this blog post and this blog post.
A recommended replacement is to use SharpDX or SlimDX.
SlimDX is no longer an active project, but it is still a good option for a direct replacement of legacy Managed DX 1.1
Related
I am looking for access to some functions in the DLL I mentioned above. I am not aware of any Nuget package that provides this DLLs.
So my question is, where do I get the latest version of this .dll from MS, and are they compatible with plugins targeting VS2019 and later?
Thanks for the answers, I am new to stack-overflow and probably didn't explain myself better.
I am developing a Visual Studio Plugin which closes some Document Windows in VS. I found some repos of VS plugins on Github which has a reference to this .DLL, and they use it to close all clones of Document Windows by casting the IVsWindowFrame to WindowFrame class belonging to this DLL.
As pointed out in comments: I found the DLL in my C: drive under this path: C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE
Microsoft's newly announced Project Islandwood is interesting, as it allows Objective-C code written for iOS to be repurposed into a Universal Windows app.
I couldn't find any information on the details, so:
Has Microsoft effectively implemented an iOS subsystem in Windows 10?
Is it built on existing software (e.g. the old OpenStep source code) or built from scratch?
Are all the various iOS frameworks - Core Data, Core Text, Core Graphics, OpenGl, etc - implemented?
It allows writing Universal Windows Apps in Objective-C using the normal Windows Runtime along with an iOS API compat layer.
Visual Studio 2015 has a language projection for Objective-C so that you can compile Objective-C into a Windows app. The most common iOS API (CoreGraphics, CoreText, OpenGL, etc.) are provided .
You can import an Xcode project into Visual Studio and then compile it as a Windows app.
See the Project Islandwood site at http://aka.ms/islandwood and the Build talk Compiling Objective-C Using the Visual Studio 2015 C++ Code Generation that Builds Windows, SQL, .Net, and Office for details. Jim Radigan talks about the Objective C code generation in the first half. Salmaan Ahmed starts talking specifically about Project Islandwood about 33 minutes in.
I am building an F# console application with Visual Studio 2013 Ultimate. The target framework is .Net 4.5
The version of FSharp.Core installed on my computer (presumably by installing VS 2013) is 4.3.1.0.
On NuGet there are two versions of FSharp.Core, 4.0.0 published April 12, 2012 and one with an ID of Fsharp.Core.3 verison 0.0.2 published March 5, 2013.
I am looking for guidance as to when one should use each of these versions, the version numbering is confusing me and I would have expected to find the latest production release on NuGet.
Am I missing something?
You should not be obtaining FSharp.Core from nuget. Microsoft does not publish any official F# bits to nuget today (though this could potentially change in the future). It's common for 3rd-party packages to bundle FSharp.Core (since presumably that's the version used for testing/validation of that 3rd-party component), but nuget should not currently be used as a mechanism for getting FSharp.Core updates or new versions.
The versioning story for FSharp.Core is sadly rather complex, and definitely not as simple as "higher version means newer." A key thing to realize is that there are 2 axes - what F# version does the runtime support, and what .NET framework version/profile does it target.
Below are the official FSharp.Core versions that ship with VS 2013 (find these dropped under %ProgramFiles(x86)%\Reference Assemblies\Microsoft\FSharp).
4.3.1.0 (F# 3.1/.NET 4) This is the most recent official version. Unless you have a requirement to target .NET 2, or you are using some legacy F# component that won't work with 3.1, this is the version you should use for any new desktop app.
4.3.0.0 (F# 3.0/.NET 4) These are the same bits that shipped with VS 2012. It is included so that you can continue working on F# 3.0 projects in VS 2013 without retargeting them to 3.1. You should use this if you have a legacy F# 3.0 desktop project that you are not ready to move to 3.1 yet.
2.3.0.0 (F# 3.0/.NET 2) These are the same bits that shipped with VS 2012. The only reason to use this is if you are targeting .NET 2. The .NET 2 side of things is not being developed further, btw - new features, versions, etc will be done for FSharp.Core targeting .NET 4+; the .NET 2 FSharp.Core is still fully supported, but it is frozen.
3.3.1.0 (F# 3.1/"Portable") This version targets .NET portable profile 7 (.NET 4.5/Windows Store). Use this if you are creating a component for a Windows store app and you don't care about Silverlight. This profile is newly supported in VS 2013.
2.3.5.1 (F# 3.1/"Portable (Legacy)") This version targets .NET portable profile 47 (.NET 4/Silverlight 5/Windows Store). Use this if you are creating a Silverlight component. This profile was also supported in VS 2012, and referred to at that time as simply "Portable."
2.3.5.0 (F# 3.0/"Portable (Legacy)") This version targets .NET portable profile 47 (.NET 4/Silverlight 5/Windows Store). These are the same bits that were included in VS 2012. Included in VS 2013 to enable you to continue working on F# 3.0 portable/silverlight projects.
.NET portable profiles are a big PITA and cause a ton of complexity. This site has a good summary to help understand: http://blog.stephencleary.com/2012/05/framework-profiles-in-net.html
So for your specific scenario (new console app) use 4.3.1.0.
Edit 7/2015:
Here's a table that probably explains the story better than the wall of text above. I've tried to use colors to indicate the motivation for the version numbers. You'll see the versioning of the portable libraries was a bit ad hoc and inconsistent in VS 2012 and 2013, but is finally consistent and predictable starting with VS 2015. This is up to date with F# 4.0, which just released.
Today I would probably rather follow these guidelines
In short, you can/should reference FSharp.Core from NuGet
We are trying to integrate an OpenCV C++ Windows Runtime Component with a C# Windows Store App. We are currently working on Windows 8 (x64) platform and using Visual Studio 2012 with OpenCV 2.4.5. The actual aim is to detect faces in a C# Windows Store App working on x64 platform. We successfully set up OpenCV 2.4.5 with Visual Studio 2012 (x64 platform) and copied all the dll's of openCV to the "system32" folder so that we are able to build and run the openCV projects on the above mentioned platform.
Here are the problems faced by us:
We are successful in building the C++ Windows Runtime Component that contains the code for the face detection. But as soon as we integrate that with the Store App and try to make the object of the WinRT's class. It throws an exception.
But the whole project works fine if we comment the lines where we are trying to work on images and cascades.
Solely we are able to detect faces in Win32 Console application using the above code. But not able to do the this task.
I am giving the link to the project we are working on.
"https://www.dropbox.com/l/OkEZNMrazzFmV6UOj59KMb"
About the project:
1. "FaceDetectWinRT" is the C++ Windows Runtime Component project which contains "Class1.cpp" and "Class1.h" which contains the code for the face detection.
2. "FaceDetectStoreApp" is the C# Windows Store App project that has the reference to the above project and is declared as the "Start up" project.
3. There is a button in the " FaceDetectStoreApp " under "MainPage.xaml.cs" class which when clicked calls the " FaceDetectWinRT " project's function "face" which when working is expected to return the coordinate of the face that is detected.
I did the same thing with very similar results. I had success when deploying the WinRT app on an ARM device. You need to:
Include the OpenCV dlls in the C# project marked as "Content"
Don't forget the highgui dll. The objdetect dll depends on it.
Make sure you reference all the OpenCV .lib files, one per OpenCV dll
Switch the configuration to ARM in the Configuration Manager
Deploy to a device running ARM (i.e. the Surface) usually done through Remote Debugger
I have not yet had success running the app on a x86 device (i.e. the Surface Pro). I believe the problem is that the objdetect dll depends on the highgui dll. The ARM build of the highgui dll only depends on a few standard libraries. The x86 build depends on several additional libraries that aren't available for WinRT. I think you might be able to get it to work by building OpenCV for x86 without highgui. You can do this by setting the BUILD_opencv_highgui CMake variable to OFF.
I know I can download the "April CTP" to get F# 2.0 for .NET 2.0. But I need FSC and F# Interactive for .NET 4.0. On a machine with VS 2010 installed, it ends up in C:\Program Files (x86)\Microsoft F#\v4.0. Is there a redistributable for this?
If you installed Visual Studio 11 Beta or Visual Studio 2012, I recommend you check the following path, where you will find Fsi.exe and Fsc.exe.
C:\Program Files (x86)\Microsoft SDKs\F#\3.0\Framework\v4.0
Others have provided good answers; I'll summarize and add one more bit (2nd bullet):
We don't have any polished story here yet. We're working on one.
In the case of the compiler, you may be able to get by with the fsc.exe in the April CTP (it is capable of referencing .NET 4.0 assemblies and building .NET 4.0 assemblies, even though the compiler itself runs on 2.0). (Note that for building project files, you might also need the right Microsoft.FSharp.targets imported; I haven't worked all that through...)
If you were to copy the right assemblies and targets files from a VS2010 install to another machine, that would work, but offhand I don't know if that violates the VS license.
The existing downloadable "redist" does only contain FSharp.Core.dll.
(possibly see also this for a similar discussion but no extra info, as well as this Connect request)
The redistributable, for the F# runtime, is available at the following link, but unfortunately doesn't include the compiler or F# interactive:
http://www.microsoft.com/downloads/details.aspx?FamilyID=5f0a79f8-925f-4297-9ae2-86e2fdcff33c&displaylang=en
If you already have VS2010 installed on the machine there shouldn't be no need to install it, as the compiler, fsi, and F# runtime will be installed with VS. It should be just a matter of adding the directory containing the compiler to the path, so the shell can find it (if you want to use the compiler/fsc from the command-line).
This is an old question, but I came across it and thought that I'd add an update for people who find it through Google:
The current version of the F# CTP (April 2011) includes both .NET 2.0 and .NET 4.0 binaries, including FSI.exe. On my install...
.NET 2 = C:\Program Files (x86)\FSharp-2.0.0.0\bin\
.NET 4 = C:\Program Files (x86)\FSharp-2.0.0.0\v4.0\bin\
I think that there is no standalone installation of F# for .NET 4.0 (similar to the standalone installation for .NET 2.0). The reason probably is that F# for .NET 4.0 is simply meant to be distributed only as part of Visual Studio 2010 and not separately (just like other core Visual Studio languages).
If you need to use fsi.exe and fsc.exe for .NET 4.0 on a machine that doesn't have Visual Studio installed, you'll probably need to copy them together with the referenced libraries. This shouldn't be that difficult - you only need assemblies from "C:\Program Files (x86)\Microsoft F#\v4.0" together with FSharp.Core.dll (which should be added to the GAC) and (I think) also ISymWrapper.dll (but I'm not quite sure where this is located).