Access existing COM dll from Metro style apps RRS feed

  • Question

  • I have an existing WPF (C#) app that calls a few unmanaged C++ COM dll. And these COM dll which in turn will call other COM dll and/or device driver. Most of these dll are compiled using  WDK6000. To create a metro style app for this, other than rewrite the app (.exe) to a metro style app, do I need to rewrite those C++ COM dll as well?

    Does this have anything to do with whether those COM dll will package together with the metro style app during deployment?

    Thank you.

    Monday, November 28, 2011 12:51 PM


All replies

  • Maybe I should widen the scope of my question. in the BUILD video "Bring existing C++ code into Metro style apps", Mr. Contenti has a slide that says standard c++ libs and ppl are still available in Metro style apps while win32 and ATL only have a subset of them available in Metro, and MFC  is not supported any more.

    I would like to know this "partially supported" or "not supported" statement refers to the Metro style apps, meaning, the application executable (.exe) itself or, it means every components that are loaded into the Metro apps address space can only have a subset of win32, ATL etc..

    And the components (dll for example) that are loaded by Metro style app, must it be a WinRT component?


    Thank you very much. 

    Tuesday, November 29, 2011 8:23 AM
  • Not just the exe, any dependencies need to be WinRT compliant as well. The DLLs do not need to be WinRT components but they should only use API allowed under WinRT.

    Tuesday, November 29, 2011 7:45 PM
  • Here are some //build/ talks that elaborate on Nishant's answer.

    Herb Sutter's talk speaks to the point about types you can use internally in your C++ code vs. the WinRT types you need to use when exposing a component to WinRT callers.

    Using the Windows Runtime from C++
    Speakers: Herb Sutter


    Jason's talk is all about reusing existing code with some demo's. I would highly recommend watching the entire presentation, but I think what your asking, how to reuse my existing components is discussed around 23:45 into the presentation.

    Being pragmatic by leveraging existing code in Metro style apps
    Speakers: Jason Olson


    The Windows App Cert kit, discussed in Ted's talk below, will generate a report of any API's in use by components you have packaged in your app that are not allowed.

    Introducing the Windows Store
    Speakers: Ted Dworkin




    Tuesday, November 29, 2011 10:30 PM

    Hi David,

    Thanks for the link. They are great presentations, especially Jason's talk.


    Hi Nishant,

    Not just the exe, any dependencies need to be WinRT compliant as well. The DLLs do not need to be WinRT components but they should only use API allowed under WinRT.

    I created a simple Metro style app to access my old unmanaged C++ COM dlls. I haven't tried out every single interface from the dlls yet. But it seems that so far the Metro app has no problem accessing and making calls to those dlls without any modification from the dlls. I am not sure I should be happy or worried about it...... Could it be the reason that the dlls are compiled using WDK instead of windows SDK?

    Thank you.


    Friday, December 2, 2011 10:13 AM
  • Just some terminology confusion I guess. When Nishant said that all dependnencies need to be WinRT compliant, he really meant that they should be compliant with the Metro style SDK (which is a subset of the overall Windows SDK).

    The terms "WinRT" and "Metro style" have been used synonymously in several places but in reality:

    - Metro style means everything related to building Metro style Windows 8 apps

    - WinRT means only things related to Windows Runtime (which is a new mechanism of creating and consuming components)

    Hope that helps.


    Raman Sharma | Program Manager, Visual C++ | @rasharm_msft

    (if my post has answered your question, please consider using the 'mark as answer' feature in the forums to help others)
    Friday, December 2, 2011 11:36 PM
  • Hi Raman,


    I assume you mean WDK is also part of Windows SDK, so as long as the COM dll uses WinRT compliant APIs from WDK, it should be fine.

    But the COM dlls I have currently have use API that I believe is not WinRT compliant, eg. Registry API, file access API for files that are not residing in local app storage folder etc. So far these APIs seem working fine when the COM dlls are called by a Metro style apps. However, I am not sure whether it is an expected behavior or would MS change this in the future releases.

    Thank you.


    Monday, December 5, 2011 3:19 AM
  • Hi Angela,


    If your DLL's in question are using Win32 API's that are not on the approved Win32 and COM for Metro style apps list, then the component would fail the Windows App Cert Kit check (whitepaper). Meaning the DLL's would not be allowed in a package uploaded to the Store.


    You may want to try this process with your Metro style app to see what (if anything) is missing from your package when it is deployed onto a fresh target. Whatever is in the package is all that will be validated and once passed Store validation, delivered by the Store.

    Tutorial: Creating, testing, and publishing your app (1 of 2)


    If your target does not have the developer tools, you will need this script.




    Thursday, December 15, 2011 1:28 AM
  • Hi David,

    Thank you for your reply. I have tried the App Certification Kit. Indeed that if I package the DLL inside the App package, the certification would fail.

    But as the DLLs are very hardware specific module, it would most likely be packaged inside the driver package instead of the Metro Apps package, just like what is currently being done in our desktop App scenario. So does it mean that the Dll does not need to pass the Certification Kit in this case?

    (Let me try to explain why we do it this way: we have a lot of different hardware that each would require its own specific driver and Dlls to be able to interface with our Apps. The Apps, on the other hand, is generic Apps that show the same set of features on different hardware. Apps can always use the same feature interface to talk to individual hardware specific Dlls, and the Dlls will translate the call to hardware specific driver or directly to the device. That is why our current practice is to package the Dlls inside the driver package but not App package, so that whenever we launch a new hardware, we will release a new set of driver and Dlls package and the existing Apps would just work.)

    Thank you.

    Thursday, December 15, 2011 3:12 AM