Proposal: More robust handling of dynamic/static libs in winmdgenerator

[riverar]

Summary

The winmdgenerator requires import libraries to generate Windows Metadata describing APIs that reside in both dynamic-link and static libraries. Import libraries are not generally available for static libraries, requiring some additional acrobatics and potentially an additional sidecar project to create an otherwise unused dynamic-link library.

I propose we change winmdgenerator to not require import libs for static library scenarios and instead handle these libraries directly. That is, rather than scan import libraries for matching symbols and then do an awkward remapping to static libraries, we instead read the static libs directly and if a symbol match is found, emit the StaticLibraryAttribute et al.

The project file schema will also need some tweaking, to accommodate.

Before:

<ImportLibs Include="..\..\target\$(Platform)\$(Configuration)\component.lib">
  <StaticLibs>component=static_component</StaticLibs>
</ImportLibs>

After:

<StaticLibs Include="..\..\target\$(Platform)\$(Configuration)\static_component.lib" />

Scope

Capability	Priority
Generate Windows Metadata with functions annotated with DllImport and/or StaticLibrary attributes	Must
Generate Windows Metadata for static libraries using a MSBuild Project (.proj)	Must
Generate Windows Metadata for import libraries using a MSBuild Project (.proj)	Must

[mikebattista]

@sotteson1 do you agree with the proposal?

[sotteson1]

I see what you mean, although in the current implementation, you don't need the static lib to exist for it to work. Also, instead of making a new element, we could have ImportLibs work with both DLL and static libs and detect the difference and do the right thing depending on what it sees. @wravery, what do you think? (Since you were the one who introduced static libs into the emitter.)

[wravery]

Sounds good to me, although I'd like to keep supporting a single winmd for scenarios where both already exist (e.g. WebView2). Can we do it in a way that supports both a standalone static lib and a static lib as an alternative to the DLL? That way we keep the fallback for libraries that include both and projections that don't do static linking.

[riverar]

@wravery I added a table to the original post to cover some requirements. If I understood correctly, you'd like to continue scanning both import/static libs and emit both DllImport and StaticLibrary attributes on functions in the metadata.

[wravery]

Yes, I'd like to have support for either, or both attributes in the same winmd.

[riverar]

Stale and my use case vanished, so closing for now. We can revive this when we have new scenarios that need it.