Applies to TestComplete 14.20, last modified on September 11, 2019

You may need to prepare your Silverlight application so TestComplete can access its objects, properties and methods. This topic explains how to make your Silverlight application testable.

Making the Application Internals Accessible to TestComplete

TestComplete can test only those Silverlight applications that were compiled and packed to an application package (the .xap file). Silverlight applications loaded by wrapper web pages directly from XAML source code files (.xaml) without using .xap package files are not supported by TestComplete.

Automatic Patching (Default Approach)

In general, TestComplete automatically exposes internal objects, methods and properties of in-browser Silverlight applications. That is, it automatically treats these applications as Open Application.

When a web browser loads a Silverlight application, TestComplete automatically injects helper libraries into the application to make it testable.

Requirements
  • The application must run in Internet Explorer.

    TestComplete cannot automatically get access to the internals of Silverlight applications running in web browsers based on the Microsoft WebBrowser control.

    To test a Silverlight application in Internet Explorer 11, you must process it using the tcAgPatcher utility (see below).
  • The application’s wrapper web page must directly load the application package file (.xap) from a web server.

    If the .xap file, in which the tested Silverlight application is implemented, is cached by the web browser and the wrapper page loads a copy of the file from the browser cache, TestComplete cannot automatically make the application testable. So, we recommend that you clear the browser cache before testing.

  • The application’s wrapper web page must be loaded via the HTTP protocol.

    The application does not automatically become testable with TestComplete if the HTTPS connection is used.

See Addressing Objects of Silverlight Applications to learn how you can check whether the application is Open or not.

If your application is not patched automatically, patch it manually (see below).

Applications That Are Not Patched Automatically

Prepare these applications for testing manually and disable automatic patching as described below.

Preparing Applications With the tcAgPatcher Utility

To manually prepare a Silverlight application for testing and make its internal objects accessible to TestComplete, use the tcAgPatcher command-line utility (<TestComplete>\Open Apps\Silverlight\tcAgPatcher.exe).

tcAgPatcher does not change the application’s source code. It adds TestComplete libraries directly to the application’s .xap file and registers them in the application’s manifest (AppManifest.xaml) inside the .xap file. These libraries are the same as those TestComplete injects into non-prepared Silverlight applications during the testing. They enable TestComplete to interact with Silverlight applications and see its UI and internal objects.

Do not copy tcAgPatcher to another folder. tcAgPatcher works only from its default installation folder.

tcAgPatcher has the following command-line syntax:

tcAgPatcher.exe [/silent] [/noBackup] xapfile

The command-line arguments are as follows:

  • /silent - (Optional) Do not show any error or warning messages.

  • /noBackup - (Optional) Do not create a backup copy of the application’s .xap file. If this argument is not specified, tcAgPatcher creates the application’s backup copy with the .bak extension in the same folder.

  • xapfile - The fully-qualified name of the Silverlight application’s .xap file to process.

You need to replace the .xap file on the application server with the processed .xap file. Do not process a local copy of the .xap file stored in your web browser’s cache.

Note for signed Silverlight applications: To test a signed Silverlight application processed with tcAgPatcher, launch TestComplete with the /agpatcheroff command-line argument:

TestComplete.exe /agpatcheroff

Without this argument, your application’s digital signature will be invalid during the testing process.

Recommendation on Launching Web Browsers

Typically, to launch a browser with the tested Silverlight application, you use the Run Browser keyword test operation, or Browsers.Item(…).Run scripting method.

If you launch the browser in some other way, and if you specify the web page’s URL in the browser’s command line or in the browser’s settings, then TestComplete will not be able to expose the internal objects, methods and properties of your Silverlight application automatically. This happens because in this case, the browser starts opening the page before TestComplete helper modules start working.

The issue occurs in the following typical cases:

  • You launch the browser from the command line and specify the test page’s URL as a command-line parameter.

  • The tested web page is specified in the browser settings and is opened automatically when the browser launches.

  • You launch the browser using the Tested Applications functionality and specify the test page’s URL as a launch parameter (this approach was adopted in TestComplete versions earlier than version 9).

To avoid the problem, use any of the following approaches:

  • Launch the browser using the Run Browser keyword test operation or the Browsers.Item(…).Run scripting method.

  • Change the launching settings so that the browser first opens the about:blank page and then navigates to the desired web page from the test. Your test can look something like the pseudo-code below --

    // Calling your custom procedure for launching the browser
    browserProcess = My_Start_Browser("about:blank")
     
    // Opening the test page (ToUrl is a method provided by TestComplete)
    browserProcess.ToUrl("http://my_server/my_test_page")

  • Prepare your Silverlight application for testing using the tcAgPatcher utility as it is described above.

Testing on Servers That Require Authentication

