Resolves #297

Removes the workaround for #297 and sets the langauge version to
experimental.

This will require 2.1.0-rc of Razor.

src/Microsoft.AspNetCore.Blazor.Razor.Extensions/BlazorExtensionInitializer.cs

@@ -27,12 +27,12 @@ namespace Microsoft.AspNetCore.Blazor.Razor
         {
             // The configuration names here need to match what we put in the MSBuild configuration
             DeclarationConfiguration = RazorConfiguration.Create(
-                RazorLanguageVersion.Version_2_1, // Cannot use experimental until 15.7p4
+                RazorLanguageVersion.Experimental,
                 "BlazorDeclaration-0.1",
                 Array.Empty<RazorExtension>());
 
             DefaultConfiguration = RazorConfiguration.Create(
-                RazorLanguageVersion.Version_2_1,
+                RazorLanguageVersion.Experimental,
                 "Blazor-0.1",
                 Array.Empty<RazorExtension>());
         }

src/Microsoft.AspNetCore.Blazor.Razor.Extensions/BlazorRuntimeNodeWriter.cs

@@ -442,15 +442,6 @@ namespace Microsoft.AspNetCore.Blazor.Razor
 
         public override void BeginWriteAttribute(CodeWriter codeWriter, string key)
         {
-            // Temporary workaround for https://github.com/aspnet/Blazor/issues/219
-            // Remove this logic once the underlying HTML parsing issue is fixed,
-            // as we don't really want special cases like this.
-            const string dataUnderscore = "data_";
-            if (key.StartsWith(dataUnderscore, StringComparison.Ordinal))
-            {
-                key = "data-" + key.Substring(dataUnderscore.Length);
-            }
-
             codeWriter
                 .WriteStartMethodInvocation($"{_scopeStack.BuilderVarName}.{nameof(BlazorApi.RenderTreeBuilder.AddAttribute)}")
                 .Write((_sourceSequence++).ToString())

test/Microsoft.AspNetCore.Blazor.Build.Test/RenderingRazorIntegrationTest.cs

@@ -234,48 +234,19 @@ namespace Microsoft.AspNetCore.Blazor.Build.Test
                 frame => AssertFrame.Attribute(frame, "data-abc", "Hello", 1));
         }
 
-        [Fact(Skip = "Currently broken due to #219. TODO: Once the issue is fixed, re-enable this test, remove the test below, and remove the implementation of its workaround.")]
+        [Fact]
         public void SupportsDataDashAttributesWithCSharpExpressionValues()
         {
             // Arrange/Act
-            var component = CompileToComponent(
+            var component = CompileToComponent(@"
-                "@{ var myValue = \"My string\"; }"
+@{ 
-                + "<elem data-abc=@myValue />");
+  var myValue = ""My string"";
+}
+<elem data-abc=""@myValue"" />");
 
             // Assert
-            Assert.Collection(GetRenderTree(component),
+            Assert.Collection(
-                frame => AssertFrame.Element(frame, "elem", 2, 0),
+                GetRenderTree(component),
-                frame => AssertFrame.Attribute(frame, "data-abc", "My string", 1));
-        }
-
-        [Fact]
-        public void TemporaryWorkaround_ConvertsDataUnderscoreAttributesToDataDash()
-        {
-            // This is a temporary workaround for https://github.com/aspnet/Blazor/issues/219
-            //
-            // Currently Razor's HtmlMarkupParser looks for data-* attributes and handles
-            // them differently: https://github.com/aspnet/Razor/blob/dev/src/Microsoft.AspNetCore.Razor.Language/Legacy/HtmlMarkupParser.cs#L934
-            // This is because Razor was historically used only on the server, and there's
-            // an argument that data-* shouldn't support conditional server-side rendering
-            // because of its HTML semantics. The result is that information about data-*
-            // attributes isn't retained in the IR - all we get there is literal HTML
-            // markup, which the Blazor code writer can't do anything useful with.
-            //
-            // The real solution would be to disable the parser's "data-*" special case
-            // for Blazor. We don't yet have a mechanism for disabling it, so as a short
-            // term workaround, we support data_* as an alternative syntax that renders
-            // as data-* in the DOM.
-            //
-            // This workaround (the automatic conversion of data_* to data-*) will be removed
-            // as soon as the underlying HTML parsing issue is resolved.
-
-            // Arrange/Act
-            var component = CompileToComponent(
-                "@{ var myValue = \"My string\"; }"
-                + "<elem data_abc=@myValue />");
-
-            // Assert
-            Assert.Collection(GetRenderTree(component),
                 frame => AssertFrame.Element(frame, "elem", 2, 0),
                 frame => AssertFrame.Attribute(frame, "data-abc", "My string", 1));
         }

tooling/Microsoft.VisualStudio.BlazorExtension/source.extension.vsixmanifest

@@ -12,7 +12,7 @@
         <PreviewImage>Content\WebConfiguration.png</PreviewImage>
     </Metadata>
     <Installation AllUsers="true">
-        <InstallationTarget Id="Microsoft.VisualStudio.Community" Version="[15.0.27512, 16.0)" />
+        <InstallationTarget Id="Microsoft.VisualStudio.Community" Version="[15.0.27617, 16.0)" />
     </Installation>
     <Dependencies>
         <Dependency Id="Microsoft.Framework.NDP" DisplayName="Microsoft .NET Framework" d:Source="Manual" Version="[4.6.1,)" />