How can I toggle my VS 2008 solution's target platform between Windows CE and Winforms?

Question

I'm in the process of porting a legacy Windows CE / Compact Framework project from VS 2003 in XP Mode with .NET 1.1 to VS 2008 and .NET 3.5

As debugging is such a pain trying to target a handheld device (there is no emulator for the specific device I'm targeting, a Motorola 3190), I want to toggle my project between targeting Windows CE and Winforms (I will debug it as a Winforms app normally, periodically setting it to Windows CE so as to build and download to the device). How can I do that? I don't see now how Visual Studio knows the project is a Windows CE / CF project.

It does, because Project Properties has a Devices tab, and when I F5, an emulator (kind of a generic one) is invoked.

But on the project properties Application tab, the Target Framework dropdown is blank and grayed out. Output type is Windows application. I would think Target Framework would be set to Windows CE or some such. Obviously it is set somewhere, but where? How can I toggle between it being run as a CE / CF and as a "plain old" Winforms project?

Selecting Project > Change Target Platform does show "Windows CE" as the current value, but the "Change to:" dropdown only contains:

Pocket PC 2003
Windows Mobile 5.0 Pocket PC SDK
Windows Mobile 5.0 Smartphone SDK
Windows Mobile 6 Professional SDK

The project properties Devies tab has many more options in the "Target device:" dropdown, but seemingly nothing of value for me.

If I unload the project and select "Edit bla.csproj, I see the following entries in that .csproj file:

<NativePlatformName>Windows CE</NativePlatformName>
. . .
<PlatformFamilyName>WindowsCE</PlatformFamilyName>
. . .
<Reference Include="Microsoft.WindowsCE.Forms">
  <Name>Microsoft.WindowsCE.Forms</Name>
</Reference>
. . .
<Import Condition="'$(TargetFrameworkVersion)' == 'v3.5'" 
Project="$(MSBuildBinPath)\Microsoft.CompactFramework.CSharp.targets" />

...and possibly at least one of these is of import here (no pun intended), but if so, what should I change it to, and if I should change it, should I change it directly, or indirectly? If the latter, how?

UPDATE

Trying to add all the *.cs and *.resx files to a Winforms project, and attacking the duality that way, I get the following error on some, but not all of my *.resx files:

Invalid Resx file. ResX input is not valid. Cannot find valid "resheader" tags for the ResX reader and writer type names.

What does that mean? The solution here C# resx file error: doesn't seem to apply to my situation, as the out-of-kilter / off-the-rails files already have this format:

<resheader name="resmimetype">
  <value>text/microsoft-resx</value>
</resheader>

Answer 1

I do not do this anymore (see *note at bottom), but I used to keep all of my various projects under one solution.

• I had my Main MDI application project.

• I had 3 small, single form projects (one on the server, and 2 different label printing applications)

• There were 2 Windows Mobile projects (one called Packout, and one called Inspections)

These projects already share their file locations on my PC where I have a folder called Common with classes that are used in all of the whole solution.

Take the Database.cs class shown above: Whether my project is an MDI Form, a stand alone form, or a Windows Mobile application, they are generally all going to connect to the same company database.

Instead of adding the file to your project (which makes a copy of the file, and places the copy in your project), add the file as a link:

I must admit: I never noticed the Add button was a Drop-Down until ctacke pointed it out to me years ago.

Now, whenever you edit this Database.cs file in one project, it will automatically be updated in all other projects that have it linked.

Warning!

This does present issues, though!

Sometimes you NEED things in your Windows Forms that Windows Mobile just does not support. Sounds crazy, but it's true. Windows Mobile just won't do it all. So, instead of being stuck writing all of your classes for the weakest link (Windows Mobile), include some #define statements in your class.

Below is a screenshot of a WM5 project that now has System.ComponentModel commented out of the code because the BackgroundWorker control is not defined in Windows Mobile:

What does this do for you?

Now you can have multiple projects within your solution. Depending upon which one you want to test your code on, just Right-Click that project, and select Set as StartUp Project.

Now you can test and develop for a Windows Form application for basic code or whatever emulator you prefer (as long as it isn't one of those icky iPhones and Android devices), then switch back to your old Company Clunker for final testing and fine tuning.

*Since we got VS2010 and VS2012, I have not been able to keep all of my projects under one solution. Most of the files, however, are still linked to the separate projects.