Best practice for a multi-target .NET library_问答_开发者

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 diffe开发者_JAVA百科rent 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?

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

This is the video and these are the slides.

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).

I do something similar with a library that targets .NET and Silverlight. I have a single set of source files and separate project files that link to the same shared files.

Sometimes I use conditional compilation to include features just for .NET and not Silverlight, or to take advantage of features available in .NET that lead to a nicer implementation and a fall back implementation for Silverlight where it has gaps.

The same approach could be used for the other platforms you mention - one set of source files, but a separate project file per platform target.

If you use a build tool like MSBuild or NAnt, you can then have the build produce all the DLLs for all target platforms when you run the script.

Look at the Portable Library Tools (Last Updated: 6/17/2011) extension from BLC Team (Microsoft) and this introduction MSDN article (Last Updated: August 2011).

I would suggest a library for each of the platform. Let me explain.

Let's say the full .NET Framework includes a bunch of features, methods that are not part of the .NET Compact Framework as the one you may find with Windows CE and smartphones. So, in order to fully take advantage of the full load of possibilities of each platform, I would leverage a common library plenty of interfaces, then you implement those interfaces within a .NET Framework platform specific class library that will allow you to take fully advantage over what is offered on a specific platform.

On the other hand, if common reuse of code, and for the sake of maintainability, you might prefer to go with a single "do-them-all" library. Under such requirements, you will need to be fully aware of each of the differences between the many platforms you wish to support.

This is obviously an important analysis and architecture question, as of both will suffer the lacks of one platform over the other.

Here's how I would proceed in front of such a situation:

I would investigate the differences between the platform specific .NET Framework;
I would put aside all (as needed) the common objects you think you might need;
I would highlight the differences, that is, objects you can use under one platform, but not the other;

This is an organic analysis you will have to perform in order to see what's coming up next.

That is, for a some sort of Waterfall approach.

As for a Scrum approach, if I may say so as this suggests empiricism, I would say try a single common library for them all, and see what you can do. If you come across some things you absolutely cannot do, then it might be relevant to only create another class library which would depend on your "do-them-all" library so that you have a common block for each platform, then some other specific libraries for what you can't do in the common. Do so, and see what advantages you got from it, and find a way out of trouble when comes the time to be more specific.