Publish failure caused by issue not detected by SSDT build - where to report bug?

[chadbaldwin]

This probably isn't an issue with DacFx...but I don't really know where else to ask this question as there doesn't seem to be a lot of support for SSDT online.

I ran into a deployment exception that caused the publish to fail. The issue is not detected in the MSBuild build process. I'm trying to figure where I can report this bug...I found a couple locations while Googling, but they were MS based forums, and not a bug reporting system, and SSDT does not appear to be on GitHub either.

This isn't an issue with sqlpackage or msbuild, so I assume it's SSDT...I'm just a little lost as to where to go....so I'm hoping someone here might be able to help point me in the right direction.

This is the exception thrown by the deployment script:

Core Microsoft SqlClient Data Provider: Msg 213, Level 16, State 1, Procedure usp_MyStoredProcedure, Line 14 Column name or number of supplied values does not match table definition.

Pretty simple issue....there's an INSERT statement that is missing the column mapping, and the number of values is less than those on the target table....Like so:

CREATE TABLE #MyTable (
    Col1 int NULL,
    Col2 int NULL,
);
INSERT INTO #MyTable VALUES (1)

This seems like something that SSDT should be detecting in the build phase, but it isn't. And it seems I'm not the first to run into this:
https://stackoverflow.com/questions/24883821/msbuild-vs2012-fails-to-find-column-name-or-number-of-supplied-values-does-no

[dzsquared]

Is that a post or pre deployment script? There isn't DacFx validation of those scripts.

For reporting issues with SSDT intellisense not detecting the error in that script -
https://docs.microsoft.com/en-us/visualstudio/ide/how-to-report-a-problem-with-visual-studio

[chadbaldwin]

Sorry, this fell off my radar.

No, it is neither a pre or post deployment script. It's just a normal sql file containing a table. This can be recreated with a new SSDT project like so:

-- file 1
CREATE TABLE dbo.foo (
    ColA int NULL,
    ColB int NULL,
);

-- file 2
CREATE PROC dbo.usp_insert_foo
AS
INSERT INTO dbo.foo SELECT 1;

Building the project (both in VS and via CLI using MSBuild) does not identify the issue even though it is invalid and SQL Server will throw an exception if you try to publish it.

I'll follow that link and submit a bug report.

[dzsquared]

Ah, I see. An insert statement that doesn't specify the columns doesn't attempt to validate the columns at all. Would you expect a warning that an unsafe insert statement without columns is being written, a warning that the number of columns doesn't match the table (if known to the model), or an error that the number of columns doesn't match the table (if known to the model)?

[chadbaldwin]

This: an error that the number of columns doesn't match the table (if known to the model)

If you can't deploy it manually through SSMS, then it should break the build via an error. Otherwise if it's only a warning, then it can still pass through and cause an unexpected publish failure. I'd rather see it fail-fast.

Only downside here is by adding a new error, it's causing a change in behavior and may cause unexpected build failures for existing SSDT users. So not sure what the internal discussions will be around that one.