Can C++/CX simplify my (non-WinRT) WPF application?

Asked 19/9, 2011 at 9:54 Answered 23/9, 2011 at 12:6

C++/CX seems to make interfacing native C++ with C# FAR easier and more direct than the current method using a C++/CLI 'layer' in-between (with all the complications that entails). But can I use C++/CX OUTSIDE WinRT in a old-school WPF Desktop-style Application? Clarification: My WPF App 'wraps' an older Windows32 Application code. So I'm interopting with native c++, but it's awkward having native c++, Managed C++ and c# all in the same application..

Caltrop answered 19/9, 2011 at 9:54 Comment(3)

C++/CX generates pure native code, unlike C++/CLI. Some interop is possible since C++/CX ref classes are COM under the hood. The registration is going to be tricky though, WinRT uses a very different deployment scenario (everything in a .zip). You are going to have to get it registered somehow. C++/CX surely isn't generating a DllRegisterServer method so that Regsvr32.exe would work. – Ciao 19/9, 2011 at 10:55

AH, OK, So C++/CX is like COM, but not exactly. c# apps (outside WinRT) can't easily reference it. – Caltrop 19/9, 2011 at 21:17

Theoretically (as it's COM under the hood) they could be access-able in .NET through a COM-Callable-Wrapper… – Pol 19/9, 2011 at 22:19

No you cannot use C++/CX outside WinRT - it relies on the windows runtime metadata and there is no metadata for non winrt APIs.

Anomalism answered 19/9, 2011 at 17:1 Comment(11)

I think he's rather talking about writing his own WinRT component in C++/CX, and then referencing that component from a .NET WPF app. Unless WinRT projection is only enabled for Metro-style apps, and not available in desktop .NET, it seems to me that this should actually work. – Exemplification 19/9, 2011 at 22:3

Pavel: You're right, that should work. I assumed he was trying to use C++/CX to simplify other COM operations. – Anomalism 20/9, 2011 at 2:40

It will be difficult to install and activate a WinRT object outside of the Metro style app universe. There is no package to install it with. – Melodramatize 21/9, 2011 at 6:37

Actually you can't activate a 3rd party winrt object outside of a metro style app. But you can use some 1st party APIs. – Anomalism 21/9, 2011 at 13:14

Which is it? Can we or can we not use a C++/CX component in a WPF app? – Sidwohl 21/9, 2011 at 23:2

@David after some experimentation, it seems that you indeed cannot. It's not even the activation - even simply using a WinRT type from a third-party DLL in any way (e.g. declaring a variable of such type) leads to a crash at runtime. My understanding of the problem is that runtime cannot locate the .winmd file to read metadata from, because the only two locations it looks at are the system folder (C:\Windows\System32\WinMetadata), and the current appx. And when your app is not a Metro app, there's no appx... – Exemplification 22/9, 2011 at 3:6

Thanks Pavel - major bummer. C++/CLI is the interop story for the desktop, and C++/CLI is DEAD on metro-style apps, while C++/CX is the interop story for Metro, and is disallowed on the desktop. C'mon MS...give us cross-platform C++/CX goodness! – Sidwohl 22/9, 2011 at 5:22

@Pavel: I did say that you can't activate a 3rd party winrt object outside a metro app. And it's not about the metadata - the C++ compiler doesn't load metadata at runtime. – Anomalism 22/9, 2011 at 13:24

@Larry The question is about using a C++/CX component from .NET. I tried to work around the activation requirement by exposing a factory method from the C++ DLL via P/Invoke and calling that from .NET, hoping that activation within the same DLL would be direct. But it seems that CLR tries to load metadata at runtime (presumably for its RCWs?), because, as soon as I reference the class defined in C++/CX in any way - as in merely declaring a local variable of that type, without even trying to new anything! - I get an ArgumentException wrapping a E_INVALIDARG coming from somewhere. – Exemplification 22/9, 2011 at 17:3

Sorry, I thought this was about C++/CX from C++/CX. And yeah, the CLR looks at the package identity for non 1st party apps. I DID say that it didn't work. If it did work, it would be a bug that we would have to fix. – Anomalism 23/9, 2011 at 5:7

RoInitialize() isn't getting called, that puts a quick end to it. You'd need a custom CLR host so it can be called before CoInitialize. Still leaves the problem of hacking the activation api, looks heavily registry based. – Ciao 23/9, 2011 at 12:26

Yes you can. WinRT and Win32 is interoperable, just that any application using anything outside the WinRT world cannot be sold in the appstore.

Fibrinolysis answered 23/9, 2011 at 12:6 Comment(0)

Recommended topics

Hot tags