Asked by:
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:
- 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.
- 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
- "Using Static Libraries for WinRT applications".
- "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