locked
LNK4264: Why are static libraries not recommended when authoring Windows Runtime types

    Question

  • When creating a static library with /ZW I get the following warning:

    "warning LNK4264: archiving object file compiled with /ZW into a static library; note that when authoring Windows Runtime types it is not recommended to link with a static library that contains Windows Runtime metadata"

    In my static library I would like to create a class along the lines of:

    public ref class MyClass sealed
    {
    };

    I would then like to link this in to my main app which creates a XAML component.

    Why is this not recommended?

    The response to this question suggests that what I'm trying to do isn't supported at all. Why not?

    http://social.msdn.microsoft.com/Forums/en-US/winappswithnativecode/thread/d042f2d9-0552-4163-804f-11dfcbe1d204?prof=required

    Friday, August 31, 2012 8:31 AM

All replies

  • Li Shao previously wrote:

    "The reason for the linker warning is that for static lib, we support for WinRT consumption but not authoring. Since linker does not have a way to tell between these two cases, the warning will always be given."

    public ref class MyClass sealed
    {
    };

    is an example of authoring a WinRT class, which Li Shao says is not supported.

    Now authoring WinRT classes can be done in a "Windows Runtime Component" project.  And that project can be used by C# and JavaScript.  The C++ static library, on the other hand, would be difficult (impossible?) to use from C# and JavaScript.  I don't know if Microsoft had a technical reason why C++ static libraries could not be used to author WinRT classes, or if it just was not deemed to be a requirement.  But in any case, the guidance would be to use a  "Windows Runtime Component" project for your "sealed" "ref" class.

    Hope this helps until an official response appears.

    Sunday, September 2, 2012 2:52 AM
  • I mentioned some of the technical reasons behind not supporting static libs with WinRT types in this forum post: http://social.msdn.microsoft.com/Forums/en-US/winappswithnativecode/thread/b9c8a6d0-d6e8-4300-ab04-ef42a332d92f

    Marian

    • Proposed as answer by Jesse Jiang Monday, September 3, 2012 8:18 AM
    • Unproposed as answer by D.G.Thomas Tuesday, September 11, 2012 7:54 AM
    Sunday, September 2, 2012 11:09 PM
  • Hi Marian,

    Thanks for your answer. This makes a fair amount of sense, but I'm still not quite sure why you would be less likely to reference WinRT components from your main executable, than native C++ code.

    Thanks,

    David

    Monday, September 3, 2012 12:52 PM
  • So it seems that if I want to provide reusable C++ code that uses both WinRT types and Native types, I need to divide it into two projects;

      • A static library project with /ZW for all functions and classes that use native types like std::wstring in public methods.
      • A Windows Runtime Component for all "public ref classes"

     And the reasons that require this division are:

    1.  The compiler will raise an error if a Windows Runtime component has a type such as std::wstring as a return type or parameter in a public method.
    2. Authoring new WinRT components in a static library and linking + consuming them in another exe/dll is not a supported scenarios for VS 2012.

    It looks to me like the C++ documentation is missing two sections in http://msdn.microsoft.com/en-us/library/hh875012

    1. "Using Static Libraries for WinRT applications".   
    2. "Using DLLs for WinRT applications".

    I found it odd that no .lib was created from a newly created DLL for Metro apps project.  Isn't there a use case for creating a .DLL which also has a .lib?

    Tuesday, September 4, 2012 2:52 AM