locked
WinRT component using static library

    Question

  • Hi,

    We are planning to have  static library (Metro style) that

    1)Consumes WinRT API

    2)Consumes another standard C++ static library

    3)Defines/Authors new WinRT components (i.e public ref classes) to be utilized by Metro app (C++/XAML)  to which this lib is linked.

    Is this supported (especially 3)? Would there be any issues with this approach?

    Also, how does the Metro app link to C++ runtime library in this case (MT static/MT Dll)? Please advise

    Thursday, August 09, 2012 10:09 PM

Answers

  • The goal of C++/CX is to serve as an interop layer between C++ and other WinRT languages (XAML, JS, etc). You shouldn't use C++/CX in places in your app there you could use standard C++. Standard C++11 provides modern constructs to achieve similar or higher simplicity than C++/CX provides on top of WinRT/COM: use shared_ptr rather than raw pointers whenever you can, use lambdas to improve the readability of your code, use PPL tasks and continuations to turn expensive operations into async operations, etc.

            > Regarding (3) - I have actually tried  by defining a public WinRT class in a static library and was able to successfully use from exe ( to which it is linked).

    You would be able to get something working, the problem is maintaining it in a working state. The way COM works, you would often end up authoring public types in your static library that are not referenced anywhere else in your final binary. When that happens, Linker will decide to exclude that code from the final binary. While Linker will do the same thing for C++ native types, it is less common that you wouldn't reference the C++ type anywhere else in the project that consumes the static lib.

           > Can the function parameters include STL classes (string, vector, etc)  as well?

    Yes, as long as you make sure that the static lib and the consuming project are compiled with the same compiler version and you don't use different compiler switches that could affect the signature and layout of the STL classes (the default project templates for static libs that are part of VS are a very good start).

    Thanks,
    Marian Luparu
    Visual C++

    Tuesday, August 14, 2012 10:42 PM
  • Hello,

    (1) Consuming WinRT components from a static library is supported.

    (3) Authoring new WinRT components in a static library and linking + consuming them in another exe/dll is not a supported scenarios for VS 2012. Linker will issue a warning during build advising against this.

    One can ignore the warning and still continue to author public classes in the lib. But because of how Linker treats .lib files, you can run into scenarios where your 'public ref class' implementation will be missing from your final binary while the winmd file generated by the Linker at a previous step will still contain all their definitions. These leads to hard-to-diagnose errors that we'd like to keep developers away from.

    Thanks,
    Marian Luparu
    Visual C++

    • Marked as answer by Jesse Jiang Friday, August 24, 2012 7:03 AM
    Monday, August 13, 2012 11:57 PM

All replies

  • Hi,


    Regarding the usage of c++ static libs there already some threads
    please have a look
    http://social.msdn.microsoft.com/Forums/en-US/winappswithnativecode/thread/0fa0695f-9828-46ac-985b-5ca15f3bee0a

    Regarding runtime library(CRT) :

    If your lib links to a Metro style app compliant C runtime you will be able to call standard C functions such as fopen.
    You can test against the App Cert Kit to confirm. Runtimes older than VC 2012 's will not work.

    Thanks,
    Bhash

    • Proposed as answer by Jesse Jiang Monday, August 13, 2012 9:12 AM
    • Marked as answer by Jesse Jiang Friday, August 24, 2012 7:02 AM
    • Unmarked as answer by Jesse Jiang Friday, August 24, 2012 7:02 AM
    Friday, August 10, 2012 12:54 PM
  • I have checked existing threads before  posting this query. And did not find any definitive answer, specifically for item (3). Please suggest.
    Monday, August 13, 2012 11:14 AM
  • Hello,

    (1) Consuming WinRT components from a static library is supported.

    (3) Authoring new WinRT components in a static library and linking + consuming them in another exe/dll is not a supported scenarios for VS 2012. Linker will issue a warning during build advising against this.

    One can ignore the warning and still continue to author public classes in the lib. But because of how Linker treats .lib files, you can run into scenarios where your 'public ref class' implementation will be missing from your final binary while the winmd file generated by the Linker at a previous step will still contain all their definitions. These leads to hard-to-diagnose errors that we'd like to keep developers away from.

    Thanks,
    Marian Luparu
    Visual C++

    • Marked as answer by Jesse Jiang Friday, August 24, 2012 7:03 AM
    Monday, August 13, 2012 11:57 PM
  • Hi Marian,

    Great thanks for the reply.

    As a follow up, just a couple more clarifications, please:

    Regarding (3) - I have actually tried  by defining a public WinRT class in a static library and was able to successfully use from exe ( to which it is linked). But based on  your response, I understand that even though it works in few cases - we could run into scenarios where this would not work and hence is not recommended/supported. Is that correct?

    Hence, in this case, the only way to make use of a static library in exe/dll is through native C++ classes/methods. Can the function parameters include STL classes (string, vector, etc)  as well? Based on these, my metro app needs to use WinRT API (default or new WinRT classes) only for:

    ->UI integration (XAML)

    ->functionality, that can't be achieved using supported native API .

    otherwise every thing else can be plain C++ or supported Win32 API as in a normal Win32 application.

    Please confirm.

    Thank you in advance.

    Ram





    Tuesday, August 14, 2012 4:10 PM
  • The goal of C++/CX is to serve as an interop layer between C++ and other WinRT languages (XAML, JS, etc). You shouldn't use C++/CX in places in your app there you could use standard C++. Standard C++11 provides modern constructs to achieve similar or higher simplicity than C++/CX provides on top of WinRT/COM: use shared_ptr rather than raw pointers whenever you can, use lambdas to improve the readability of your code, use PPL tasks and continuations to turn expensive operations into async operations, etc.

            > Regarding (3) - I have actually tried  by defining a public WinRT class in a static library and was able to successfully use from exe ( to which it is linked).

    You would be able to get something working, the problem is maintaining it in a working state. The way COM works, you would often end up authoring public types in your static library that are not referenced anywhere else in your final binary. When that happens, Linker will decide to exclude that code from the final binary. While Linker will do the same thing for C++ native types, it is less common that you wouldn't reference the C++ type anywhere else in the project that consumes the static lib.

           > Can the function parameters include STL classes (string, vector, etc)  as well?

    Yes, as long as you make sure that the static lib and the consuming project are compiled with the same compiler version and you don't use different compiler switches that could affect the signature and layout of the STL classes (the default project templates for static libs that are part of VS are a very good start).

    Thanks,
    Marian Luparu
    Visual C++

    Tuesday, August 14, 2012 10:42 PM
  • Great Thanks. This would help me to get started...
    Thursday, August 16, 2012 6:49 AM