Best practice for cross-platform mono project layout when using native dll's

Question

I am looking for best practices for a portable C# project that runs on multiple platform. In my case I have different wrapper dll's for each platforms providing interface/classes, etc. Whereas thy are the same on each platform I still need to reference the corresponding dll on each platform. What are best practices in such a case?

I could use conditional references in the C# project file (with the technique described here). Then I would require to know if I am on Linux, Windows or OS X. How would I do that?

Another option is to create a separate project for each platform. But then I have code redundancy because I have to implement each interface/inheritance for each platform. While the implementation is identical they derive from de facto different types coming from different assemblies (though they are the very same when using them).

What are possible strategies in this case and what are the advantages or downsides?

Answer 1

I have done something like that some time ago. I do not know if one should consider my way as best practice, but it worked for me:

I did opt for the "separate project for each platform" approach (only MS-.net and MonoDroid for me at the moment), but worked around code duplication by simply putting both .csproj files into the same folder. I then added the code files used in the first project to the second one.

I tiptoed around any inconsisencies in the dependencies of my code by inserting conditionals, which I subsequently added to the according csproj.

The only notable downside of this approch is, that one gets frequent complaints from Visual Studio if reopening a file (by double-clicking in project explorer) in the second project, that is already opend via the first one (implying both are added to the same solution, as I did). But these notifications seemed to do no harm and I was able to happily code away.

Imho this slight annoyance is preferable to the trouble it would cause to have the same code in two places. Maybe this could be mitigated by keeping the code together in a proper source control system like Git (e.g. on two different branches), but as the multi-csproj approach worked so well for me, I did not try anything down that route.