AdaptiveCards: .NET WPF doesn't render a simple card

.NET WPF (haven’t tested HTML yet) fails to render this card:

{
	"$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
	"type": "AdaptiveCard",
	"version": "1.2",
	"body": [
		{
			"type": "TextBlock",
			"id": "3",
			"text": "Container default style"
		}
	]
}

exception message:

System.ArgumentException
  HResult=0x80070057
  Message='3' is not a valid value for property 'Name'.
  Source=WindowsBase
  StackTrace:
   at System.Windows.DependencyObject.SetValueCommon(DependencyProperty dp, Object value, PropertyMetadata metadata, Boolean coerceWithDeferredReference, Boolean coerceWithCurrentValue, OperationType operationType, Boolean isInternal)
   at System.Windows.DependencyObject.SetValue(DependencyProperty dp, Object value)
   at AdaptiveCards.Rendering.Wpf.AdaptiveRenderContext.Render(AdaptiveTypedElement element)
   at AdaptiveCards.Rendering.Wpf.AdaptiveContainerRenderer.AddContainerElements(Grid uiContainer, IList`1 elements, AdaptiveRenderContext context)
   at AdaptiveCards.Rendering.Wpf.AdaptiveCardRenderer.RenderAdaptiveCardWrapper(AdaptiveCard card, AdaptiveRenderContext context)
   at AdaptiveCards.Rendering.AdaptiveElementRenderers`2.<>c__DisplayClass1_0`1.<Set>b__0(AdaptiveTypedElement typedElement, TContext tContext)
   at AdaptiveCards.Rendering.Wpf.AdaptiveRenderContext.Render(AdaptiveTypedElement element)
   at AdaptiveCards.Rendering.Wpf.AdaptiveCardRenderer.RenderCard(AdaptiveCard card)

Aside from the exception itself, it’s noteworthy that we’re not converting the System.ArgumentException to an AdaptiveException.

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 18 (18 by maintainers)

Most upvoted comments

@andrewleader proposal may still be the best option, having a dictionary when rendering with all the ids and rendered items to handle all id’s , that way we don’t have to worry about changing the ids prefixing an underscore ‘_’ and we don’t have to deal with the ‘Name’ message and the impact on the client side

Fixing it on WPF isn’t as trivial as just prepending an underscore (that doesn’t handle cases where there’s a space), however it is still relatively trivial to fix.

However, I think WPF needs to be updated regardless as the code as it’s written today poses a potential security threat to host apps. Today, we’re assigning the Id to the Name property of the actual WPF elements in the visual tree… what happens if the author uses the same Id as the host app is using for an element name elsewhere? If that author then looks through the visual tree for their named element, they might instead find the element from the author. Now, it’s not best practice to look up elements by name, as it requires iterating through the entire visual tree, so that’s probably a very unlikely vulnerability. However, I don’t think there’s any reason for us to be using the Name and the visual tree for this either. We should be storing a separate dictionary of Id->Element, which would be on the order of O(1) rather than O(n) for grabbing the element in order to toggle the visibility.

HTML5’s identity syntax sounds fine with me too

almedina-ms on Jul 17, 2019