Open asklar opened 3 years ago
Bringing them into the same static libraries adds the possibility for collision though. E.g. we would probably try to end up linking a whole bunch of different cppwinrt versions together.
I didn't say static libraries though :) vcxitems would just be loose source files that would get linked into the app project, using the app project cppwinrt package and headers.
How would we bring in transitive dependencies? Similarly would we see any compat issues from app code library changes affecting the modules?
This would make it more difficult to consume a C++ module from C# (since you still need a C++ library/app to consume the source from). There could be an "aggregator" library that pulls in the C++ modules distributed as source.
Building modules as individual libraries carries some penalties, both at build time (everything needs to be linked and resolved), as well as deployment-wise and at runtime (whole separate PE image, prevents folding with like code in the app binary).
For native modules that are distributed as binary, this seems inescapable. However for modules that are source-distributed, a proposal would be to distribute them as vcxitems projects that get statically linked into the app.