mixing compact and winform code

  • Thread starter Thread starter Hans Kesting
  • Start date Start date
H

Hans Kesting

Is it possible to mix code meant for the CompactFramework and
code meant for the standard framework?

We are trying to make PDA and light-weight "laptop" versions of
one application. This means a lot of functionality is identical
(or at least similar).
As the compact framework is a subset (correct?) of the full
framework, we had the idea of building the base functionality
as "compact" projects. Thse projects could then be used
(or extended) by both the PDA and laptop versions.

However! We run into several problems. The compact "System.dll"
is copied to the run directory (even though "copy local" is
set to "false"), which leads to problems when a standard
application tries to access it's (standard) System.dll.

Is it even possible to build such "shared projects" and did we
just miss some setting, or should we separate these projects
into "pure compact" and "pure laptop" (with all consistency problems)

Hans Kesting
 
Hans,
The way I did it was to create the SmartDevice project, then I could use
the binary exe on the desktop and the PPC. AFAIK, you'd only get the
system.dll copied if you chose one that is a different version than what's
in the GAC. Have you tried deleting the one in your run dir to see if
there's really a dependency on it?
 
Floyd Burger said:
Hans,
The way I did it was to create the SmartDevice project, then I could use
the binary exe on the desktop and the PPC. AFAIK, you'd only get the
system.dll copied if you chose one that is a different version than what's
in the GAC. Have you tried deleting the one in your run dir to see if
there's really a dependency on it?
Click to expand...

I never explicitly *chose* a system.dll, but it gets copied when I use
Compact classes
in a "desktop" project. The system.dll is the "Compact Framework" one.
When I stay within one solution, it seems to work. However, when I try to
reference
my dll from another solution, then I get a warning "this will change where
system.dll
is found". The warning is accurate because then I get lots of problems with
incorrect versions.

Temporary solution:
copy all *our* dll's to a separate directory and reference from there. As
there is
no invalid system.dll, the problems do not occur.

Hans Kesting
 
Back
Top