Build error SQL72025: Failed to load dacpac RRS feed

  • Question

  • My build succeeds in SSDT but fails with MSBuild.exe command line, Below is log of both..

    Also the step "Validating the project model..." takes very long to complete in both cases.


    ------ Rebuild All started: Project: Servicer, Configuration: Release Any CPU ------
    Loading project references...
    Loading project files...
    Building the project model and resolving object interdependencies...
    Validating the project model...
    Writing model to C:\main\dev\OrionDBServer\Servicer\obj\Release\Model.xml...
    Servicer -> C:\main\dev\OrionDBServer\Servicer\bin\Release\Servicer.dll
    Servicer -> C:\main\dev\OrionDBServer\Servicer\bin\Release\Servicer.dacpac
    ========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========


    C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild !SourceSoln! /t:Rebuild 

             Loading project files...
             Building the project model and resolving object interdependencies...
             Validating the project model...
         2>c:\Main\Dev\OrionDBServer\DAC Packages\EINV.dacpac : Build error SQL72025: Failed to load C:\MAIN\DEV\ORIONDBSERVER\DAC PACKAGES\EINV.DACPAC.
         2>Done Building Project "c:\Main\Dev\OrionDBServer\Servicer\Servicer.sqlproj" (Rebuild target(s)) -- FAILED.
         1>Done Building Project "c:\Main\Dev\OrionDBServer\OrionServer.sln" (Rebuild target(s)) -- FAILED.

    Build FAILED.

           "c:\Main\Dev\OrionDBServer\OrionServer.sln" (Rebuild target) (1) ->
           "c:\Main\Dev\OrionDBServer\Servicer\Servicer.sqlproj" (Rebuild target) (2) ->
           (SqlBuild target) -> 
             c:\Main\Dev\OrionDBServer\DAC Packages\EINV.dacpac : Build error SQL72025: Failed to load C:\MAIN\DEV\ORIONDBSERVER\DAC PACKAGES\EINV.DACPAC.

        0 Warning(s)
        1 Error(s)

    Time Elapsed 00:20:30.28


    Tuesday, November 4, 2014 1:01 PM

All replies

  • I am also experiencing the same issue when I try building the sqlproj on a build server.  When I build locally it works just fine and have no issues.  It almost seems like there is some sort of lock on the referenced .DACPAC file that msbuild can't access it.
    Tuesday, November 4, 2014 7:18 PM
  • Hi TJ and Mahesh, does using the /p:CommandLineInMemoryStorage="true" parameter fix the issue for either of you? This will use an in-memory model rather than the file-backed one and can resolve some issues with running larger builds, particularly on build servers. 

    Other possible causes:

        • Ensure you are using the correct version of SSDT's MSBuild tools when building from the command line. This may default to VS2012's tools unless the /p:VisualStudioVersion=12.0 flag is used to specify that VS2013's tooling should be used. I'm not sure if this is blocking you but if it's only failing on the command line it's worth exploring.
        • For all other issues you will need to enable logging and examine the event log. Here is the information for this - note that you can look at the logs yourself for information about what might be going wrong.

        If this issues is reproduceable on the latest SSDT bits, I'd suggest capturing the event log for what is going wrong and then opening a connect bug for this issue at and use the category "Developer Tools(SSDT, BIDS, etc.)". We're trying to track all bugs through connect so that you can tell when we have fixed the issue and we can request more information. Please include the event log (instructions on this below) plus any other useful information you can provide, such as an example of exact steps to reproduce the problem.


        Gathering an Event Log for SSDT

        For diagnostic purposes we would like you to gather an event log for the issue that you are experiencing in SSDT. In order to gather a log and send it to a member of the team, please follow the steps below.


        1. Open a new command prompt as Administrator.
        2. Run the following command

        logman create trace -n DacFxDebug -p "Microsoft-SQLServerDataTools" 0x800 -o "%LOCALAPPDATA%\DacFxDebug.etl" -ets

        logman create trace -n SSDTDebug -p "Microsoft-SQLServerDataToolsVS" 0x800 -o "%LOCALAPPDATA%\SSDTDebug.etl" -ets

        1. Run whatever the target/issue scenario is in SSDT.
    • Go back to the command prompt and run the following commands

      logman stop DacFxDebug -ets

      logman stop SSDTDebug -ets

      1. The resulting ETL files will be located at %LOCALAPPDATA%\SSDTDebug.etl & %LOCALAPPDATA%\DacFxDebug.etl and can be navigated to using Windows Explorer.
      1. Please attach this file when creating the connect bug


      NOTE - These logs will only be used by Microsoft product team members in order to better diagnose the problem you are experiencing with SSDT and will not be shared elsewhere. If you want to make sure that there is no private information in your ETL file, the SSDTDebug.etl file can be opened and analyzed using the Windows Event Viewer.

      To do this, open the Windows Event Viewer application. In the right-hand panel, select Open Saved Log. Navigate to the location where you saved the log, open, and review the contents of the trace.



    Wednesday, November 5, 2014 12:58 PM
  • Hello Kevin,

    None of your tips help, so I logged a bug:



    Friday, November 7, 2014 8:42 PM
  • Thanks Mahesh, we will look at that connect bug and contact you as we are investigating.


    Friday, November 14, 2014 7:02 AM