Of Visual Studio, Device Projects, Resources, and MSBuild

Quite a title, isn’t it?  This post is going to help a lot of frustrated Pocket PC developers out there!  Note: Everything I document here is probably good for CF 2.0 and 3.5.  I’m using 3.5 so keep your eyes open.

By default, Compact Framework Pocket PC Application Projects (.exe) compile in a hi-resolution resource that either enables or disables proper scaling.  I haven’t figured that piece out, and I don’t really care because I had to make my application hi-res aware anyway when I was trying to figure this piece out.

Now, this is fine and dandy and transparent until you want to compile in important resources such as, oh, the File Version that you would see on the Version tab in the file’s properties (Right Click -> Properties).

For most CF applications, this is not a problem.  The AssemblyVersion attribute will still be placed inside the binary and usable once you load the binary.  However, let us not forget that the Compact Framework doesn’t allow us to unload a binary (and the Desktop Framework barely allows that).

So what is a Pocket PC / SmartPhone developer supposed to do?  We want to check the binary’s version, but we can’t!

Some have found solutions.  But they either involve 1. compiling in new resources manually or 2. changing your PlatformFamilyName to WindowsCE.  This can be done within the project manually by opening your project and replacing:

<PlatformFamilyName>PocketPC</PlatformName>

With:

<PlatformFamilyName>WindowsCE</PlatformName>

Which is jolly good until you get these ridiculous warnings:

warning VSD102: The type Microsoft.WindowsCE.Forms.HardwareButton is not supported in this platform.
warning VSD102: The type Microsoft.WindowsCE.Forms.Notification is not supported in this platform.

Then, as an intelligent developer, you do what comes naturally: you try to suppress those warnings.  Except you can’t!  /nowarn does not work with VSD102!  It only works with CS-prefixed warnings!

Oh noes!

Well, lucky for you, I’ve been dicking around with the failure that is MSBuild all day.  I also found this page that details a lot of retardedness going on at the Visual Studio For Devices team.  It mentions this “platform verification” nonsense and says that the way to stop it is to manually edit %windir%\Microsoft.NET\Framework\[version]\Microsoft.CompactFramework.Common.Targets.

“NO!” I say.  That will not do.  I’m using a compile server that I don’t have control of.  And NO I will not reproduce your stupid targets file.

A little digging around in that file, however, finds this little gem that had plagued me for a month when I was looking into hi-resolution stuff:

<PropertyGroup>
<ShouldAddHighDPIResource Condition=”‘$(TargetExt)_and_$(HighDPIResAware)_and_$(Win32Resource)’==’.exe_and_true_and_'”>true</ShouldAddHighDPIResource>
<ShouldAddHighDPIResource Condition=”‘$(TargetExt)_and_$(HighDPIResAware)_and_$(Win32Resource)_and_$(PlatformFamilyName)’==’.exe_and__and__and_PocketPC'”>true</ShouldAddHighDPIResource>
<ShouldAddHighDPIResource Condition=”‘$(TargetFrameworkVersion)’==’v1.0′”>false</ShouldAddHighDPIResource>
</PropertyGroup>

<Target
Name=”AddHighDPIResource” Condition=”‘$(ShouldAddHighDPIResource)’==’true'”>
<AddHighDPIResource
Win32Resource=”$(Win32Resource)”
ApplicationIcon=”$(ApplicationIcon)”
OutputDirectory=”$(IntermediateOutputPath)”>
<Output TaskParameter=”Win32Resource” PropertyName=”Win32Resource” />
<Output TaskParameter=”ApplicationIcon” PropertyName=”ApplicationIcon” />
</AddHighDPIResource>
</Target>

Try googling HighDPIResAware.  You don’t find anything except a plagiarized build script.  But this is the key to all of our problems.  All you have to do is set this property to something, anything in your project file and you are good to go.  No platform warnings, no changing platforms, no hi-resolution resource crap compiling in without your consent.

tl;dr:

<PropertyGroup>
<HighDPIResAware>1</HighDPIResAware>
</PropertyGroup>

Half of the important terms in this article were not indexed by Google, so I hope to have helped a the few Pocket PC developers still out there who care.  Because problems relating to this issue have probably used more of my time than any other .NET CF issue.

Trackback/Pingback (1)

  1. Building .netcf with TeamCity | Elegant Code on Friday, July 31, 2009 at 4:02 pm

    […] http://throwachair.com/2008/10/09/of-visual-studio-device-projects-resources-and-msbuild/ […]