• SqlPackage or DacFx Version: Microsoft.Build.Sql 2.2.0 / 2.3.0-preview.2, Microsoft.SqlServer.DacFx 170.5.60-preview
• .NET Framework (Windows-only) or .NET Core: .NET 10.0.302
• Environment (local platform and source/target platforms): Windows 11 → SQL Server 2022 (Sql160)

Steps to Reproduce:

1. Create an SDK-style SQL project targeting Sql160
2. Add a stored procedure or view that uses the SQL Server 2022 named WINDOW clause:

CREATE PROCEDURE [dbo].[ExampleProc] AS
BEGIN
    SELECT
        ROW_NUMBER() OVER [win] AS [RowNum],
        SUM([Amount]) OVER [win] AS [RunningTotal]
    FROM [dbo].[Transactions]
    WINDOW [win] AS (PARTITION BY [AccountID] ORDER BY [TransactionDate]);
END

3. Build the project with dotnet build
4. Build fails with: Build error SQL46010: Incorrect syntax near 'OVER'.

Expected Behavior:

The project builds successfully. The WINDOW clause is valid, generally available T-SQL syntax that shipped with SQL Server 2022 (compatibility level 160), documented at:
https://learn.microsoft.com/en-us/sql/t-sql/queries/select-window-transact-sql

Actual Behavior:

Build error SQL46010: Incorrect syntax near 'OVER'.

The ScriptDom parser does not recognize the named WINDOW clause syntax and fails to parse the T-SQL.

Versions Tested:

Did this occur in prior versions? If not - which version(s) did it work in?

This has never worked in any version of DacFx or Microsoft.Build.Sql. The named WINDOW clause was introduced in SQL Server 2022 (November 2022) and the ScriptDom parser has not been updated to support it in any release since — including the latest preview (170.5.60-preview, August 2026).

This follows a pattern of SQL Server engine features shipping without corresponding ScriptDom/DacFx parser support, previously seen with IGNORE NULLS (#133) and GENERATE_SERIES (#105). Both were treated as bugs and resolved.

Impact:

Teams using the WINDOW clause for cleaner, DRY window function definitions are forced to rewrite all named window references as inline OVER (PARTITION BY ... ORDER BY ...) definitions. The workaround is functionally identical but more verbose and harder to maintain.

Workaround:

Replace named WINDOW references with inline OVER() definitions:

-- Instead of this (fails to build):
SELECT
    ROW_NUMBER() OVER [win] AS [RowNum],
    SUM([Amount]) OVER [win] AS [RunningTotal]
FROM [dbo].[Transactions]
WINDOW [win] AS (PARTITION BY [AccountID] ORDER BY [TransactionDate]);

-- Use this (builds successfully):
SELECT
    ROW_NUMBER() OVER (PARTITION BY [AccountID] ORDER BY [TransactionDate]) AS [RowNum],
    SUM([Amount]) OVER (PARTITION BY [AccountID] ORDER BY [TransactionDate]) AS [RunningTotal]
FROM [dbo].[Transactions];