Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles
(untagged)

UltraDynamo (Part 5) - Building, Code Signing and Packaging

0.00/5 (No votes)
14 Jan 2013 1  
In this section we will take a look at what is required to build, sign and package the application.

Table Of Contents

Note: This is a multi-part article. The downloads are available in Part 1.

Introduction

In this section we will take a look at the various steps I have employed for building, code signing and packaging the application.

There are things that are covered here, that will probably not use again as part of this project, but all provided towards the learning experience, so have been included for reference. 

Code Signing Certificates 

All applications to the Intel AppUp store had to be code signed. This meant it was a requirement to obtain a suitable code signing certificate from a recognised certificate provider. It was allegedly possible to obtain a free certificate through Comodo via the Intel AppUp program. After registering for the Intel AppUp program at http://software.intel.com/[^] they provide a link to click on your dashboard;

Giving up on Comodo 

I went through the required process. submitted the relevant forms, sent the appropriate legal documents, however despite numerous emails from them they failed to contact me via telephone to validate me.

The emails they sent all asked the same thing, they were each responded to in the same way. They kept asking for me to register my details in directory services like 192 and BT, despite them being there anyway as I am not ex-directory. If they had only cared to check after each response, before asking again. Even the screenshots from the websites being emailed to them failed to convince them I had done what they asked. Overall it was a shocking service.

Good Times With GlobalSign  

Time was pressing during the Comodo saga and as we were timebound for the competition entries I decided to go and obtain my own code signing certificate from GlobalSign[^]. The process with them was much smoother. Supplied the required forms, scnas of the the legal documents (such as passport and driving license) and after receiving an email to arrange a time for them to contact me, I received the phonecall and the process was complete. They issued a certificate for me to download from their website. After downloading the certificate to a folder on my computer and armed with the relevant keyphrase for the certificate, which I generated during the order process, I could now code sign the application. 

Manual Code Signing

After building the application in the usual way, I knew where to locate the EXE file for signing. To sign the EXE it was a case of issuing the following command at the command prompt;

"C:\Program Files (x86)\Windows Kits\8.0\bin\x86\signtool.exe" sign /f "C:\Users\Dave\Desktop\Code Signing Certificate\OS201210309376.pfx" /p <certificate_keyphrase> /t http://timestamp.verisign.com/scripts/timstamp.dll "C:\Users\Dave\Documents\Visual Studio 2012\Projects\UltraDynamo\UltraDynamo\bin\Release\UltraDynamo.exe"

As you can see there are a few things to note:
1: sign = tells the command to sign the file
2: /f = tells the command to sign using the following certificate file
3: /p = the value following this is the keyphrase for the certificate. Replace with your own.
4: /t = tells the code signing tool where to get the timestamp data. Without this, the application would not run beyond the expiration date of the certificate.

To find out more about all the various options (over and above the ones used), visit here: http://msdn.microsoft.com/en-us/library/8s9b9yaz(v=vs.110).aspx[^]

Now, if you had to run this everytime things would get tedious. Thankfully we have Build Events!

Signing Using Build Events

The build events allow you specify commands to run against the various build configurations. For example, I do not want to code signing when I am running Debug Builds only when I am building for Release.

Opening up the project properties, you will see the Build Events tab, in here you can then specify the commands to run. You will notice that there are a couple of macros used. The 'If' instruction checks to see if the $(ConfigurationName) equals 'Release' and then the file to sign is the $(TargetPath).

The full command in the build event looks like;

if $(ConfigurationName) == Release (

"C:\Program Files (x86)\Windows Kits\8.0\bin\x86\signtool.exe" sign /f "C:\Users\Dave\Desktop\Code Signing Certificate\OS201210309376.pfx" /p <certificate_keyphrase> /t http://timestamp.verisign.com/scripts/timstamp.dll "$(TargetPath)"

) 

I am sure there is further command I can add into the build events that take care of the packaging, but haven't got round to that yet. Yes, a job for another day!

