I'm building a solution that has 1 component for the Desktop and 1 component
for the Pocket PC. (Though this isn't a mobile question).
I have a data library that will be shared on both platforms. So I've
adopted the approach of having two projects share the same set of files. In
my case, I have two similarly named projects:
DataObjects
DataObjectsCF
The former is for the Desktop app and the latter is for the Compact Framework.
Throughout the many classes shared by these two projects I have some
conditional compilation statements that look like this:
#if (CF)
where 'CF' is used to denote code only for the Pocket PC and conversely
'!CF' is for code only for the Desktop.
I opened up the properties of DataObjectsCF and added the conditional
compilation constant 'CF'. Strangely though, this treated all the files
"looked at" by DataObjects as if I were debugging the Pocket PC app, when
clearly I was working with the Desktop app.
Why is this?
--
Robert W.
Vancouver, BC www.mwtech.com 16  2207 
There is an issue (at least I classify it as such) where if you have two
projects, in the same solution, that are linking to the same file, then when
that file is open the last project that was loaded into the solution will
take precedence over the others and the conditional constants for this
project will be honored as well as intellisense showing information based on
the references of the last project loaded. In short, if you're sharing files
between projects in the same solution, and one project is targeting the full
framework while the other is targeting the compact framework then you may
see issues, as it appears is the case in this situation. The only workaround
that I'm aware of is to place each project into its own solution. It's not
nice but it's better than dealing with the phantom issues of shared files.
The other option in your situation is to code, and compile, your class
library against the compact framework, using only compact framework classes
that also exist in the full framework, and the class library will be usable
on the desktop as it is retargetable.
--
Tim Wilson
..NET Compact Framework MVP
"Robert W." <Ro*****@discussions.microsoft.com> wrote in message
news:ED**********************************@microsof t.com... I'm building a solution that has 1 component for the Desktop and 1
component for the Pocket PC. (Though this isn't a mobile question).
I have a data library that will be shared on both platforms. So I've
adopted the approach of having two projects share the same set of files.
In my case, I have two similarly named projects:
DataObjects
DataObjectsCF
The former is for the Desktop app and the latter is for the Compact
Framework.
Throughout the many classes shared by these two projects I have some
conditional compilation statements that look like this:
#if (CF)
where 'CF' is used to denote code only for the Pocket PC and conversely
'!CF' is for code only for the Desktop.
I opened up the properties of DataObjectsCF and added the conditional
compilation constant 'CF'. Strangely though, this treated all the files
"looked at" by DataObjects as if I were debugging the Pocket PC app, when
clearly I was working with the Desktop app.
Why is this?
--
Robert W.
Vancouver, BC
www.mwtech.com
Tim,
Thank you for your response. I think you've hit the nail on the head
because so-called "phantom issues" seem to be exactly what I'm experiencing
now. They're scary!
With regard to your latter idea, if I were just to code everything for the
CF then I would manually copy the resultant DLL into the WinForms project?
Put another way, how do I force a class library to always compile for the CF?
--
Robert W.
Vancouver, BC www.mwtech.com
"Tim Wilson" wrote: There is an issue (at least I classify it as such) where if you have two
projects, in the same solution, that are linking to the same file, then when
that file is open the last project that was loaded into the solution will
take precedence over the others and the conditional constants for this
project will be honored as well as intellisense showing information based on
the references of the last project loaded. In short, if you're sharing files
between projects in the same solution, and one project is targeting the full
framework while the other is targeting the compact framework then you may
see issues, as it appears is the case in this situation. The only workaround
that I'm aware of is to place each project into its own solution. It's not
nice but it's better than dealing with the phantom issues of shared files.
The other option in your situation is to code, and compile, your class
library against the compact framework, using only compact framework classes
that also exist in the full framework, and the class library will be usable
on the desktop as it is retargetable.
--
Tim Wilson
..NET Compact Framework MVP
"Robert W." <Ro*****@discussions.microsoft.com> wrote in message
news:ED**********************************@microsof t.com... I'm building a solution that has 1 component for the Desktop and 1
component for the Pocket PC. (Though this isn't a mobile question).
I have a data library that will be shared on both platforms. So I've
adopted the approach of having two projects share the same set of files.
In my case, I have two similarly named projects:
DataObjects
DataObjectsCF
The former is for the Desktop app and the latter is for the Compact
Framework.
Throughout the many classes shared by these two projects I have some
conditional compilation statements that look like this:
#if (CF)
where 'CF' is used to denote code only for the Pocket PC and conversely
'!CF' is for code only for the Desktop.
I opened up the properties of DataObjectsCF and added the conditional
compilation constant 'CF'. Strangely though, this treated all the files
"looked at" by DataObjects as if I were debugging the Pocket PC app, when
clearly I was working with the Desktop app.
Why is this?
--
Robert W.
Vancouver, BC
www.mwtech.com
> With regard to your latter idea, if I were just to code everything for the CF then I would manually copy the resultant DLL into the WinForms project?
You would just add the class lib assembly (dll) as a reference and use it as
normal.
Put another way, how do I force a class library to always compile for the
CF?
Place the code to compile in a smart device project. The project would be
set up to compile against the CF.
--
Tim Wilson
..NET Compact Framework MVP
"Robert W." <Ro*****@discussions.microsoft.com> wrote in message
news:86**********************************@microsof t.com... Tim,
Thank you for your response. I think you've hit the nail on the head
because so-called "phantom issues" seem to be exactly what I'm
experiencing now. They're scary!
With regard to your latter idea, if I were just to code everything for the
CF then I would manually copy the resultant DLL into the WinForms project?
Put another way, how do I force a class library to always compile for the
CF?
--
Robert W.
Vancouver, BC
www.mwtech.com
"Tim Wilson" wrote:
There is an issue (at least I classify it as such) where if you have two
projects, in the same solution, that are linking to the same file, then
when that file is open the last project that was loaded into the solution
will take precedence over the others and the conditional constants for this
project will be honored as well as intellisense showing information
based on the references of the last project loaded. In short, if you're sharing
files between projects in the same solution, and one project is targeting the
full framework while the other is targeting the compact framework then you
may see issues, as it appears is the case in this situation. The only
workaround that I'm aware of is to place each project into its own solution. It's
not nice but it's better than dealing with the phantom issues of shared
files. The other option in your situation is to code, and compile, your class
library against the compact framework, using only compact framework
classes that also exist in the full framework, and the class library will be
usable on the desktop as it is retargetable.
--
Tim Wilson
..NET Compact Framework MVP
"Robert W." <Ro*****@discussions.microsoft.com> wrote in message
news:ED**********************************@microsof t.com... I'm building a solution that has 1 component for the Desktop and 1
component for the Pocket PC. (Though this isn't a mobile question).
I have a data library that will be shared on both platforms. So I've
adopted the approach of having two projects share the same set of
files. In my case, I have two similarly named projects:
DataObjects
DataObjectsCF
The former is for the Desktop app and the latter is for the Compact
Framework.
Throughout the many classes shared by these two projects I have some
conditional compilation statements that look like this:
#if (CF)
where 'CF' is used to denote code only for the Pocket PC and
conversely '!CF' is for code only for the Desktop.
I opened up the properties of DataObjectsCF and added the conditional
compilation constant 'CF'. Strangely though, this treated all the
files "looked at" by DataObjects as if I were debugging the Pocket PC app,
when clearly I was working with the Desktop app.
Why is this?
--
Robert W.
Vancouver, BC
www.mwtech.com
Tim,
Sorry to be so dense about this (and Daniel Moth went to great pains to
explain it to me) but I do have another question.
I've removed the extra parallel projects so things were as before. Now ...
one of my top-level projects is called "Pocket PC". My other top-level
project is called "Desktop". Both reference my class libraries,
"DataObjects" and "Multimedia".
In the Pocket PC project I set a compiler constant called "CF". Then in
several places within the two class libraries I have #if (CF), #else, and
#endif statements.
My confusion is this: When I rebuild the Pocket PC project I had *thought*
that it would force the two DLLs to be built as if they were CF DLLs,
recognizing the 'CF' compiler constant. But after rebuilding I've checked
the file sizes and they're identical to when I rebuild the Desktop project.
So the CF constant is obviously not being recognized.
Or is it the case that I have to manually add the CF flag into each DLL's
properties each time before I rebuild Pocket PC? That's possible, of course,
but will be such a nuisance.
Hoping I explained my dilemma well.
--
Robert W.
Vancouver, BC www.mwtech.com
Are you sure that you're still not running into the same issue? Try breaking
all the projects out into there own solutions and build the "common"
assemblies against the CF. So ensure that any class libs that you want to
consume from both the desktop and the device side are built from within a
smart device class library project. Just by building from within a smart
device project you will be targeting the CF. If you have any shared source
files then I'm assuming that this is where you have the #if...#else blocks,
and within a smart device project that contains one of these shared source
files you are defining the CF constant in the project properties. Then you
can add these assemblies as a reference to either a desktop or smart device
project.
--
Tim Wilson
..NET Compact Framework MVP
"Robert W." <Ro*****@discussions.microsoft.com> wrote in message
news:29**********************************@microsof t.com... Tim,
Sorry to be so dense about this (and Daniel Moth went to great pains to
explain it to me) but I do have another question.
I've removed the extra parallel projects so things were as before. Now
.... one of my top-level projects is called "Pocket PC". My other top-level
project is called "Desktop". Both reference my class libraries,
"DataObjects" and "Multimedia".
In the Pocket PC project I set a compiler constant called "CF". Then in
several places within the two class libraries I have #if (CF), #else, and
#endif statements.
My confusion is this: When I rebuild the Pocket PC project I had *thought*
that it would force the two DLLs to be built as if they were CF DLLs,
recognizing the 'CF' compiler constant. But after rebuilding I've checked
the file sizes and they're identical to when I rebuild the Desktop
project. So the CF constant is obviously not being recognized.
Or is it the case that I have to manually add the CF flag into each DLL's
properties each time before I rebuild Pocket PC? That's possible, of
course, but will be such a nuisance.
Hoping I explained my dilemma well.
--
Robert W.
Vancouver, BC
www.mwtech.com
Tim,
I just did as you said. I created a new solution, copied the required CF
related project folder underneath it (Pocket PC, DataObjects, and Multimedia
projects), and then added these projects into the solution. I rebuilt
everything.
Still, I got the same error as before:
An unhandled exception of type 'System.TypeLoadException' occurred in PP.exe
Additional information: Could not load type System.Drawing.Image from
assembly System.Drawing, Version=1.0.5000.0, Culture=neutral,
PublicKeyToken=B03F5F7F11D50A3A.
Maybe my interpretation is incorrect, but I assume this means that the
Multimedia project is STILL being compiled as an X86 WinForms one.
For this project I've pretty much given up on sharing DLL code. The only
fullproof method I've found is to build parallel, often identical, code
within the actual PocketPC project. That obviously compiles as CF-compliant
code whereas *I* can't seem to get it to do so if it's in a DLL ... even if
it's a CF-only solution as you've just instructed me to do.
Frustrating!
--
Robert W.
Vancouver, BC www.mwtech.com
"Tim Wilson" wrote: Are you sure that you're still not running into the same issue? Try breaking
all the projects out into there own solutions and build the "common"
assemblies against the CF. So ensure that any class libs that you want to
consume from both the desktop and the device side are built from within a
smart device class library project. Just by building from within a smart
device project you will be targeting the CF. If you have any shared source
files then I'm assuming that this is where you have the #if...#else blocks,
and within a smart device project that contains one of these shared source
files you are defining the CF constant in the project properties. Then you
can add these assemblies as a reference to either a desktop or smart device
project.
--
Tim Wilson
..NET Compact Framework MVP
"Robert W." <Ro*****@discussions.microsoft.com> wrote in message
news:29**********************************@microsof t.com... Tim,
Sorry to be so dense about this (and Daniel Moth went to great pains to
explain it to me) but I do have another question.
I've removed the extra parallel projects so things were as before. Now
.... one of my top-level projects is called "Pocket PC". My other top-level
project is called "Desktop". Both reference my class libraries,
"DataObjects" and "Multimedia".
In the Pocket PC project I set a compiler constant called "CF". Then in
several places within the two class libraries I have #if (CF), #else, and
#endif statements.
My confusion is this: When I rebuild the Pocket PC project I had *thought*
that it would force the two DLLs to be built as if they were CF DLLs,
recognizing the 'CF' compiler constant. But after rebuilding I've checked
the file sizes and they're identical to when I rebuild the Desktop
project. So the CF constant is obviously not being recognized.
Or is it the case that I have to manually add the CF flag into each DLL's
properties each time before I rebuild Pocket PC? That's possible, of
course, but will be such a nuisance.
Hoping I explained my dilemma well.
--
Robert W.
Vancouver, BC
www.mwtech.com
Just out of curiosity (and to learn)
Why not create 3 common classes, one for shared code, one for the CF and
one for the normal framework?
-Mark
--
Sent via .NET Newsgroups http://www.dotnetnewsgroups.com
Mark,
I'm certainly not the expert here, but when I looked at this, I discovered
so many required cross references that I didn't know if it would work
correctly. But maybe somebody else on here might have some more experienced
views on your question.
--
Robert W.
Vancouver, BC www.mwtech.com
"Mark Nijhof" wrote: Just out of curiosity (and to learn)
Why not create 3 common classes, one for shared code, one for the CF and
one for the normal framework?
-Mark
--
Sent via .NET Newsgroups
http://www.dotnetnewsgroups.com
Let me try to get my head around what you're doing a little better. You have
two class library projects that each output a dll (assembly) - DataObjects
and Multimedia - correct? You need to use both of these dlls on the desktop
and on a device, correct? I assume that both of these projects are smart
device projects? Do you have any code that is shared between these projects?
--
Tim Wilson
..NET Compact Framework MVP
"Robert W." <Ro*****@discussions.microsoft.com> wrote in message
news:61**********************************@microsof t.com... Tim,
I just did as you said. I created a new solution, copied the required CF
related project folder underneath it (Pocket PC, DataObjects, and
Multimedia projects), and then added these projects into the solution. I rebuilt
everything.
Still, I got the same error as before:
An unhandled exception of type 'System.TypeLoadException' occurred in
PP.exe
Additional information: Could not load type System.Drawing.Image from
assembly System.Drawing, Version=1.0.5000.0, Culture=neutral,
PublicKeyToken=B03F5F7F11D50A3A.
Maybe my interpretation is incorrect, but I assume this means that the
Multimedia project is STILL being compiled as an X86 WinForms one.
For this project I've pretty much given up on sharing DLL code. The only
fullproof method I've found is to build parallel, often identical, code
within the actual PocketPC project. That obviously compiles as
CF-compliant code whereas *I* can't seem to get it to do so if it's in a DLL ... even
if it's a CF-only solution as you've just instructed me to do.
Frustrating!
--
Robert W.
Vancouver, BC
www.mwtech.com
"Tim Wilson" wrote:
Are you sure that you're still not running into the same issue? Try
breaking all the projects out into there own solutions and build the "common"
assemblies against the CF. So ensure that any class libs that you want
to consume from both the desktop and the device side are built from within
a smart device class library project. Just by building from within a smart
device project you will be targeting the CF. If you have any shared
source files then I'm assuming that this is where you have the #if...#else
blocks, and within a smart device project that contains one of these shared
source files you are defining the CF constant in the project properties. Then
you can add these assemblies as a reference to either a desktop or smart
device project.
--
Tim Wilson
..NET Compact Framework MVP
"Robert W." <Ro*****@discussions.microsoft.com> wrote in message
news:29**********************************@microsof t.com... Tim,
Sorry to be so dense about this (and Daniel Moth went to great pains
to explain it to me) but I do have another question.
I've removed the extra parallel projects so things were as before.
Now .... one of my top-level projects is called "Pocket PC". My other
top-level project is called "Desktop". Both reference my class libraries,
"DataObjects" and "Multimedia".
In the Pocket PC project I set a compiler constant called "CF". Then
in several places within the two class libraries I have #if (CF), #else,
and #endif statements.
My confusion is this: When I rebuild the Pocket PC project I had
*thought* that it would force the two DLLs to be built as if they were CF DLLs,
recognizing the 'CF' compiler constant. But after rebuilding I've
checked the file sizes and they're identical to when I rebuild the Desktop
project. So the CF constant is obviously not being recognized.
Or is it the case that I have to manually add the CF flag into each
DLL's properties each time before I rebuild Pocket PC? That's possible, of
course, but will be such a nuisance.
Hoping I explained my dilemma well.
--
Robert W.
Vancouver, BC
www.mwtech.com
Tim,
By asking me whether "both projects are smart device projects", which 2
projects are you referring to? "Pocket PC" is definitely a smart device
project but "Desktop" is a WinForms project.
There is no code shared between "DataObjects" and "Multimedia".
By end goal/hope here is to find a simple (and safe) way to be able to use
each of DataObjects and Multimedia within each of Desktop and Pocket PC.
Currently I can use some of the methods in each but things fail on the Pocket
PC if I try to use things like Images and DataSets.
--
Robert W.
Vancouver, BC www.mwtech.com
"Tim Wilson" wrote: Let me try to get my head around what you're doing a little better. You have
two class library projects that each output a dll (assembly) - DataObjects
and Multimedia - correct? You need to use both of these dlls on the desktop
and on a device, correct? I assume that both of these projects are smart
device projects? Do you have any code that is shared between these projects?
--
Tim Wilson
..NET Compact Framework MVP
Ok. So let's go back and talk about the options. You have two ways to
approach this. In both situations you may want to think about how these
projects relate to each other. A solution is intended to group related
projects together. I assume by the fact that you stated that the DataObjects
project and the Multimedia project are not sharing code that these projects
are not really related. So you may consider placing each of the projects
into a separate solution - so that the DataObjects project is in one
solution by itself and the Multimedia project is in another solution by
itself. Then, to ensure that you don't run into any phantom issues you may
also want to place the Pocket PC project into it's own solution and Desktop
project into it's own solution as well. In total you would have four
projects and four solutions. This doesn't sound ideal but it could save you
some more frustration down the road. Now lets get to the options...
(1) You could build the DataObjects project and Multimedia project as smart
device class library projects. This would ensure that the resulting dll is
compiled against the CF. And, assuming that you're not using anything device
specific like the InputPanel component, then these assemblies will also be
usable on the desktop. One issue that you may run into, however, is that VS
may attempt to automatically pull in references when you add these
assemblies to the Desktop project. But I'm just going off of memory here. If
VS doesn't cause issues when adding a reference to the assemblies in your
Desktop project then this is the way that I'd go as it seems more logical to
share assemblies rather than share, or copy, code.
(2) You can create two project for each class lib. One for the desktop and
one for the device. So, and again understanding the phantom issues, you
would create a solution for the desktop DataObjects project and a solution
for the desktop Multimedia project and you would also create a solution for
the device DataObjects project and another solution for the device
Multimedia project. That's a lot of solutions, but what you could do is then
link the code into the projects between the desktop and device versions.
This may have been what you were doing before. At this point you would
differentiate any device and desktop specific code with conditional
compilation, defining the conditional compilation constants (or symbols) in
the appropriate project. This way would ensure that you are seeing proper
syntax highlighting as well as intellisense. Then you would add the correct
assembly (device or desktop) to the appropriate project (Pocket PC or
Desktop). This option gives you flexibility to add extra functionality that
is dependent on the full framework but yet share the bulk of the code
between the desktop and the device.
I guess it's up to you which one you choose, but if you don't need to do
anything specific to either the desktop or the device then I would attempt
the first option. If you do get jerked around by VS (which from memory is a
possibility when you attempt to add the assembly built against the CF as a
reference to the Desktop project) then the second option becomes the last
resort.
--
Tim Wilson
..NET Compact Framework MVP
"Robert W." <Ro*****@discussions.microsoft.com> wrote in message
news:46**********************************@microsof t.com... Tim,
By asking me whether "both projects are smart device projects", which 2
projects are you referring to? "Pocket PC" is definitely a smart device
project but "Desktop" is a WinForms project.
There is no code shared between "DataObjects" and "Multimedia".
By end goal/hope here is to find a simple (and safe) way to be able to use
each of DataObjects and Multimedia within each of Desktop and Pocket PC.
Currently I can use some of the methods in each but things fail on the
Pocket PC if I try to use things like Images and DataSets.
--
Robert W.
Vancouver, BC
www.mwtech.com
"Tim Wilson" wrote:
Let me try to get my head around what you're doing a little better. You
have two class library projects that each output a dll (assembly) -
DataObjects and Multimedia - correct? You need to use both of these dlls on the
desktop and on a device, correct? I assume that both of these projects are smart
device projects? Do you have any code that is shared between these
projects?
--
Tim Wilson
..NET Compact Framework MVP
Tim,
Thanks for your patience with me on this, I do appreciate it. The next time
you're in Vancouver, please give me a shout and I'll give you a great tour of
what was just ranked as the #1 city in the world. Anyhow ...
You've given me lots of food for thought. But I need to ask you something
about Option #1. You said, "You could build the DataObjects project and
Multimedia project as smart device class library projects." I think I must
be missing something because I just double-checked and these are the options
I have available to me in Visual Studio 2003:
Windows Application
Class Library
Windows Control Library
Smart Device Application
OpenNETCF Application
Etc.
But there is no "Smart Device Class Library" project option available. Is
there perhaps some "trick" I need to know about, such as creating a "Smart
Device Application" and then removing the default form, thus leaving me with
the equivalent of a class library?
Most curious,
--
Robert W.
Vancouver, BC www.mwtech.com
"Tim Wilson" wrote: Ok. So let's go back and talk about the options. You have two ways to
approach this. In both situations you may want to think about how these
projects relate to each other. A solution is intended to group related
projects together. I assume by the fact that you stated that the DataObjects
project and the Multimedia project are not sharing code that these projects
are not really related. So you may consider placing each of the projects
into a separate solution - so that the DataObjects project is in one
solution by itself and the Multimedia project is in another solution by
itself. Then, to ensure that you don't run into any phantom issues you may
also want to place the Pocket PC project into it's own solution and Desktop
project into it's own solution as well. In total you would have four
projects and four solutions. This doesn't sound ideal but it could save you
some more frustration down the road. Now lets get to the options...
(1) You could build the DataObjects project and Multimedia project as smart
device class library projects. This would ensure that the resulting dll is
compiled against the CF. And, assuming that you're not using anything device
specific like the InputPanel component, then these assemblies will also be
usable on the desktop. One issue that you may run into, however, is that VS
may attempt to automatically pull in references when you add these
assemblies to the Desktop project. But I'm just going off of memory here. If
VS doesn't cause issues when adding a reference to the assemblies in your
Desktop project then this is the way that I'd go as it seems more logical to
share assemblies rather than share, or copy, code.
(2) You can create two project for each class lib. One for the desktop and
one for the device. So, and again understanding the phantom issues, you
would create a solution for the desktop DataObjects project and a solution
for the desktop Multimedia project and you would also create a solution for
the device DataObjects project and another solution for the device
Multimedia project. That's a lot of solutions, but what you could do is then
link the code into the projects between the desktop and device versions.
This may have been what you were doing before. At this point you would
differentiate any device and desktop specific code with conditional
compilation, defining the conditional compilation constants (or symbols) in
the appropriate project. This way would ensure that you are seeing proper
syntax highlighting as well as intellisense. Then you would add the correct
assembly (device or desktop) to the appropriate project (Pocket PC or
Desktop). This option gives you flexibility to add extra functionality that
is dependent on the full framework but yet share the bulk of the code
between the desktop and the device.
I guess it's up to you which one you choose, but if you don't need to do
anything specific to either the desktop or the device then I would attempt
the first option. If you do get jerked around by VS (which from memory is a
possibility when you attempt to add the assembly built against the CF as a
reference to the Desktop project) then the second option becomes the last
resort.
--
Tim Wilson
..NET Compact Framework MVP
In VS.NET 2003 the smart device wasn't quite as much of a first class
citizen as it is in VS 2005. You should select the "Smart Device
Application" project template. Once you proceed to create the project,
another dialog will appear asking which platform you want to target and with
what project type. It is at this point that you select "Pocket PC" in the
first listbox and then select "Class Library" in the second listbox.
--
Tim Wilson
..NET Compact Framework MVP
"Robert W." <Ro*****@discussions.microsoft.com> wrote in message
news:6C**********************************@microsof t.com... Tim,
Thanks for your patience with me on this, I do appreciate it. The next
time you're in Vancouver, please give me a shout and I'll give you a great tour
of what was just ranked as the #1 city in the world. Anyhow ...
You've given me lots of food for thought. But I need to ask you something
about Option #1. You said, "You could build the DataObjects project and
Multimedia project as smart device class library projects." I think I
must be missing something because I just double-checked and these are the
options I have available to me in Visual Studio 2003:
Windows Application
Class Library
Windows Control Library
Smart Device Application
OpenNETCF Application
Etc.
But there is no "Smart Device Class Library" project option available. Is
there perhaps some "trick" I need to know about, such as creating a "Smart
Device Application" and then removing the default form, thus leaving me
with the equivalent of a class library?
Most curious,
--
Robert W.
Vancouver, BC
www.mwtech.com
"Tim Wilson" wrote:
Ok. So let's go back and talk about the options. You have two ways to
approach this. In both situations you may want to think about how these
projects relate to each other. A solution is intended to group related
projects together. I assume by the fact that you stated that the
DataObjects project and the Multimedia project are not sharing code that these
projects are not really related. So you may consider placing each of the projects
into a separate solution - so that the DataObjects project is in one
solution by itself and the Multimedia project is in another solution by
itself. Then, to ensure that you don't run into any phantom issues you
may also want to place the Pocket PC project into it's own solution and
Desktop project into it's own solution as well. In total you would have four
projects and four solutions. This doesn't sound ideal but it could save
you some more frustration down the road. Now lets get to the options...
(1) You could build the DataObjects project and Multimedia project as
smart device class library projects. This would ensure that the resulting dll
is compiled against the CF. And, assuming that you're not using anything
device specific like the InputPanel component, then these assemblies will also
be usable on the desktop. One issue that you may run into, however, is that
VS may attempt to automatically pull in references when you add these
assemblies to the Desktop project. But I'm just going off of memory
here. If VS doesn't cause issues when adding a reference to the assemblies in
your Desktop project then this is the way that I'd go as it seems more
logical to share assemblies rather than share, or copy, code.
(2) You can create two project for each class lib. One for the desktop
and one for the device. So, and again understanding the phantom issues, you
would create a solution for the desktop DataObjects project and a
solution for the desktop Multimedia project and you would also create a solution
for the device DataObjects project and another solution for the device
Multimedia project. That's a lot of solutions, but what you could do is
then link the code into the projects between the desktop and device versions.
This may have been what you were doing before. At this point you would
differentiate any device and desktop specific code with conditional
compilation, defining the conditional compilation constants (or symbols)
in the appropriate project. This way would ensure that you are seeing
proper syntax highlighting as well as intellisense. Then you would add the
correct assembly (device or desktop) to the appropriate project (Pocket PC or
Desktop). This option gives you flexibility to add extra functionality
that is dependent on the full framework but yet share the bulk of the code
between the desktop and the device.
I guess it's up to you which one you choose, but if you don't need to do
anything specific to either the desktop or the device then I would
attempt the first option. If you do get jerked around by VS (which from memory
is a possibility when you attempt to add the assembly built against the CF as
a reference to the Desktop project) then the second option becomes the
last resort.
--
Tim Wilson
..NET Compact Framework MVP
Dear Tim (& Others):
I just discovered this: http://flimflan.com/blog/PermaLink,g...757f2a721.aspx
This is EXACTLY what I've been going through!!! I now understand what I've
done wrong, what a smart device class library is (and how to create one).
Lots of rework to do, but at least the problems are now starting to make
sense, rather than be great big mysteries!!!
--
Robert W.
Vancouver, BC www.mwtech.com
Tim,
Just to let you know ... I've now gone back and replaced my Multimedia.dll
with a Smart Device Class Library of the same name. And lo and behold
everything works ... including much original code that I had written that
"mysteriously" didn't work when I moved it from my CF project into the DLL.
Now it's no longer a mystery why!
I also just tested using this new & improved DLL in my Desktop project. It
seems to work fine. Later this week I'm going to start porting DataObjects,
which is much bigger, over to CF compliant code as well. I'll be most
interested to see whether it works okay with DataSets.
I'm just kicking myself that not until now did I know about Smart Device
Class Libraries. I should have investigated that further way back when.
I do have a lingering question for you: Is there ANY downside to my Desktop
app using the CF DLL? I mean, I realize that I'll have to write some special
code to compensate for missing features like SortedList, for example, but
having one set of source code rather than two copies of the same thing (which
rarely remain identical over time) is worth it for me. But are there any
other downsides that you can think of?
--
Robert W.
Vancouver, BC www.mwtech.com
> I do have a lingering question for you: Is there ANY downside to my
Desktop app using the CF DLL? I mean, I realize that I'll have to write some
special code to compensate for missing features like SortedList, for example, but
having one set of source code rather than two copies of the same thing
(which rarely remain identical over time) is worth it for me. But are there any
other downsides that you can think of?
Other than what you stated about needed to reconstruct missing features in
the CF, I can't really think of a downside. It should just work. And if
you're ok with limiting yourself to CF-only types and members than it may be
easier to just deal with this one dll, rather than one for the desktop and
one for the device.
--
Tim Wilson
..NET Compact Framework MVP
"Robert W." <Ro*****@discussions.microsoft.com> wrote in message
news:7D**********************************@microsof t.com... Tim,
Just to let you know ... I've now gone back and replaced my Multimedia.dll
with a Smart Device Class Library of the same name. And lo and behold
everything works ... including much original code that I had written that
"mysteriously" didn't work when I moved it from my CF project into the
DLL. Now it's no longer a mystery why!
I also just tested using this new & improved DLL in my Desktop project.
It seems to work fine. Later this week I'm going to start porting
DataObjects, which is much bigger, over to CF compliant code as well. I'll be most
interested to see whether it works okay with DataSets.
I'm just kicking myself that not until now did I know about Smart Device
Class Libraries. I should have investigated that further way back when.
I do have a lingering question for you: Is there ANY downside to my
Desktop app using the CF DLL? I mean, I realize that I'll have to write some
special code to compensate for missing features like SortedList, for example, but
having one set of source code rather than two copies of the same thing
(which rarely remain identical over time) is worth it for me. But are there any
other downsides that you can think of?
--
Robert W.
Vancouver, BC
www.mwtech.com This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Simon Neve |
last post by:
Hello,
This question is related to sharing .Net projects across solutions and is
reposted from the SourceSafe group.
We have several different solutions and want to share common assemblies...
|
by: cybertof |
last post by:
Hi !
What is the common use of sharing a single .cs across multiple project
files ?
I think it's to share common classes between projects.
I have actually a .cs file shared accross multiple...
|
by: JoeS |
last post by:
Is there anyway to share a single pch file between
projects in VC 7.0? I have 300+ projects each of which
creates its own pch. All projects include the exact same
header files in the precompiled...
|
by: Daniel |
last post by:
Hi!
I have several projects (approx 50) that includes basically the same
files such as <atlcom.h> and <comdef.h>. The projects are set up to
use a precompiled header wich includes these header...
|
by: Chris Morse |
last post by:
Hi,
I am creating a solution with two projects. Basically, they share a
few common class files and forms. I finished one project, and it
compiles and runs fine. I just finished bringing in...
| | |
by: Ron L |
last post by:
I have an application that I am developing that is a front end for a SQL
database. We will also be developing a subset of the UI that will work as a
(mainly) standalone client that will make a...
|
by: Andrew E Chapman |
last post by:
I have a VB.NET class library project and two other VB.NET projects that
depend on that class library, ie:
Class library
--Project 1
--Project 2
Currently, as you'd expect, when I compile...
|
by: Magnus Bergh |
last post by:
I have a solution which contains multiple projects (different
applications). Every project use the same typed dataset (and also a few
other shared code files).
I tried to remove the dataset.xsd...
|
by: Jeff Dege |
last post by:
I'm working with a group that's been doing C++ coding for quite a long
time, now, and in that environment we've pretty much worked out
development practices that serve us well.
We've been doing...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
| | |
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
| | |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
