Hi,
I made exactly that - several times. Here are my experiences and
suggestions.
1) Of course you have to limit your usage of the .NET Framework to the
common subset of both.
2) In my components I avoid to have _any_ GUI stuff in the components that I
share among .NET and .NETCF. I guess you should avoid having any GUI stuff
in your libraries, too. The GUI is what makes the platforms so different. So
leave that to the platform specific application and outside of commonly used
libraries.
3) You must test thoroughly on both frameworks because there are some subtle
differences (Some that I found and remember: String.Replace(string,string)
with newValue=null works on big .NET as documented but leads to exception on
..NETCF; HttpWebResponse is IDisposable and must be disposed in big .NET but
does not even implement IDisposable in .NETCF; etc...). Expect to find quite
a few of such small compatibility glitches.
4) If you encounter a serious incompatibility, or even have to do some
P/Invoke stuff (which is almost always different), it is probably best to
use some conditional compilation (in C#: #if / #else / #endif). I don't know
whether there is any officially suggested symbol for .NETCF, I just define
and use WINCE and bracket platform dependend code with #if WINCE / #else
/#endif. IMHO: Visual Studio should define some platform symbol in all Smart
Device Projects by default.
5) The resulting binary .dll of a build is not fully portable across .NET
and .NETCF. It is in some cases (.NETCF builds should work on full .NET 1.1)
but not in the general case.
6) Therefore, you must make two completely separate builds. One as a Smart
Device Application project (although it will only be a library), and another
as a Class Library project (always assuming you will use Visual Studio).
Both builds can be made from the same source code though.
7) To organise these builds, perhaps the best solution is to use
VisualSourceSafe. There you can create two separate project branches and
share all common source code between these branches. Thus you can be sure
that both builds are always made from the same source code. Do not share the
project files .csdproj and .csproj as these are different. Also I do not
share the AssemblyInfo.cs as I use that to mark my builds differently. To do
so, you will have to use VisualSourceSafe through its own GUI and disable
the VSS integration in Visual Studio which always messes things up if you
have shares. (Interestingly the old pre-.NET Visual Studio was able to
handle this. The new VisualStudio.NET VSS integration got much worse and is
better switched off completely)
Final advice: The complete .NET reference documentation is obviously made
from the full .NET framework (and development team) and there is no _real_
documentation of the .NETCF. Therefore it often contains information that is
plain wrong for the .NETCF. So take care and test a lot.
Good luck!