Following code signing, if you navigate to the EXE in explorer, and right-click and select properties, you will now see a  "Digital Signatures" tab. It will now contain details from your certificate. You can select the item, click the 'Details' button and view the certificate in even more detail; 

Packaging

Packaging up the application opened up a whole new avenue of problems.  

InstallShield Limited Edition

Visual Studio 2012 comes with a limited edition of InstallShield. You first have to download the product and register to obtain your license key. That was the easy bit. It then just got a whole lot more confusing.

You first have to add a new Setup and Deployment project to your solution;

After this you can use the Project Assistant to step through and enter the various details required to build the deployment project.

However, I still found it a requirement to manual go through a tweak the various settings on each of the numbered panes in the solution explorer and actually build the project and test the install to make sure everything was working fine and installing and uninstalling cleanly without any error.

It was important on the #6 Prepare for Release | Release page to enter the path to the code signing certificate and set the keyphrase. This ensures that the setup executable and the internal installer package are both code signed using your certificate.

After many setting changes and building and executing tests to get a working deployment package without errors I ran into the first real stumbling block. The Intel AppUp store required that the application submission package was an *.msi (Microsoft Installer) named file. No matter where I looked I could not find anything in the setup and deployment options of InstallShield that I could create just the msi file and not package it into an setup executable.

This is where I turned to little workaround dubbed the double install. The first thing to do is install the application on a computer as normal. Next empty the contents of the Temp folder used by the installer. You do not have to do this but makes it easier to locate which folder is created by the installer. then run the installer again. You are presented with an alert error to notify you that the application is already installed. At this point you can navigate to the temp folder and grab a copy of the extracted msi file from the generated folder with a random GUID, e.g. C:\Users\Dave\AppData\Local\Temp\{A62723F8-A894-43E5-8BDD-29306F4DBDC5}).

Having grabbed the MSI file, I could then upload this onto the AppUp site for the validation progress to commence.

This is where the next problem began. My Application had passed validation, both MetaData and Binary validation and had been published. However, Intel got back in touch with me to say that the shortcuts were not Advertised Shortcuts and to this day still haven't got a clue what this means or how or if it could be fixed in InstallShield.

Intel fortunately gave me some pointers on using WIX to package the application. So, it was time to learn something else!

Goodbye InstallShield, Hello WIX!

Intel provided me with an internal tool called MSICreatorAlpha which used Wix (Windows Installer XML Toolset) to package up the application. A requirement for the tool was to grab the latest version from the Wix Homepage at: http://wixtoolset.org/[^]

Having grabbed the latest version and installing it, I fired up the Intel tool, and let it do its thing. However, the tool didn't really generate the correct install path I wanted and added extra layers of directory structure. What the tool did though is produce a template of the required Wix file that I edited to suit my needs. The XML file that I tailored for my use is shown below (UltraDynamo.wxs);

