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

Answer 1

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.

Answer 2

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

Answer 3

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

Answer 4

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?