Configuring Manifests on Windows 8.1 and Later Operating Systems

Applies to TestComplete 15.68, last modified on October 16, 2024

On Windows 8.1 and later operating systems, your COM client application for TestComplete must have the same privilege level as TestComplete. The privilege level is specified by the uiAccess attribute in the application manifest (the AppName.exe.manifest XML file next to the application). TestComplete and your application must have the same uiAccess value (true or false) in their manifests.

Using Extended Privilege Level (uiAccess="true")

To test Windows Store applications, your COM client from which you control TestComplete must use the extended privilege level, that is, it must have uiAccess="true" in its manifest. If it is impossible, automate TestComplete in some other way, for example, by using the command line.

Requirements

Your COM client application from which you control TestComplete:

  • Must be digitally signed. (See below.)

  • Must be in the Program Files, Program Files (x86) or Windows\System32 folder.

Setting the uiAccess Attribute

Set the extended privilege level for TestComplete and your COM client application from which you will control TestComplete:

  1. Launch a text editor as Administrator.

  2. In the text editor, open the manifest file corresponding to the TestComplete version you use:

    • 32-bit version: <TestComplete>\Bin\TestComplete.exe.manifest

    • 64-bit version: <TestComplete>\x64\Bin\TestComplete.exe.manifest

  3. Find the requestExecutionLevel element and add the uiAccess="true" attribute to it:

    XML
    Copy Code

    XML

      <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <security>
          <requestedPrivileges>
            <requestedExecutionLevel level="asInvoker" uiAccess="true"/>
          </requestedPrivileges>
        </security>
      </trustInfo>

  4. Save the changes.

  5. In the same way, change the manifest of your COM client application.

    Note: A manifest may be embedded into the application. This manifest takes priority over an external manifest on Windows Server 2003, Windows Vista, and later Windows versions. On Windows XP, the external manifest has higher priority. If you have trouble connecting to your application, make sure you edited the correct manifest.

Digitally Signing the COM Client

Your COM client must be signed. There are several ways you can do it:

By using PowerShell

  1. Use the New-SelfSignedCertificate cmdlet to create a new self-signed certificate. For example:

    PowerShell
    Copy Code

    PowerShell

    New-SelfSignedCertificate -DnsName "www.mycompany.com" -Type codesigningcert -Subject "CN=Test" -CertStoreLocation "cert:\LocalMachine\My"

    Where:

    DnsName - is the DNS name (or names) to use as the alternative name for the certificate subject.

    Type - is the type of the new certificate. To sign a COM client, use the CodeSigningCert value.

    Subject - is the subject of the new certificate.

    CertStoreLocation - is the certificate store to which the new certificate will be added. It can be the local machine certificate store or the current user certificate store. To learn more about the certificate stores, see the following article at the Microsoft website:

    docs.microsoft.com/en-us/windows-hardware/drivers/install/certificate-stores

  2. If needed, export the created certificate data to a .pfx file. To do this, use the Export-PfxCertificate cmdlet. For example:

    PowerShell
    Copy Code

    PowerShell

    $pwd = ConvertTo-SecureString -String 'mypassw0rd' -Force -AsPlainText
    $cert = Get-ChildItem -Path Cert:\LocalMachine\My -CodeSigningCert
    Export-PfxCertificate -Cert 'cert:\LocalMachine\my\' + $cert.thumbprint -FilePath 'c:\temp\cert.pfx' -Password $pwd

    Where:

    Cert - is the path to the created certificate, in the certificate store.

    FilePath - is the target .pfx file to which the certificate data will be exported.

    If the specified file already exists, it will be overwritten.

    Password - is the secure string that specifies the password of the created .pfx file. To get the password in the secure string format, use the ConvertTo-SecureString cmdlet.

  3. Use the Set-AuthenticodeSignature cmdlet to sign your COM client with the certificate data. For example:

    PowerShell
    Copy Code

    PowerShell

    $pfx = Get-PfxCertificate -FilePath 'C:\Temp\cert.pfx'
    Set-AuthenticodeSignature -FilePath "C:\Temp\Client1.exe" -Certificate $pfx

    – or –

    PowerShell
    Copy Code

    PowerShell

    $cert = Get-ChildItem -Path Cert:\LocalMachine\My -CodeSigningCert
    Set-AuthenticodeSignature -FilePath "C:\Temp\Client1.exe" -Certificate $cert

    Where:

    FilePath - is the name of your COM client executable.

    Certificate - is the certificate data stored in a .pfx file or in the certificate store. To get the certificate data from a .pfx file, use the Get-PfxCertificate cmdlet. To get the certificate data form the certificate store, use the Get-ChildItem cmdlet.