<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.microsoft.com/wix/2006/wi">
  <Product Name="UltraDynamo" Id="35428e84-c66f-4fd9-9a1c-b37b7cc4b47b" UpgradeCode="b8ab586c-46c8-4d87-af78-a4391c39d6f9" Language="1033" Codepage="1252" Version="1.1.0.0" Manufacturer="David Auld">
    <Package Id="*" Keywords="Installer" Description="UltraDynamo Installation" Comments="This Package Installs UltraDynamo" InstallerVersion="100" Languages="1033" Compressed="yes" SummaryCodepage="1252" />
    <Media Id="1" Cabinet="Sample.cab" EmbedCab="yes" DiskPrompt="CD-ROM #1" />
    <Property Id="DiskPrompt" Value="AppUp_WIXTest disk prompt 0.0.0.1 [1]" />
    <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="ProgramFilesFolder" Name="PFiles">
          <Directory Id="INSTALLDIR" Name="UltraDynamo">
            <Component Id="Component1" Guid="*">
              <File Id="File_id1" KeyPath="yes" Source="C:\Users\Dave\Documents\Visual Studio 2012\Projects\UltraDynamo\UltraDynamo\bin\Release\ChangeLog.txt" />
            </Component>
            <Component Id="Component2" Guid="*">
              <File Id="File_id2" KeyPath="yes" Source="C:\Users\Dave\Documents\Visual Studio 2012\Projects\UltraDynamo\UltraDynamo\bin\Release\ReadMe.txt" />
            </Component>
            <Component Id="MainExecutable" Guid="*">
              <File Id="File_id3" KeyPath="yes" Source="C:\Users\Dave\Documents\Visual Studio 2012\Projects\UltraDynamo\UltraDynamo\bin\Release\UltraDynamo.exe">
                <Shortcut Id="desktopApp10" Directory="DesktopFolder" Name="UltraDynamo" WorkingDirectory="INSTALLDIR" Icon="Appicon.ico" IconIndex="0" Advertise="yes" />
              </File>
            </Component>
            <Component Id="Component4" Guid="*">
              <File Id="File_id4" KeyPath="yes" Source="C:\Users\Dave\Documents\Visual Studio 2012\Projects\UltraDynamo\UltraDynamo\bin\Release\UltraDynamo.exe.config" />
            </Component>
          </Directory>
      </Directory>
      <Directory Id="DesktopFolder" Name="Desktop" />
    </Directory>
    <Feature Id="Complete" Title="UltraDynamo" Description="UltraDynamo" Display="expand" Level="1">
      <ComponentRef Id="Component1" />
      <ComponentRef Id="Component2" />
      <ComponentRef Id="MainExecutable" />
      <ComponentRef Id="Component4" />
    </Feature>
    <Icon Id="Appicon.ico" SourceFile="C:\Users\Dave\Desktop\1352829907_line_graph.ico" />
  </Product>
</Wix>

Once I had the XML file I could open up the command prompt and manually build the msi file using the Wix tools. There are two tools we need to use. 

First we use CANDLE, this pre-processes and compiles WiX source files into object files. (*.wixobj), Next we use LIGHT, this links and binds one or more .wixobj files and creates a Windows Installer database (.msi). The overall process would be;

CANDLE UltraDynamo.wxs 

LIGHT UltraDynamo.wixobj  

The result of this would be a file UltraDynamo.msi installer. BUT WAIT, it is not over yet! At this stage we have a code signed application packaged up into the required MSI file, but we now need to code sign the MSI file!

It is simply a case of taking the code sign command we used in the Build Event and modifying it to code sign the MSI file generated by the Wix tools. 

As you can see there are quite a few manual steps to package up the required files and code sign them and get us to a point where these were acceptable to the Intel AppUp process. It is here that I believe I can further modify my Build Event commands to automate this process fully, but just haven't got round to it yet. 

In Summary 

It is safe to say that this whole packing and deployment lark was a bit of a head buster.  

The quality of service provided by the certificate authorities was varied, the various tools, whether they be InstallShield, Intels MSI Creator or Wix could not have been more different if the authors had tried.

For this project, it is safe to say InstallShield was no use for the AppUp store, and Wix was the best approach, although I am sure there are other tools out there on the market, but probably require depositing some huge amount of cash somewhere! 

For the time being, it will be manually churned Wix until I tweak the build events. 

Where do we go now? 

I hope to go on and continue to develop and evolve this application, add more features, fix any bugs etc. Time is precious, so there are no guarantees when this will happen. I have a million other things I need to be getting on with! (Don't we all!) 

Final Thoughts 

The competition really was an eye opener for me. This was the first time I really had to pull my finger out and pulling this all together was a bit of a nightmare. After all, I am not a professional developer who does this day in day out. I have learnt a lot, an awful lot, it was a challenge, it was fun, and that is what it is all about. 

I was really grateful when I received an Ultrabook, I was even more surprised when I managed to get my App into the AppUp store and receive a prize for that. I was even more shocked and stunned to end up winning a category prize as well. In fact, I was completely blown away by that! 

Thanks to Chris and the team at CodeProject for hosting this competition and thanks to Intel as the sponsor. 

 

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here