Installing a Code Signing Certificate, 2016

This is an update to my earlier article about the same subject. This process is much easier than it used to be.

This post was edited on August 1, 2019 to reflect minor changes in the process.

Install a certificate from Sectigo (was Comodo)

1. Use IE11 for your browser for everything related to the purchase. Don't use Edge or Chrome.
2. Use Sectigo (formerly Comodo) to buy your Code Signing Cert. They're still the cheapest provider, especially if you go through Tucows and buy a three year certificate.
3. When filling out the information during the purchase process:
• Make SURE you click the checkbox to allow the private cert to be exported, or you will be very unhappy.
• You want a SHA2 certificate, which will do SHA1 and SHA256 signing.
4. Your private key is generated when you initiate the order, but it is NOT stored in your Cert Store. Therefore, you must start and complete your order on the same machine with the same browser.
5. After your identity is confirmed, you will receive an email from Sectigo with a subject like ORDER #12345678 - Your Code Signing Certificate is ready!
6. Install the new certificate by clicking the link in the email. Again, use IE11. When it's done, you'll see something like this:





7. At this point, your new certificate has been automatically added to your Cert Store.
8. Verify the installation. Go to Control Panel / Internet Options / Content, click Certificates, select your new certificate, and click View in the bottom right. The certificate will probably be on the Personal page. Make sure you are looking at your new certificate and not the old. You can tell the difference by the expiration date.
9. Make sure you have the private key. Again on the Certificate page, at the end of the information, right under the "Valid from" dates, you should see something that says "You have a private key that corresponds to this certificate." If this isn't there, you may not have checked the box during the signup process as described in Step 3 above. You will probably need to get the certificate reissued (this is free with Sectigo).
10. Remove your old certificate. If you are renewing an existing certificate, then keeping the old certificates installed isn't usually useful, and having multiple certificates will break SIGNTOOL if signtool is searching the certificate store. Go to Control Panel / Internet Options / Content, click Certificates, select your old certificate, and click Remove. The old certificate will probably be on the Personal page.

Export the PFX file

A PFX file can be used by many third party utilities. One advantage is that PFX files can be created without a password, which is handy in automated builds if you are using SIGNTOOL. You can see the complete process with pretty pictures at Acmetek. Here's the abridged version:

1. Go back to the Certificates Page on Internet Options.
2. Select your new certificate
3. Click Export...
4. Click Next.
5. Select "Yes, export the private key."
6. Click Next.
7. Select "Personal Information Exchange - PKCS #12 (.PFX)." (If this option is grayed out, then your private key was not imported).
8. Check the box labeled "Include all certificates in the certification path if possible." THIS IS VERY IMPORTANT.
9. You may want to read about the new Windows 10 option, Enable certificate privacy.
10. Click Next.
11. Check the Password box.
12. Provide a password and the confirmation.
13. Click Next.
14. Enter a filename.
15. Click Next.
16. Click Finish.
17. If you want to remove the password from the PFX file, use openssl as described in this post from the Wayback Machine. Quick summary:
    openssl pkcs12 -in mycert.pfx -out tmpmycert.pem -nodes
    openssl pkcs12 -export -out mycert2.pfx -in tmpmycert.pem

Sign your code!

If you need some hints on this, see my earlier post.

As of January 1, 2016, all Windows executables destined for Windows 7 or later must be signed with SHA256. If you still support Windows XP and Vista, then you must also dual sign with SHA1. For details, see this excellent article.

Managing multiple configurations using Virtual PC

We use Virtual PC extensively for testing in our lab. We have about 12 different configurations for each version of Windows we test. We've spent a lot of time learning how to create these configurations so that they work reliably and to create a reasonable balance between updates of individual configurations versus a global rebuild as the security updates and service packs pile up.

This blog entry describes how we create the VHDs and configure them in Virtual PC.

Layer Overview

Our VHD tree is built based on a set of defined layers. Layer 1 is comprised of single root VHD for each version of Windows, such as WinXP SP3. Layer 2 is built from differencing VHDs that use the root VHD as the parent. This means that the root VHD needs to be configured as far as possible, without requiring lower layer VHDs have to "undo" any configuration. Here is the VHD structure we use:

1. Root VHD - Contains base Windows install and common configurations

