DacPackage.UpdateModel(TSqlModel) corrupts package: 'Origin.xml' is missing or corrupted.

• SqlPackage or DacFx Version: Microsoft.SqlServer.DacFx 161.8089.0
• .NET Framework (Windows-only) or .NET Core: .NET 6.0
• Environment (local platform and source/target platforms):

Steps to Reproduce:

// NOTE: The original .dacpac is generated by a .sqlproj - this is key!
var dacpacFromSqlproj = "OutputOfSqlproj.dacpac";

using var buffer = new MemoryStream();
using (var temp = File.OpenRead(dacpacFromSqlproj))
{
    temp.CopyTo(buffer); // to avoid modifying the original .dacpac file
}

buffer.Position = 0;
using (var dacpac = DacPackage.Load(buffer, DacSchemaModelStorageType.Memory, FileAccess.ReadWrite))
{
    dacpac.UpdateModel(
        new TSqlModel(SqlServerVersion.SqlAzure, new TSqlModelOptions()),
        new PackageMetadata());
}

buffer.Position = 0;
// DacException: 'Origin.xml' is missing or corrupted. ---> System.Xml.XmlException: Data at the root level is invalid. Line 23, position 13.
DacPackage.Load(buffer);

Microsoft.SqlServer.Dac.DacServicesException: Could not load package. ---> Microsoft.Data.Tools.Schema.Sql.Dac.DacException: 'Origin.xml' is missing or corrupted. ---> System.Xml.XmlException: Data at the root level is invalid. Line 23, position 13.

XmlTextReaderImpl.Throw(Exception e)
XmlTextReaderImpl.Throw(String res, String arg)
XmlTextReaderImpl.ParseRootLevelWhitespace()
XmlTextReaderImpl.ParseDocumentContent()
XmlTextReaderImpl.Read()
XContainer.ReadContentFrom(XmlReader r)
XContainer.ReadContentFrom(XmlReader r, LoadOptions o)
XDocument.Load(XmlReader reader, LoadOptions options)
XmlUtilities.LoadWithProhibitDtd(Stream stream, LoadOptions options)
DacOrigin.Deserialize(Stream stream)
--- End of inner exception stack trace ---
DacOrigin.Deserialize(Stream stream)
DacOrigin.Open(Stream stream)
DacUtilities.GetDacOrigin(SqlPackage package)
DacPackage.ContainsExportedData(IPackageSource packageSource)
DacPackage.ctor(IPackageSource packageSource, FileAccess packageAccess)
DacPackage.Load(Stream stream, DacSchemaModelStorageType modelStorageType, FileAccess packageAccess)
--- End of inner exception stack trace ---
DacPackage.Load(Stream stream, DacSchemaModelStorageType modelStorageType, FileAccess packageAccess)
DacPackage.Load(Stream stream, DacSchemaModelStorageType modelStorageType)
DacPackage.Load(Stream stream)

This is Origin.xml from the initial .dacpac which was generated from a .sqlproj:

<?xml version="1.0" encoding="utf-8"?>
<DacOrigin xmlns="http://schemas.microsoft.com/sqlserver/dac/Serialization/2012/02">
  <PackageProperties>
    <Version>3.0.0.0</Version>
    <ContainsExportedData>false</ContainsExportedData>
    <StreamVersions>
      <Version StreamName="Data">2.0.0.0</Version>
      <Version StreamName="DeploymentContributors">1.0.0.0</Version>
    </StreamVersions>
  </PackageProperties>
  <Operation>
    <Identity>a480dbf8-d356-4c4c-b3f8-821257ea2806</Identity>
    <Start>2023-03-13T22:36:23.9372197-07:00</Start>
    <End>2023-03-13T22:36:26.0148593-07:00</End>
    <ProductName>Microsoft.Data.Tools.Schema.Tasks.Sql, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a</ProductName>
    <ProductVersion>16.0.6389.0</ProductVersion>
    <ProductSchema>http://schemas.microsoft.com/sqlserver/dac/Serialization/2012/02</ProductSchema>
  </Operation>
  <Checksums>
    <Checksum Uri="/model.xml">707F09FB16524772A2013C8D93B7DF6D7A21CED27C4ECF4522999F07A4625427</Checksum>
  </Checksums>
  <ModelSchemaVersion>2.4</ModelSchemaVersion>
</DacOrigin>

This is Origin.xml in the MemoryStream after calling DacPackage.UpdateModel():

<?xml version="1.0" encoding="utf-8"?>
<DacOrigin xmlns="http://schemas.microsoft.com/sqlserver/dac/Serialization/2012/02">
  <PackageProperties>
    <Version>3.1.0.0</Version>
    <ContainsExportedData>false</ContainsExportedData>
    <StreamVersions>
      <Version StreamName="Data">2.0.0.0</Version>
      <Version StreamName="DeploymentContributors">1.0.0.0</Version>
    </StreamVersions>
  </PackageProperties>
  <Operation>
    <Identity>a480dbf8-d356-4c4c-b3f8-821257ea2806</Identity>
    <Start>2023-03-13T22:59:31.2164864-07:00</Start>
    <End>2023-03-13T22:59:31.2178705-07:00</End>
    <ProductName>Microsoft.SqlServer.Dac.Extensions, Version=16.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a</ProductName>
    <ProductVersion>16.1.8430.0</ProductVersion>
    <ProductSchema>http://schemas.microsoft.com/sqlserver/dac/Serialization/2012/02</ProductSchema>
  </Operation>
  <Checksums>
    <Checksum Uri="/model.xml">823FEC3213691E0DFA47674B49448153E9AF8AA7C1BE0ED858388111FC321213</Checksum>
  </Checksums>
  <ModelSchemaVersion>2.4</ModelSchemaVersion>
</DacOrigin>in>

Both Origin.xml files are 1114 chars long, note the 3 junk characters on the end, also note that ProductName changed from Microsoft.Data.Tools.Schema.Tasks.Sql (37 chars) to Microsoft.SqlServer.Dac.Extensions (34 chars). Seems like it’s replacing the file contents but neglecting to update the stream/buffer length.

Did this occur in prior versions? If not - which version(s) did it work in? Tried all versions 161.8089.0 (latest stable) through 161.8430.0-preview (latest preview), not sure when this was introduced. (DacFx/SqlPackage/SSMS/Azure Data Studio)

[zijchen]

@Ericvf The original issue (with the extra characters breaking the XML) should be fixed in the latest release (162.0.52). I’m investigating the checksum issue right now.

I’ll close this issue now, but feel free to reopen if you still see the broken XML bug. Please use #281 to discuss about the checksum issue.

[smichtch]

@smichtch Could you create a new issue the checksum mismatch? So far it seems the checksum from UpdateModel is different than the one that’s calculated when the DacPackage is reloaded.

Done, filed #281.

We’ve noticed this issue a long time ago. Not sure exactly where the issue lies, we have tried to even fix it in this package. The Origin.xml does get corrupted, there is a bug somewhere probably in Dotnet. The solution for us has been to compile the project as net48. Unfortunately we can longer support that and therefore we are looking into this again.

Curiously we have other dacpacs which work fine. This only breaks in certain circumstances (but is repeatable).

As I mentioned in the original post it only occurs when the initial .dacpac was generated using a .sqlproj and then modified using the DacFx library (the DacOrigin/Operation/ProductName string in origin.xml changes and becomes 3 chars shorter). I suspect Stream behavior changed between .NET Framework to .NET Core so that the length is not updated automatically when the new origin.xml content is written. (The mismatching checksum may be related to non-deterministic GetHashCode() behavior in .NET Core versus .NET Core, but this is just speculation)