Didn't really consider this aspect till I started building my solution...
To simplify, my application exposes an API to be used by other applications. The API is conceptually comprised of two parts: "Action" classes, and data type objects. Each of these is in its own project.
(I'm not asking now about class design, that's a whole separate issue - there are good reasons for this.)
Now, one of the main reasons these are in separate assemblies, is that internally they are used very separate from each other: the data types ARE used internally, extensively - however, the action classes are simply the public face of the application, and NOT used internally at all.
So far, all was good, it all made sense...
Then I started plugging in the API, and realized - calling apps would need to reference TWO assemblies, instead of just the one, in order to use the API.
So what would be the best move here?
Reeeheely hoping for something new in the area of 3...
Can you not build a 3rd Assembly that contains the API to be consumed? This will reference the 2 working assemblies and provide a single entry point for 3rd parties?
UPDATE:
Based on the conversation in the comments and thinking this through, I absolutely agree with what Avid is trying to do, it does make things cleaner having a single dll, but as long as its documented and works it doesnt really matter that much. Once its referenced it's referenced. Developers will soon figure this out. I would certainly not try and add additional build steps to merge things to get around this. (This is just my opinion)
To answer the question I would go with option No. 1 in the original post.