2. Configuration specific VHD - Includes apps, service packs, etc. that are different from the root. This is where configuration-dependent changes are done.

3. Working VHD - Includes temporary changes that are used over the course of several tests.

4. Undo file.

Layers are defined by how often they are changed, because when a layer changes, everything underneath it is invalidated. Layer 1 changes every six to eighteen months, usually when the number of security updates becomes overwhelming. Layer 2 changes every few months. Layer 3 is only used when a customized configuration needs to be tested for several days (or when you hit the wrong button and say "commit change.) Layer 4 changes on a minute to minute basis. It is discarded whenever a user selects "Discard changes" when a VPC is closed.

Roadblocks

Creating the VHD hierarchy is tricky. There are several problems we've seen that must be solved by making the changes in the correct order in the correct order. Some of these problems include:

• Duplicate Ethernet MAC addresses.
• Duplicate computer names.
• Domain disconnects.
• Accidental overwriting of a parent vhd file.
• Windows Update automatically overwriting desired configurations.

The MAC address will be updated automatically by Virtual PC as long as you create a new .vmc file from the menu. In other words, use the New Virtual Machine Wizard, don't make a copy of your existing .vmc file. If you insist on copying your .vmc file, you can manually remove the MAC address from the XML file and it will automatically be recreated.
Many people are also concerned about "SID duplication" and want to use something like NewSID or SysPrep. Recent reports indicate that this is no longer a concern. Please see NewSID Retirement and the Machine SID Duplication Myth.

Create the Layer 1 Root VPC

The first task in creating the hierarchy is to create the Layer 1 VHD, which contains the OS install and will be common to all dependent virtual machines.

1. Create the .vhd file using the Disk Wizard. Set to dynamic size, 20 to 32GB is usually a good size.
2. Create the Virtual PC .vmc using the New Virtual Machine Wizard under the File menu. Make sure you give it enough RAM, the defaults are almost always too small.
3. Install Windows. Install a version of Windows that includes the desired service pack. Set the system name to be something like RootWinXp so you know when you've forgotten to change it. Do not join a domain during installation.
4. Log in as an Administrator and activate Windows, if necessary. Don't do this in a child virtual machine or you'll need an additional activation key for every child.
5. Shut down Windows and make a backup of the VHD. Name it "Level 1 - Clean" This is a "clean machine" that's been activated. Use this VHD to create completely new configuration hierarchies.

Configure the Layer 1 Root VPC

1. Boot the virtual machine.
2. Install the Virtual PC Additions.
3. Set the vpc to be part of workgroup, if it's not already. Do NOT join the root vhd to a domain! That must be done in a lower layer.
4. Install desired Windows service pack, if any.
5. For Windows XP, go to Windows Update in Internet Explorer and enable Microsoft Update.
6. Install latest security updates through Windows Update. Pay attention to the following:
• For Windows XP, go to Windows Update in Internet Explorer and check High Priority and Optional updates. The task bar "Update" icon does not show these updates.
• Under Optional, I recommend you install Update for Root Certificates.
• Also under Optional, install Microsoft .NET Framework, if needed.
• Windows Update may automatically upgrade Internet Explorer if you don't do a "Custom" update and uncheck Internet Explorer. OTOH, IE8 for Windows XP is under Optional.
• After each reboot, go back to Windows Update and check again. You'll probably need to run through Windows Update several times to get all updates.
7. In Control Panel, set Automatic Updates to "Notify me", not to automatically download or to automatically install. Otherwise you end up fighting Windows Update every time you boot a configuration.
8. Disable the requirement for Ctrl-Alt-Del. This can save a lot of mousing around when running the virtual PC in a window. For Windows XP, this can be found under Control Panel / User Accounts / Advanced (or use Group Policy.)
9. Create any desired local users (as opposed to domain users.) Make sure you set them as Admin or Limited, appropriately. At a minimum, I recommend creating a "Limited" user for testing.
10. Disable the Internet Connection Wizard if you have Windows XP virtual machines. In Group Policy, it's under User Configuration\Administrative Templates\Windows Components\Internet Explorer\Internet Settings\Advanced Settings\Internet Connection Wizard\
11. Set firewall exceptions in Control Panel | Windows Firewall | Exceptions:
• File and Printer Sharing must be enabled to allow access the system by name on the network.
• Remote Desktop must be enabled to access the system remotely.
12. If desired, enable Remote Desktop under My Computer | Properties | Remote. Note that Remote Desktop is not supported in any of the "Home" versions of Windows. Local Administrators will automatically have rights to access the system via Remote Desktop.
13. If you use Remote Debugging in Visual Studio, start up MSVCMON.EXE and tell it unblock the firewall for your subnet. You will discover that this adds numerous exceptions to the firewall. MSVCMON.EXE can be found in:
    
    C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\x86\msvsmon.exe
14. Modify options in My Computer | Tools | Folder Options | View, such as "Display the contents of system folders", "Show hidden files and folders", "Hide extensions", and Hide protected operating system files". This can also be done in the domain logon script with:
    
    reg add hkcu\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced /v Hidden /t REG_DWORD /d 1 /f

reg add hkcu\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced /v HideFileExt /t REG_DWORD /d 0 /f

reg add hkcu\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced /v WebViewBarricade /t REG_DWORD /d 1 /f
15. Share any desired folders.
16. Shut down the root vpc using the "Shutdown" from the Start menu.
17. Commit all changes if you are using Undo disks.
18. Set the VHD to be read-only.
19. Create a backup of the file. Name it "Level 1 - Common".
20. Optionally, go to the Virtual PC Console and remove this virtual machine so you don't accidently try to use it. If you don't delete it, make sure you enable Undo disks so you don't accidentally change it (Virtual PC will helpfully remove the read-only attribute.)

Create a Layer 2 VPC

1. Use disk wizard to create a differencing hard disk to the root.
2. Make a backup of this vhd file. Name it "Level 2 - Empty".
3. Create the Virtual PC .vmc using the menus. Again, make sure you give it enough RAM. Turn off Undo for now.
4. Boot the new virtual PC.
5. Log in as an adminstrator.
6. Change the system name.
7. Join a domain, if desired. This can be done from the command line with the NetDom command, which is available in the Windows XP Support Tools. (This should all be on one line.)
   
   netdom join myvpc /domain:test.com
/userd:Administrator
/passwordd:<domain admin password>
8. Give any desired domain users or groups permission to login via Remote Desktop.
9. Log in as any domain users you plan to use frequently. This does the one-time configuration of the VPC for that user. Change Folder Options again for these users.
10. Install any configuration-dependent software.
11. Install updates and service packs for the software you just installed.
12. Map network shares with a domain logon script. If a computer on a domain must map a drive on a non-domain computer, make sure the non-domain computer has an account with the same name and password as the domain computer. Alternatively, you use this command to save the username/password on the domain computer, then say "net use x: \\acme\share" in the domain logon script.
    
net use x: \\acme\share
/savecred /persistent:yes
13. Check Windows Update one more time. On Vista and Windows 7, make sure you explicitly tell it to check again.
14. Once everything is configured to your satisfaction, shut down Windows from the Start menu so it shuts down cleanly.
15. Set the VHD to be read-only.
16. Create a backup of the file. Name it "Level 2 - Configured".

Create a Layer 3 VPC

1. Create a third vhd, differencing, whose parent is the vhd you just set to be read-only. I normally name it the same as the parent with the word "Child" appended. This is what I called the "Working VHD" earlier in this document. You will use this when you need to reuse a configuration a few times, then discard the configuration. Normally this vhd is empty.
2. Change the settings in Virtual PC for your virtual machine to point to this working file.
3. Enable Undo for this vhd.
4. Backup this third VHD. Label it "Level 3 - Empty". You'll need the backup whenever you discard your current working configuration.

At this point you should have five backup files. The files labeled "Empty" in the below should be small, between 44KB and 106KB:

• Level 1 - Clean root VHD, with a clean Windows install.
• Level 1 - Configured root VHD, with a mostly configured Windows install.
• Level 2 - Empty configuration VHD, which is an empty differencing disk whose parent is the Level 1 vhd.
• Level 2 - Configured VHD, which is your fully configured test environment.
• Level 3 - Empty VHD.

Create Remaining Configurations

1. Copy your Level 2 - Empty vhd to a new file that will be the new configuration. Under Windows 7, you can create all of them at once using the DISKPART utility. For example: (DiskPart requires elevated privileges and so must be run from a command prompt started with Run As Administrator.)
   
   DISKPART < Parts.txt
   
   And Parts.txt is one or more lines similar to this:
   create vdisk file="c:\vpc\ParentDisks\WinXP Office 2007.vhd" parent="c:\vpc\ParentDisks\WinXP SP3 Root.vhd"
2. Go to Step 3 under Configure a Layer 2 VPC and continue through Configure a Layer 3 VPCs.

Licensing

Licensing is also an issue. Strictly speaking, it appears that you need one Windows license per virtual PC. In practice, we have a dozen different variants of each root virtual PC, with only minor changes between each, such as whether it's a member of a workgroup or a member of a domain, or whether it's Service Pack 2 of WinXP or Service Pack 3. Since we rebuild these fairly routinely from scratch, it is hard to believe that we are supposed to own thirty different licenses and rebuy all of them every few months. Our solutions for Windows has been to use the volume licensing versions of Windows, which are available to Microsoft Certified Partners on MSDN Downloads.

NUnit Unit Testing with C++

I switch back and forth between C++ and C#. When doing C# development, NUnit rules the day for unit testing. Whether I'm doing automated tests from the command line or using the GUI to run selective tests (show below in a screenshot from SourceForge) NUnit is a pleasure to use.



If you've ever tried to run unit tests for C++, the landscape is much less appealing. C++ does not have a reflection API, nor does it have attributes that are embedded in the executable code, so it's much more tedious in C++ to do all of the housekeeping to initialize the framework and it's much more difficult to integrate external GUI tools. In short, unit test in C++ is a sub-par experience compared to more modern languages.

But I have good news for you - it's possible to use NUnit with C++. There are two minor caveats:

1. You must be using Microsoft Visual Studio 2005 or later (sorry MinGW and cygwin users.)
   
2. The code to be tested must either be a DLL or a static library. If you need to test code in an .EXE, you should factor that code out into its own static library.
   

The secret is to place your tests in a separate DLL compiled for C++/CLI, which you enable on the Visual Studio C++ properties page in the General properties, immediately under Configuration Properties. Under Project Defaults, set Common Language Runtime support to "/clr". Don't use any of the other variants - they won't work for this task.

If you haven't built this kind of project before, a C++/CLI project is a curious hybrid that contains all of the power of C++ as well as much of the power of .Net. (Access to certain features, like LINQ, is not available in C++/CLI.)

With a C++/CLI project, you can use NUnit attributes for classes and member functions, just like in C#. When you run NUnit, your target is your test DLL, which implicitly loads either your static library code or your DLL code.

This strategy can also be used in the test environment build into Visual Studio if you have the Professional edition or better.

Visual Studio 2008 Feature Pack: Manifest Problems

If you install the Visual Studio 2008 Feature Pack, be aware that the manifest handling in the release is buggy, to put it politely. It's very easy to end up with the manifest requiring both the RTM DLLs (9.00.21022.8) and the Feature Pack DLLs (9.00.30411.0). This can cause weird, untraceable errors at runtime. I blogged about this problem before, but in that case it was caused by changing from a Beta build to the Release build.

There's a helpful blog post about the problem in the Visual C++ Team Blog.

The important point is that there are two #defines that force the manifest to point to the newer DLLs:

#define _BIND_TO_CURRENT_CRT_VERSION 1
#define _BIND_TO_CURRENT_MFC_VERSION 1

There's a single #define that does the same thing, but it's broken in the Feature Pack. [9/7/2008 - It's fixed in Service Pack 1. Thanks "anonymous"!]

#define _BIND_TO_CURRENT_VCLIBS_VERSION 1

The blog points out that defining the explicit BIND macros is not always the right thing to do.

This problem bit me because I was following the directions in this blog post, which call for making copies of certain directories from Debug_NonRedist. In a system where the CRT and MFC DLLs have been installed, there are pointers in the registry from the old versions of the DLLs to the new versions, so everything "just works." However, when using the Debug_nonRedist directories, these redirect pointers don't exist. Since the manifest was calling for the old versions of the DLLs, the application wouldn't open.

If you get error c101008a, either Rebuild All or delete all of your "xxx.exe.embed.manifest" files and build the solution.

Installing a Code Signing Certificate

WARNING: if you are getting your code signing certificate from VeriSign or Thawte, DO NOT use a Windows Vista or Win7 computer to get your certificate. If you do, you will not be able to export the private key and so you won't be able to sign code on any other computer and you won't be able to back up your certificate. If this happens to you, Thawte will give you a free reissue (Thanks Thawte!) See https://www.thawte.com/ssl-digital-certificates/technical-support/ Make sure you do not use a Vista or Win7 computer for the reissue! [Added 7/13/2008]. View my earlier post to see why.

Every time I try and install a code signing certificate, I forget how I did it last time. You'd think that there would be a guide somewhere on how to do it, but if there is, I haven't found it. Both VeriSign and Thawte give tantalizing hints scattered among dozens of knowledgebase articles, but overall, it's rather poorly documented.

So here's how to do it: (Note: If you are using Comodo and saving to the CSP, you should skip to Step 3, then skip to Step 7. In this case, you don't use the PVK or SPC file.)

1. Prerequisites: You must have a PVK file and an SPC file. From VeriSign and Thawte, these are normally named mycert.spc and mykey.pvk. If you don't have both of these files, this article won't help you. You'll also need the password for the PVK file.
2. Install PVKIMPRT from Microsoft. You can download it here.
   
3. Remove your old certificate. If you are renewing an existing certificate, then keeping the old certificates installed isn't usually useful, and having multiple certificates will break SIGNTOOL if signtool is searching the certificate store. Go to Control Panel / Internet Options / Content, click Certificates, select your old certificate, and click Remove. The old certificate will probably be on the Personal page if you allowed PVKIMPRT to decide where to put it.
4. Import the certificate. Run PVKIMPRT to load the certificate into your cert store, like this (should all be entered on one line):
   
   C:\Windows\PVKIMPRT.EXE -import c:\mycert.spc c:\mykey.pvk
   
   You'll be prompted for your password, which you should already know. You'll also be asked which certificate store. You can let PVKIMPRT decide.
5. Verify the installation. Go to Control Panel / Internet Options / Content, click Certificates, select your old certificate, and click View in the bottom right. The certificate will probably be on the Personal page if you allowed PVKIMPRT to decide where to put it.
6. Install the intermediate certificate. When you view the certificate information, you'll probably get a message that says something like "Windows does not have enough information to verify this certificate."
Don't panic! This is easily solved by installing the intermediate certificate. For Thawte, download the Root Certificates. This package also contains the intermediate certificates. Extract the ZIP file. Double click the file named "Thawte Code Signing CA.cer". You should see the Certificate Information. Click Install Certificate. Now go back to the Certificates Page on Internet Options and view your certificate. You should see the complete Certificate Information.

Make sure you have the private key. Go back to the Certificates Page on Internet Options and view your certificate. At the end of the information, right under the "Valid from" dates, you should see something that says "You have a private key that corresponds to this certificate." If this isn't there, delete the certificate, and repeat this procedure starting from Step 3. This happened to me when the intermediate certificate wasn't installed.

Export the PFX file. The PFX file can be used by SIGNTOOL. One advantage is that PFX files can be created without a password, which is handy in automated builds if you are using SIGNTOOL. You can see the complete process with pretty pictures at PentaWare. Here's the abridged version:

1. Go back to the Certificates Page on Internet Options
2. Select your certificate
3. Click Export.
4. Click Next.
5. Select "Yes, export the private key."
6. Click Next.
7. Select "Personal Information Exchange - PKCS #12 (.PFX)." (If this option is grayed out, then your private key was not imported).
8. Check the box labeled "Include all certificates in the certification path if possible. THIS IS VERY IMPORTANT.
9. Click Next.
10. On Windows XP, you can leave the password information blank if you plan to use this PFX file for automated builds. On Windows Vista, you must provide a password.
11. Click Next.
12. Enter a filename.
13. Click Next.
14. Click Finish.

Sign your code! If you need some hints on this, see my earlier post.

Parallel Builds - Success!

I've given up on the parallel build facility in VCBUILD (the /M option, such as /M2). It is almost useless for our build scenario. Instead I've switched to GNU make from the "cygwin" project. GNU make supports the -j command line parameter to enable parallel builds. GNU make also allows me to specify dependencies at whatever granularity level I need. Currently I specify dependencies on a per-project basis (one project = one .vcproj file), but I could just as easily go one level deeper and have multiple dependencies for each project, such as Debug/Release/Demo.

My makefile looks something like this (simplified for demonstration purposes):

all: sdk gui server

sdk:
vcbuild c:/proj/sdk/sdk.vcproj

gui: core
vcbuild c:/proj/gui/gui.vcproj

server: core
vcbuild c:/proj/svr/svr.vcproj

core:
vcbuild c:/proj/core/core.vcproj

This makefile is launched by a batch file that sets two very important environment variables:

set SolutionPath=c:\proj\proj.sln
set VCBUILD_DEFAULT_OPTIONS=/M1

By setting the "SolutionPath" environment variable to the solution file, we give VCBUILD the ability to set the $(SolutionDir) variable in the build scripts, which is typically required to build successfully.

When you point VCBUILD at a vcproj file, it automatically builds all configurations in that file. This way the makefile doesn't need to have knowledge of all the possible configurations. One feature you give up by specifying the vcproj file is that VCBUILD won't automatically add dependent libraries to the link line. For Visual Studio, this isn't a loss because the feature is largely broken anyway.

Using GNU make gives me the control that I need to keep my dual core processor busy. I'm finally happy :-)

Parallel Builds

One of the features in Visual Studio 2005 that I was most looking forward to was the ability to do parallel builds such that both cores in the Dual Core processor are used. So far this has been a complete bust.

Problem #1: Visual Studio wants to build based on Configurations instead of Projects. This means that you can't build a Release version of a project at the same time you build a Debug version.
Problem #2: Visual Studio will only build one Configuration at a time. This means that you can't create a build of one product while another product is in progress.
Problem #3: The meaning of Problem #1 and Problem #2 is that Visual Studio is optimized to build solutions that are based on many projects. This is typical for a C# application, but somewhat atypical for a C++ application. Our build hierarchy is wide and shallow, which means that Visual Studio's parallel build mechanism is almost useless.

I also tried to create a fake configuration that included all projects. This solution didn't work either because many library dependencies are generated based on the configuration, and this information is lost with an all-at-once Configuration.

Code Signing with SIGNTOOL

Part of our automated build system is to digitally sign our applications with our company's Verisign code signing certificate. Predictably, the signcode command failed under Vista.

First, a little history. Originally we signed our application like this:

signcode /spc C:mycredencials.spc /v a:myprivatekey.pvk /t http://timestamp.verisign.com/scripts/timstamp.dll c:\Project1.exe

The problem is that it required us to enter a password in a dialog box every time this command was run. Since we built several applications at a time, our "automated" build process required a lot of manual intervention.

The solution to that problem was to embed the key in the registry using PVKIMPRT. This was always painful because PVKIMPRT had some issues on Windows XP, so you had to use Windows 2000 or Windows 98 to import and export the certificate into a usable format. [Update 7/25/2008 - The problem was originally caused because the key was generated on Windows 2000. This is no longer true, so you can now safely use PVKIMPRT on Windows XP.]

The command line for signcode that directly accessed the certificate store was:

signcode -cn "Cool Corp" -n "My Application" -i http://www.example.com/MyApp.html -t http://timestamp.verisign.com/scripts/timstamp.dll c:\Project1.exe

This worked well on Windows XP, but failed on Vista with the error "failed to build the certificate chain." [Update 7/25/2008 - This problem was probably caused because the intermediate key was not installed. See my later post.]

Recent discussions about codesigning seem to advocate using signtool instead of signcode, although there's no discussion about the difference. I found that signtool has one big advantage over signcode: it can read PFX files, which is what Internet Explorer exports (Control Panel / Internet Options / Content / Certificates / Export). However, if you export your certificate to a PFX file in Windows Vista, you are required to provide a password, which didn't play well with one of our automated build tools.

The first solution was to use Windows XP to create the PFX file instead of Vista. WinXP will allow you to export your certificate and private key to a PFX file without a password. However, I found a better solution with a little research.

Signtool can automatically select a code signing certificate from the registry with the /a option. That's very handy. Eventually I ended up with this command in the Post Build Event:

$(SolutionDir)Tools\SignTool sign /a /d "My Application" /du "http://www.example.com/MyApp.html" /t http://timestamp.verisign.com/scripts/timstamp.dll $(TargetPath)