Windows Phone app fails static validation. Image file format is not supported.


Once you are done developing your app, you will submit it to the Windows Phone Marketplace. After you upload your application, it will immediately undergo static code analysis  to ensure that you have complied with the Marketplace guidelines when developing your application. This is a formality that goes through the basic requirements so you can fix any glaring errors up front without having to wait for the manual review.


I recently tried to submit an update for an existing app, when I get the following error


“Image file format is not supported”. <filepath omitted> 2014.


This was a new one for me, since this app has already gone through the initial submission as well as an app update. The error message had me focused on the actual file, rather than the real issue (I accidently switched the tile image and background image, full artwork guidelines). In reading other posts troubleshooting the static validation step, the answer jumped out at me.

Use the Marketplace Test Kit. In Visual Studio, right click the Windows Phone Application project and choose Open Marketplace Test Kit.




The first page in the wizard is going to require you to upload the images for the Marketplace. Although you can skip this step, I would encourage you to take the two seconds to upload your images because

  1. Your entries are saved so you don’t have to repeat this step next time you run the test
  2. Your error report is more accurate because the image errors aren’t clogging up your report



The next tab is where the real magic is. Automated Tests of your application, packaging, and marketplace submission are provided when you install with Windows Phone SDK. Each test case output goes beyond just pass/fail and includes things like capabilities, description of resources being loaded, and detailed error messages. If you weren’t listening and didn’t upload your images, you can expect to see images similar to mine.



Once I ran this tool, my mistake became very obvious and it was no problem to fix it. Once again, if the marketplace error message is at all ambiguous, RUN the Marketplace Test Kit. Two minutes later and ….



Mature Your Process with Continuous Integration

Continuous Integration is a software development practice where members of a team integrate their work frequently. Each integration is verified by an automated build to detect integration errors as quickly as possible.

Software teams can benefit from Continuous Integration for both coordination and automation. We'll be discussing the people that can and should participate in CI, the processes that we can implement and then automate, and look at the technology that makes all of this possible. I've attached the presentation I gave at the CapArea .NET User Group on Nov 16, 2009.



Identifying Duplicated Code with Continuous Integration

As part of my continuous improvement campaign, I have been adding additional processes to our continuous integration server so our team can ensure high code quality.

One issue I have seen is that developers do not take enough time to read each other’s code. This leads to duplicate code that then needs to be maintained in multiple places. Sometimes this is just a one-off, sometimes this is a trend, you need to decide for your project. Practices like code reviews and pair programming can minimize this. There are many tools that can do the mechanical review as well.

The most popular commercial tool is Simian. However, for my project I am using Duplicate Finder, which is open-source software. These tools will scan your source code, not object code, so access to the source code is required. The reports that are generated can help you identify cut & paste programming, or common constructs that can be refactored.

Anthony Steele (the developer of Duplicate Finder) recently integrated changes into the tool to provide an XML output perfect for use with CruiseControl.NET. I've created two Xsl files that integrate the Xml reports in both summary form and detail (with file name and line number).

To integrate them into your CruiseControl.NET dashboard

  1. Unzip them both to <cruisecontrol install directory>\webdashboard\xsl
  2. Modify the dashboard.config file in <cruisecontrol install directory>\webdashboard\ as follows
    1. Add the following line <xslFile>xsl\DuplicateReportSummary.xsl</xslFile> to dashboard/plugins/buildPlugins/buildReportBuildPlugin/xslFileNames
    2. Add the following line <xslReportBuildPlugin description="Duplicate Code Report" actionName="DuplicateBuildReport" xslFileName="xsl\DuplicateReport.xsl" /> to dashboard/plugins/buildPlugins/

sha1: 29d5ae55db98db86ebf01d3e8bfd88f15c53b3a4