Thursday, August 09, 2012 10:09 PM
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
Friday, August 10, 2012 12:54 PM
Regarding the usage of c++ static libs there already some threads
please have a look
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.
- Proposed As Answer by Jesse JiangMicrosoft Contingent Staff, Moderator Monday, August 13, 2012 9:12 AM
- Marked As Answer by Jesse JiangMicrosoft Contingent Staff, Moderator Friday, August 24, 2012 7:02 AM
- Unmarked As Answer by Jesse JiangMicrosoft Contingent Staff, Moderator Friday, August 24, 2012 7:02 AM
Monday, August 13, 2012 11:14 AMI 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:57 PM
(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.
- Marked As Answer by Jesse JiangMicrosoft Contingent Staff, Moderator Friday, August 24, 2012 7:03 AM
Tuesday, August 14, 2012 4:10 PM
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.
Thank you in advance.
Tuesday, August 14, 2012 10:42 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).
Thursday, August 16, 2012 6:49 AMGreat Thanks. This would help me to get started...