If the tested Silverlight application is running on a server that requires Negotiate, NTLM or some other authentication, TestComplete is unable to expose the application’s internal objects, methods and properties automatically. In order for TestComplete to be able to access the internal objects, methods and properties of this Silverlight application, prepare the application for testing with the tcAgPatcher utility. See above for complete information.

Making Cross-Domain Silverlight Applications Testable with TestComplete

If you want to test a Silverlight application that uses cross-domain communication, you need to perform the following steps to make the application testable with TestComplete:

  1. Create a crossdomain.xml configuration file with the following contents and place the file in the root directory of the web site where the tested Silverlight application’s package file (.xap) resides:

    XML

    <?xml version="1.0"?>
    <!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
    <cross-domain-policy>
       <allow-http-request-headers-from domain="*" headers="*"/>
    </cross-domain-policy>

    For more information on this file, see the MSDN Library.

  2. In the application manifest file (AppManifest.xml) of your Silverlight project, set the ExternalCallersFromCrossDomain attribute of the Deployment element to “ScriptableOnly”.

    XML

    <Deployment xmlns="http://schemas.microsoft.com/client/2007"
      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
      ExternalCallersFromCrossDomain="ScriptableOnly"
        ...
    >
        ...
    </Deployment>

    By default, the application manifest file is generated when you are building your Silverlight project. If the file is not generated, make sure that the “Generate Silverlight manifest file” option is enabled in the project’s settings. For this purpose:

    • Right-click the project node in Visual Studio’s Solution Explorer and select Properties from the context menu.

    • In the Project Properties window, switch to the Silverlight tabbed page.

    • Select the Generate Silverlight manifest file check box and specify a manifest file template (by default, it is AppManifest.xml).

    For more information on setting the ExternalCallersFromCrossDomain attribute in the manifest file, see the MSDN Library.

  3. In the source code of the application’s wrapper web page, set the enableHtmlAccess parameter of the Silverlight plugin hosting the tested Silverlight application to true.

    The way Silverlight application developers can change the enableHtmlAccess parameter depends on the way the application is embedded into the wrapper web page.

    If the application is embedded into the web page by using an HTML object element:
    • Open the application’s wrapper web page in an editor.

    • Locate the object element that is used to embed the Silverlight application.

    • Locate or add the child param element named enableHtmlAccess and set the parameter’s value to true as shown in the following example:

      HTML

      <div id="silverlightControlHost">
          <object width="640" height="480" data="data:application/x-silverlight-2," type="application/x-silverlight-2" >
              <param name="source" value="MySilverlightApp.xap"/>
              <param name="minRuntimeVersion" value="4.0.50826.0" />
              <param name="enableHtmlAccess" value="true" />
              <a href="http://go.microsoft.com/fwlink/?LinkID=124807" style="text-decoration: none;">
                  <img src="http://go.microsoft.com/fwlink/?LinkId=108181" alt="Get Microsoft Silverlight" style="border-style: none"/>
              </a>
          </object>
      </div>

    • Save the changes.

    If the application is added to the web page by using JavaScript functions:
    • Open the web page or JavaScript file containing the application’s functions in an editor.

    • Locate the Silverlight.createObject or Silverlight.createObjectEx function call that is used to embed the Silverlight application.

    • Locate or add the enableHtmlAccess property in the function’s parameter list and set its value to true as shown in the following example:

      JavaScript

      Silverlight.createObject(
          "MyApplication.xap",
          document.getElementById("silverlightControlHost"),
          "silverlightControl",
          {
              width: "640",
              height: "480",
              version: "4.0.50826.0",
              enableHtmlAccess: true
          },
          { },
          null,
          null
      );

      // -- or --

      Silverlight.createObjectEx({
          source: "MyApplication.xap",
          parentElement: document.getElementById("silverlightControlHost"),
          id: "silverlightControl",
          properties: {
              width: "640",
              height: "480",
              version: "4.0.50826.0",
              enableHtmlAccess: true
          },
          events: {}
      });

    • Save the changes.

    For more information on setting the enableHtmlAccess parameter of the Silverlight plugin, see the MSDN Library.

  4. Include the <TestComplete>\Open Apps\Silverlight\tcAgAgent14.dll assembly in your Silverlight project in Visual Studio.

  5. Append the following call to the Startup event handler code:

    C#

    AutomatedQA.TestComplete.AgAgent.Core.AgAgentLoader.LoadAgent();
  6. Rebuild the application. After that, you need to process the generated application package file (.xap) with the tcAgPatcher.exe command-line utility in the manner described above. This will enable extended support for Silverlight controls in your application.

See Also

Testing Silverlight Applications
Testing In-Browser Silverlight Applications - Requirements
Preparing a Web Browser for Testing Silverlight Applications
TestComplete Command Line

Highlight search results