Have you personally run into problems sharing code
No. But then again I haven't really had a whole lot of need to do this.
The CF (Compact Framework) team modeled the namespaces, classes, etc. to
mimic the FF (Full Framework). So you'll notice lots of similarities between
the FF and CF. This was absolutely by design. This allows devs to leverage
their knowledge between the two frameworks. But keep in mind that the CF
emphasizes the word "compact". So the CF is a subset of the FF. If you look
at the documentation you'll notice the statement "supported by the .NET
Compact Framework" on certain members (now I must warn you that the docs are
not 100% accurate, particularly with the event members). This gives you an
idea of what you can and cannot use between CF and FF. So in your code
example, the "HasChildren" property would not compile against the CF since
it's not supported. But you could always just check the Count of the
Controls collection. So there are usually work arounds. You'll just need to
find the combination that works for both the CF and FF and then compile that
in a project against the CF.
The reason that I implied that it's best not to share UI related code is
mostly for two reasons:
(1) The form factor of a device (like a Pocket PC or Smartphone) is
drastically different from a typical desktop computer display. So the UI is
pretty much a rewrite anyways.
(2) Through the designer, the generated resx files for Forms are not
compatible between FF and CF projects.
So there's nothing wrong with having utility methods to perform tasks on
controls, but you'll want to ensure that you have different projects, one
for the FF and one for the CF, so that you can more easily define proper
UI's.