Best practice for a multi-target .NET library

Question

I'm planning on releasing an open source (MIT) .NET library, but also including DLLs to make it easy for people so they don't have to compile everything themselves.

My library is very simplistic in the types it references, the only real dependency seems to be .NET 3.0 or higher (since it refers to Func<T> and the like).

I want my library to be usable by multiple targets, including .NET 4.0 server, .NET 3.5 server, Windows Phone 7 Silverlight, normal Silverlight, XNA (Phone), XNA (Windows), and XNA (XBox 360).

I make sure to not use any types that are not available on the platforms I'm targeting, e.g. HashSet<T> isn't available on Windows Phone 7, so I'm not using it.

Will I need to make different projects and thus multiple DLLs for each of these targets or is there some way to produce a common DLL for them all to use?

Answer 1

There was a talk at PDC this year about doing this sort of stuff:

This is the video and these are the slides.

Answer 2

Separate project files with shared, common source files is the way to go. Make sure that the projects are set to build to different output folders (e.g. not \bin\Debug, but \CF\bin\debug) to prevent annoyances when consuming the library from multiple targets (like a desktop and device project).

The OpenNETCF.IoC framework is an example of this - it supports the desktop, CF, Windows Phone and MonoTouch all with the same source files, but separate project files per platform. Trying to compile to a single binary assembly that is usable on all of them was too messy and hard to maintain.

The main pain point here is keeping all of the project files in sync when you add/change files and making sure all of them always compile. A build server can do that if you have access to automation (which Codeplex unfortunately doesn't expose).