Embed XML Directly in Visual Basic .NET Code with XML Literals

The problem: XML as strings is easy to break

Many VB.NET applications still build XML by concatenating strings:

Dim payload As String = "<alert><user>" & userName & "</user></alert>"

This works until a user name contains an ampersand, a quote, or a stray angle bracket. The compiler cannot catch malformed markup because it sees only a string. You discover the problem at runtime, often after the XML reaches a consumer or a log file.

What XML literals do

Visual Basic .NET supports XML literals: you write XML element syntax directly in code, and the compiler checks that the markup is well-formed before it ever runs. A literal such as <item><title>Hello</title></item> compiles to System.Xml.Linq.XElement calls through LINQ to XML. You can embed values with <%= expression %> blocks.

This feature arrived in Visual Basic 9.0 with .NET Framework 3.5 and Visual Studio 2008. It is specific to Visual Basic .NET; C# and classic VB6 do not have it.

Worked example: build a notification payload

Suppose you need to emit a small XML notification from a console application. Instead of assembling a string, declare an XDocument from an inline literal:

Imports System.Xml.Linq

Module NotificationBuilder
    Sub Main()
        Dim recipient As String = "Ada Lovelace"
        Dim priority As Integer = 3

        Dim doc As XDocument = _
            <notification>
                <recipient><%= recipient %></recipient>
                <priority><%= priority.ToString() %></priority>
                <issuedOn><%= DateTime.UtcNow.ToString("o") %></issuedOn>
            </notification>

        Console.WriteLine(doc.ToString())
    End Sub
End Module

Run this in a Visual Basic .NET console app targeting .NET Framework 3.5 or later. If the literal contains an unclosed tag or an illegal character, the build fails with a compiler error rather than a runtime exception. At runtime, doc.ToString() produces escaped, well-formed XML.

Where this decision breaks down

• Language portability: XML literals are Visual Basic .NET only. If you later port logic to C# or share the project with a C# team, this syntax will not compile.
• Namespaces: Default namespaces in XML literals follow VB scoping rules, which can silently differ from the same XML written in a standalone file. Always qualify elements when mixing literal XML with external schemas.
• Modern .NET support: Support in .NET Core, .NET 5, and later should be confirmed for your target project before relying on XML literals in new cross-platform work.
• Readability: Deeply nested literals with many embedded expressions become harder to read than a separate XML resource or a builder API.

How to verify before you commit to it

1. Open Visual Studio and create a Visual Basic .NET console app.
2. Set the target framework to .NET Framework 3.5 or later, or confirm your .NET Core/.NET 5+ SDK supports the feature for your project.
3. Add the example literal above and build.
4. Run the application and confirm the console output is valid XML.
5. Optional: open the compiled assembly in a decompiler such as ILSpy and confirm the literal was lowered to System.Xml.Linq.XElement and XDocument calls.

No administrative permissions are required for these steps. The main risk is assuming the feature behaves identically across every .NET implementation; verify on your actual target runtime.

Closing recommendation

Use XML literals when the markup is static or semi-static, lives inside VB.NET code, and benefits from compile-time validation. Reach for external XML files or a LINQ to XML builder when the document is large, edited by non-developers, or needs to be shared across languages. Check your target framework first, then let the compiler catch your markup mistakes before they reach production.