Library projects can have various types of bundle resources (storyboards, xibs, property lists, png images, CoreML models, texture atlases, etc - the _BundleResourceWithLogicalName item group), and they're bundled into the compiled library as embedded resources (using a prefix, like __monotouch_content_) - in the PackLibraryResources task.

If any processing can be done (such as compiling storyboards or xibs, or optimizing property lists/png images, etc), it's done before embedding, but this complicates library builds a lot, because they:

• Need to execute on a Mac, because compiling xibs/storyboards can only be done on a Mac.
• Need Apple's toolchain around.
• Makes it impossible to do any decision-making based on the original resources when building the app.

The last part is important because of conflicting resources (#5755) - if the executable app ends up with multiple xcassets with the same name from multiple library projects (or a library project and the executable project), it's impossible to merge them post-compilation (while it could be done if we had access to all the original resources when compiling the executable project).

So the suggestion would be to add support for bundling original assets in libraries, by adding a new MSBuild property BundleOriginalLibraryAssets, and make the default value true.

Unfortunately there may have been a reason it was done this way originally, but that potential reason has been lost in history. This means that we must support opting out of this behavior for a while.

Advantages:

• Library projects can be built on any platform, there's no need for Apple's toolchain (no remoting needed from Windows for instance).
• Library projects will build faster.
• We can include library assets in any decision making when building the executable project (such as merging assets from multiple sources).