Metro-style App + Import library + Static library RRS feed

  • General discussion

  • I am having a Win32 DLL with import library and a static library that I would like to use with a Metro-style app.  I have looked into various post on MSDN forums, but I found various conflicting information. I would be thankful if someone points me to the official documentation OR MSFT people can post answers to following questions:

    1) Do I need to create the new Metro-style DLL project? OR The same project would work if I don't use the restricted APIs?

    2) Do I need to set the configuration for "Metro-style App Support" in the project configuration while building the library?

    3) I was using the import libs to include this DLL in the application project. Will the same method would work with Metro-style application?

    4) Do I need to package the DLL and import lib in the Metro-style app package? OR Putting the DLL in some known location in the file system and using import lib to open the same would work?

    5) I have a static library. It does not use any of the C runtime library functions. Will I be able to link Metro-style application with this static library?


    Wednesday, March 7, 2012 2:34 PM

All replies

  • 1) Yes.

    2)No, if no WinRT API used.

    3)Yes, just as  native one.



    Correct me if my understanding is not correct.

    Friday, March 9, 2012 2:16 PM
  • @Cheribum_Lee

    Great job responding with the information provided.


    Could you elaborate on your objective? Are you wanting your component to be a WinRT component, which is then consumable across the languages? If not, then your component would only be available from .NET using P/Invoke or C++ using LoadPackagedLibrary if the DLL was included in your package.

    David Lamb

    Friday, March 9, 2012 5:01 PM
  • @Cheribum_Lee,

    Thanks for the reply. However, I am not sure in answers (1) and (4), "Yes" is refering to which part of the question.


    I have few Win32 DLL projects. These projects are used by the C++ desktop application using import libs. I don't use .NET or any other managed code funtionality in desktop application or DLLs. It is pure C++ coding making use of Win32 APIs. Now, I would like to create a new Metro-style application that uses these DLLs in similar way as the desktop application is using it currently.

    First step toward this would to make these DLL projects compatible with Metro-style app in-order to use them. To do this, I have opened the project in VS2011 and upgraded the platform tool set to v110. Now, I am not sure about other changes required.

    1) Do I need to package this DLL in Metro-app package. OR I can open open this DLL even when they are somewhere in file system.

    2) What is the purpose of "Metro-style App Support" option in the project configuration? How does it affects the DLL generation or DLL internals?

    3) Is there any other changes or project settings required in order to use these DLLs in Metro-style apps?

    4) How to build static library, that can be included into Metro-style app?

    • Edited by U__K Friday, March 9, 2012 6:03 PM
    Friday, March 9, 2012 5:48 PM
  • If you haven't seen this talk, you may find it helpful in understanding how to bring your code forward. Specifically starting at 23:50 into this talk.

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

    1) Yes, it needs to be in the App package

    2) Steve Horne will be responding to this.

    3) Depends. If your keeping it a Native DLL, no. The above talk should help you understand your options. This is assuming your only using the allowed API calls and not referencing anything else that isn't permitted.

    4) Steve Horne will be responding to this

    David Lamb

    Saturday, March 10, 2012 12:43 AM
  • As Cherubim_Lee noted in his minimalist style :) If your code isn't going to be changed such that you add ref classes or ref new against WinRT classes then you don't need to make any changes beyond updating the toolset to v11 (static code can't be mixed across compilers, so it's a very bad mistake to link a v10 static lib with v11 code). You should also add the WINAPI_FAMILY=WINAPI_PARTITION_APP preprocessor define to ensure you aren't calling any unsupported api.

    The "Metro Style App Support" switch adds the <Immersive>true</Immersive> property to the vcxproj file. This isn't doc'd that I know of but it's a 'meta' property that throws the /ZW and supporting (/GM-, /ZW:nostdlib) switches during the build (take a look at the cl tlog files generated). It is turning on the C++/CX support in the compiler so you can implement ref new classes and consume WinRT libraries with ref new. If you don't need to do that then it's not a "Metro static lib", it's just a static lib that you are linking to a Metro app.

    /ZW code can consume non /ZW code so there is no problem calling your library from a Metro app -- your code just can't cross the ABI boundary.


    Saturday, March 10, 2012 1:24 AM
  • David Lamb, Steve Horne,

    Thank you very much for your replies. I have some follow-up questions related to your posts.

    1) As stated, I need to package DLL in Metro-style app package in order to use it in Metro-style app. As per above post, I need to only change the platform tool set to v11 if I don't use WinRT classes. Now, when I generate a DLL and import lib throuth VC++ project, how does the generated import lib know whether to use LoadLibrary or LoadPackagedLibary?

    I have heard that import libs simplifies the usage of DLL by removing the need of LoadLibrary and GetProcAddress from the application. Now, as an independent VC++ DLL project, how does the Visual Studio know whether this library would be used in destkop app or metro-style app? Wouldn't it need some indication in order to generate the import library code which uses LoadPackagedLibary?

    I am not sure how the import libraries written. But, was curious if we don't indicate how would they find out which function to use for loading a DLL.

    2) In one of the project, I am using SetupDi and CreateFile Win32 APIs. Now, I need to update this project to use Windows.Devices.Enumeration namespace and CreateDeviceAccessInstance in place of SetupDi and CreateFile respectively. So, for this project I need to specify "Metro Style App Support". Correct? I don't need to create a new Metro-DLL project and import code, just making this option enable would be sufficient. Correct?

    3) For device enumeration, the API returns the IAsyncOperation. The sample Metro-style app uses the Concurrency::task namespace. However, I need to code the same thing in DLL. I was able to include the Windows.Devices.Enumeration namespace, but Concurrency namespace was not found. Can't we use the Concurrency namespace in DLL? Is any project setting related to Metro-style app support missing?


    • Edited by U__K Tuesday, March 13, 2012 4:10 PM
    Tuesday, March 13, 2012 3:04 PM
  • For 1), statically bound DLLs (i.e. you link to the .LIB file generated when you build the DLL) are loaded very different from dynamically loaded DLLs. For a dynamic load, you will use LoadLibrary/LoadPackagedLibrary, for statically bound dlls, the loader loads the DLLs when it loads the EXE and resolves jump addresses in the import address table. This looks like a pretty good explanation - http://sandsprite.com/CodeStuff/Understanding_imports.html.

    The short answer is, don't worry about it when linking with a .LIB file for a DLL. The loader will do the right thing whether it's Metro or non-Metro.

    2) Yes, that should be sufficient. This is a DLL, right? It looks like all of your questions in the last post are referring to DLL projects.

    3) Did you include the ppltasks.h header file? This is where you'll find the concurrency::task class. PPL is a library that was released with VS2010, it's been updated with continuations and support for Metro but you can still use it from native code so there is no Metro C++/CX compilation requirements. Just include the right header files.


    Tuesday, March 13, 2012 11:44 PM
  • Steve,

    Thanks for the detailed reply.

    Friday, March 23, 2012 6:52 PM
  • I described by use-case below. Then I posted 4 questions. It will be very helpful if I get some expert suggestions. Thanks in advance.

    I have an existing C++ library built as static in VS2008 (call it MyCnx.lib). It uses WinSock Win32 api calls and thus has dependency on winsock2.h and related header files (such as ws2def.h qos.h Ws2tcppip.h Iphlpapi.h). I "converted" my project and solution from VS2008 to VS2011 Beta and the build failed with error message that it cannot find winsock2.h file (even though the Win8 SDK was already installed). I downloaded Microsoft SDK 6.0A and installed it on the Win8 Consumer Preview environment and the build and link succeeded, provided I added:
    C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include
    C/C++ / General / Additional Include Directories:

    I also included the preprocessor flag: WINAPI_FAMILY=WINAPI_PARTITION_APP

    Qs 1: Will this MyCnx.lib work, if I build my desktop application on Win8?

    QS 2: Will this MyCnx.lib work from a new C++ Metro Style app on Win8 on x86 hardware? If not, what requirements does MyCnx.lib must meet?
    [(a) In some threads, I see existing Win32 api calls must be replaced by now new api's from WinRT library.
    (b) In the Build video by Jason Olson, PLAT 877T, it seems, a "thin" layer of public functions with WinRT conventions (ref in class declarations), which would call native functions in existing legacy library, would suffice the job]

    Qs 3: Repeat Qs 2, for ARM hardware.

    QS 4: Repeat Qs 2, for a C# (not C++) Metro Style app on Win8 on ARM hardware.

    Thanks again.

    Monday, April 23, 2012 3:53 AM
  • Please create new threads rather than re-opening old ones. An old answered thread with new posts won't generally bubble up and be noticed.

    After installing and using any SDK other than the Windows 8 SDK I can't say what your app will do. The Win8 SDK is the only one which is WINAPI_FAMILY aware so by installing the older SDK you've made the compiler and linker happy but likely included non-Metro safe api calls. You need to build the library with Win8 SDK headers and libraries _only_ and replace any API calls not supported under Metro style with equivalent WinRT functionality for Metro style support.

    Q2b - yes that is one good design for Metro style targeting.

    Once you're using only Win8 and Dev11 libraries you should get ARM support for free.

    Wednesday, April 25, 2012 11:49 PM
  • I got some questions about

    5) I have a static library. It does not use any of the C runtime library functions. Will I be able to link Metro-style application with this static library?

    For my case,  RT component DLL is the interface to the metro application. RT component DLL links against my static library. I added WINAPI_FAMILY=WINAPI_PARTITION_APP into my static library project file. Build is ok. So before I continue, I want to make sure:

    a) Can my static library uses C runtime library?

    b)  How do I know if my static library is using C runtime library.


    rob qqq

    Tuesday, August 28, 2012 11:25 PM
  • I find the setting for b).  Could anyone answer my question a)?

    rob qqq

    Thursday, August 30, 2012 6:48 PM