The sample PowerShell script below shows how to sign a COM client:

PowerShell
Copy Code

PowerShell

# Create a new self-signing certificate, add it to a personal certificate store, and store the certificate data to a variable
$cert = New-SelfSignedCertificate -DnsName "www.mycompany.com" -type CodeSigningCert -subject "CN=Test" -CertStoreLocation "cert:\LocalMachine\My"
# Get the path to the created certificate in the certificate store
$path = 'cert:\LocalMachine\my\' + $cert.thumbprint

# Set the password for the .pfx file
$pwd = ConvertTo-SecureString -String ‘mypassw0rd’ -Force -AsPlainText
# Set the name of the .pfx file to create
$certPath = 'C:\Temp\cert.pfx'
# Export the created certificate to the specified .pfx file
Export-PfxCertificate -cert $path -FilePath $certPath -Password $pwd

# Sign the COM client with the certificate data from the .pfx file
$pfx = Get-PfxCertificate -FilePath $certPath
Set-AuthenticodeSignature -FilePath "C:\Temp\client.exe" -Certificate $pfx
By using signing utilities (deprecated)

You can get the signing utilities with Visual Studio or Windows SDK.

The MakeCert utility used to create certificates is deprecated. We recommend that you use the PowerShell approach described above to sign your COM client.

  1. Use the MakeCert utility to create a self-signed certificate and a private key:

    MakeCert -r -n CertificateName -ss CertificateStore -sr localmachine -sv PrivateKeyFile.pvk OutputCertificateFile.cer

    Where:

    CertificateName - is the name of your certificate, it must comply with the X.500 standard and match the Publisher value in your client application’s manifest. For example, "CN=MyCompany";

    CertificateStore - is the name of your certificate store that will store the generated certificate;

    PrivateKeyFile.pvk - is the name of the file to which the utility will store the private key;

    OutputCertificateFile.cer - is the name of the file, to which the utility will store the certificate.

    The utility will ask you for a password for the private key. Specify the password if needed.

    The utility will generate a self-signed certificate and save it to the specified certificate store. It will also export the private key and the certificate information to the specified .pvk and .cer files.

  2. Add the generated certificate to the Trusted Root Certification Authorities store for a local computer. To do this, you can use the CertMgr utility:

    CertMgr /add OutputCertificateFire.cer /s /r localmachine root

  3. Use the Pvk2Pfx utility to copy the private key and the certificate information to a Personal Information Exchange file (.pfx):

    Pvk2Pfx /pvk PrivateKeyFile.pvk /spc OutputCertificateFile.cer /pfx OutoutCertificate.pfx

    The utility will generate the .pfx file with the specified name.

  4. Use the SignTool utility to sign your COM client:

    SignTool sign /f OutoutCertificate.pfx MyCOMClient.exe

To verify that your client application is signed properly, you can use the verify command of the SignTool:

SignTool verify -pa -v MyCOMClient.exe

To learn more about code signing, see the Using SignTool to Sign a File article in the MSDN Library.

Using Standard Privilege Level (uiAccess="false")

Use this approach if your COM client application does not have a manifest, or if you do not test Windows Store applications.

  1. Disable the Enable support for testing Windows Store applications option in TestComplete:

    Disabling support for Windows Store applications in TestComplete

    Click the image to enlarge it.

  2. Launch a text editor as Administrator.

  3. In the text editor, open the manifest file corresponding to the TestComplete version you use:

    • 32-bit version: <TestComplete>\Bin\TestComplete.exe.manifest

    • 64-bit version: <TestComplete>\x64\Bin\TestComplete.exe.manifest

  4. Find the requestExecutionLevel element and make sure that it does not contain the uiAccess attribute or that this attribute is set to false:

    XML
    Copy Code

    XML

      <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <security>
          <requestedPrivileges>
            <requestedExecutionLevel level="asInvoker" uiAccess="false"/>
          </requestedPrivileges>
        </security>
      </trustInfo>

  5. If your COM client application has a manifest, change it in the same way.

    Note: A manifest may be embedded into the application. This manifest takes priority over an external manifest on Windows Server 2003, Windows Vista, and later Windows versions. On Windows XP, the external manifest has higher priority. If you have trouble connecting to your application, make sure you edited the correct manifest.

See Also

Working With TestComplete via COM - Overview
Working With TestComplete via COM

Highlight search results