Known Issues

The AdControl exposes variables that are reserved for its own use. These are:

• window._msAdsGlobalEventManager
  
  
• window._msAdEngaged
  
  

Do not use these variables.

ApplicationId must be the same for all ad placements in an app, and cannot be changed during runtime. AdUnitId cannot be changed for a given AdControl during runtime. If you do assign a new value, the property value will change without throwing an exception. However, on the next ad refresh the errorOccurred event will fire.

Because ads are hosted in a WebView control, the following are some usage limitations and behavioral abnormalities for XAML apps.

1. The z-order of the AdControl is always the top level, which means an expanded ad can conflict with other WebView controls. An article discussing the issue can be found here.
   
   
2. Starting with the January release of the SDK, use the new UseStaticAnchor to work around flickering and z-order issues. When set to true, the AdControl will always use the WebViewBrush to render ads instead of the WebView control.
   
   
3. The UseStaticAnchor property supersedes the previously recommended workarounds of using the Suspend/Resume methods to address z-index issues and the IsPerformanceScrollingEnabled to address flicker during scrolling issues.
   
   
4. If hosting an ad on a page with user input controls, beware that focus is moved to the AdControl on an ad because XAML automatically gives focus to the newly added WebView control. The workaround is to manually refresh and do not call Refresh while the user is engaged with your app.
   
   

Apps may show some flickering during refresh as the old ad unloads and the new one loads.

HTML5 apps must NOT place elements into the reserved MAX-10 range of z-order, with the sole exception of interrupt overlays. For example, an inbound phone call notification for a Skype app. You can test your app with click-to-full-screen experiences by implementing the test AdUnitID value ADPT49 and clicking on it in the emulator.

A memory leak may be observed for apps running in the debugger. When the ad refreshes the AdControl may create a new iframe and the old iframe is waiting for garbage collection, which may not happen under the debugger. This is a known issue with iframe use in the debugger. If you observe what appears to be a memory leak in your app after an ad refresh try running the app without debugging.

Setting border related properties inherited by the AdControl from its parent class will cause the ad placement to be wrong. The Windows 8 interface discourages the use of borders. Consistent layout and the use of margins are the Windows 8 style. For more information see Developing Windows 8 style apps.

The current Ad SDK does support .NET C++ (managed C++ using the CLR). The AdControl loads the CLR and uses managed C++. Fully native support is planned for a future release -- there is no release ETA.

Be sure to read the end user license agreement (EULA) in its entirety. See the topic Important Notice – End Users License Agreement.

Age Rating: Your Windows 8 apps must have an Age rating of at least 12+ in the Windows Application Marketplace to receive Ads. See the Additional Agreements section.