none
SMO 2017 Microsoft.SqlServer.BatchParser.dll load error

    Question

  • SMO being distributed now via NuGet is great. However there is an issue that not only myself, but others have run into as well (see comments on this page): https://docs.microsoft.com/en-us/sql/relational-databases/server-management-objects-smo/installing-smo

    When trying to do a restore operation on PCs that do not have things like Visual Studio installed, you'll receive this error.

    Could not load file or assembly 'Microsoft.SqlServer.BatchParser.dll' or one of its dependencies. The specified module could not be found.

    The file exists in the deploy directory, but it seems to have issues loading it for whatever reason. No one has responded on docs website, so posting here hoping to get some answers on what's up here. Bug in the NuGet package?

    Once you install like VS2017, this error goes away, because BatchParser is in the GAC at that point, but the docs say now:

    This is a replacement for SharedManagementObjects.msi, which was previously released as part of the SQL Feature Pack for each release of SQL Server. Applications that use SMO should be updated to use the NuGet package instead and will be responsible for ensuring the binaries are installed with the application being developed.

    So, what needs to happen here? Or is there a way to remove the dependency from BatchParser from restore operations, which is where I'm hitting it?


    Tuesday, September 5, 2017 6:31 PM

All replies

  • Did you find a solution? I'm experiencing the same issue.

    I've tried compiling with AnyCPU, x86 and x64. Neither works.

    Wednesday, September 27, 2017 9:32 AM
  • I have not. I'm sure it's something wrong in the package. I submitted a Connect issue here:

    https://connect.microsoft.com/SQLServer/feedback/details/3140836

    You should add your feedback please so they know it's not just me :)

    Wednesday, September 27, 2017 4:00 PM
  • Posted more detail on the connect issue
    Thursday, September 28, 2017 8:19 AM
  • Thank you. Hopefully that will give them enough info to fix it.
    Thursday, September 28, 2017 7:45 PM
  • Hey all,

    Apologies for the delay! I've finally been able to investigate this and it turns out the issue has been due to missing VC Runtime dependencies. You can solve this by downloading and installing the appropriate redist (https://www.microsoft.com/en-us/download/details.aspx?id=40784) for the architecture of the computer running the application.

    Note this doesn't solve the issue with AnyCPU using the x86 version of BatchParser. It's suggested that if you plan on using any functionality that relies on BatchParser (such as database.ExecuteNonQuery or the Restore functionality) that you build your application specifically targeting x86/x64 and distributing as appropriate.

    Let me know if this doesn't solve your issues.

    -Charles Gagnon (chgagnon@microsoft.com)
    Wednesday, October 4, 2017 7:01 PM
  • Hi,

    We had a similar issue. In the end we tried to go for x64 all the way, but then the JIT compilation throws BadImageFormatException when trying to load Microsoft.SqlServer.Xe.Core.dll.

    I digged into the files provided with the nuget and for me it seems that Microsoft.SqlServer.Xe.Core.dll and Microsoft.SqlServer.XEvent.Linq.dll found in "runtimes/win-x64/native" seem to defined the files x86 in their headers. Also the sha512 sums of x64 and x86 versions match. So the same files seem to be deployed on both folders. Is this right? (In contrast the Microsoft.SqlServer.BatchParser.dll does have headers matching the folder (win-x64/win-x86) and different sha512 sums...)

    So should there actually be x64 versions of those two files deployed or should the x86 versions work also when targeting x64?

    Thursday, October 5, 2017 7:14 AM
  • Ah, yeah I looked into this and we are indeed packaging up the x86 version in both directories. Thanks for the extra investigation! We'll get a fixed version released soon.

    Thursday, October 5, 2017 4:00 PM
  • Hi,

    I am having this issue as well.  

    I have reproduced the error in a minimal WebAPI application. I have stuck the code, deployment folder, dxdiag and error screen on github. https://github.com/stevie6410/SMOTest

    Please let me know if you need anything else. I still have it deployed if you need me to check anything specifically.

    Tuesday, October 10, 2017 8:13 AM
  • Hey all,

    Apologies for the delay! I've finally been able to investigate this and it turns out the issue has been due to missing VC Runtime dependencies. You can solve this by downloading and installing the appropriate redist (https://www.microsoft.com/en-us/download/details.aspx?id=40784) for the architecture of the computer running the application.

    Note this doesn't solve the issue with AnyCPU using the x86 version of BatchParser. It's suggested that if you plan on using any functionality that relies on BatchParser (such as database.ExecuteNonQuery or the Restore functionality) that you build your application specifically targeting x86/x64 and distributing as appropriate.

    Let me know if this doesn't solve your issues.

    -Charles Gagnon (chgagnon@microsoft.com)

    Another problem with the Nuget package seems to be related to the Microsoft.SqlServer.SqlManagementObjects.targets file in the packages\Microsoft.SqlServer.SqlManagementObjects.140.17199.0\build\net40 folder. This file is intended to instruct MSBuild to copy the correct version of the runtimes (e.g. files located in packages\Microsoft.SqlServer.SqlManagementObjects.140.17199.0\runtimes\win-x64) to the output folder based on the target platform. However, when you publish a web application from VS (I'm using VS2013), the following files get copied to the root of the web application in addition to the bin folder:
    Microsoft.SqlServer.BatchParser.dll
    Microsoft.SqlServer.XE.Core.dll
    Microsoft.SqlServer.XEvent.Linq.dll

    While these files correctly get copied to the bin folder, the application doesn't need a second copy of these files web application root folder.



    • Edited by cbae Wednesday, November 8, 2017 3:01 AM
    Wednesday, November 8, 2017 3:01 AM
  • Hey all,

    Apologies for the delay! I've finally been able to investigate this and it turns out the issue has been due to missing VC Runtime dependencies. You can solve this by downloading and installing the appropriate redist (https://www.microsoft.com/en-us/download/details.aspx?id=40784) for the architecture of the computer running the application.

    Note this doesn't solve the issue with AnyCPU using the x86 version of BatchParser. It's suggested that if you plan on using any functionality that relies on BatchParser (such as database.ExecuteNonQuery or the Restore functionality) that you build your application specifically targeting x86/x64 and distributing as appropriate.

    Let me know if this doesn't solve your issues.

    -Charles Gagnon (chgagnon@microsoft.com)

    Another problem with the Nuget package seems to be related to the Microsoft.SqlServer.SqlManagementObjects.targets file in the packages\Microsoft.SqlServer.SqlManagementObjects.140.17199.0\build\net40 folder. This file is intended to instruct MSBuild to copy the correct version of the runtimes (e.g. files located in packages\Microsoft.SqlServer.SqlManagementObjects.140.17199.0\runtimes\win-x64) to the output folder based on the target platform. However, when you publish a web application from VS (I'm using VS2013), the following files get copied to the root of the web application in addition to the bin folder:
    Microsoft.SqlServer.BatchParser.dll
    Microsoft.SqlServer.XE.Core.dll
    Microsoft.SqlServer.XEvent.Linq.dll

    While these files correctly get copied to the bin folder, the application doesn't need a second copy of these files web application root folder.




    I also get the Microsoft.SqlServer.SqlManagementObjects.targets file error when I build in VSTS build server.
    Wednesday, February 14, 2018 8:29 PM
  • Hi Charles,

    Even with the latest release of the NuGet package (2018-02-22),  we are still getting this error:

    Could not load file or assembly

    'Microsoft.SqlServer.BatchParser, Version=14.100.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies.

    The system cannot find the file specified.


    The redistributable you referenced is already installed for us, but I went ahead and ran the "Repair" option from the installer, just in case, with no luck.

    Help!

    Jonathan Boarman

    Thursday, March 8, 2018 9:03 PM
  • Charles,

    I enabled the Fusion Log and am confused by the result.  It seems like it _might_ be loading the assembly successfully.  It has the same set of messages logged for all the other assemblies that are loaded as well.

    *** Assembly Binder Log Entry  (3/8/2018 @ 3:10:47 PM) ***
    
    The operation was successful.
    Bind result: hr = 0x1. Incorrect function.
    
    Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
    Running under executable  c:\projects\GoogleDataToAzureSql\bin\Debug\GoogleDataToAzureSql.exe
    --- A detailed error log follows. 
    
    BEGIN : Native image bind.
    END   : Incorrect function. (Exception from HRESULT: 0x00000001 (S_FALSE))
    
    
    *** Assembly Binder Log Entry  (3/8/2018 @ 3:10:47 PM) ***
    
    The operation was successful.
    Bind result: hr = 0x0. The operation completed successfully.
    
    Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
    Running under executable  c:\projects\GoogleDataToAzureSql\bin\Debug\GoogleDataToAzureSql.exe
    --- A detailed error log follows. 
    
    === Pre-bind state information ===
    LOG: DisplayName = Microsoft.SqlServer.BatchParserClient, Version=14.100.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91
     (Fully-specified)
    LOG: Appbase = file:///c:/projects/GoogleDataToAzureSql/bin/Debug/
    LOG: Initial PrivatePath = NULL
    LOG: Dynamic Base = NULL
    LOG: Cache Base = NULL
    LOG: AppName = GoogleDataToAzureSql.exe
    Calling assembly : Microsoft.SqlServer.ConnectionInfo, Version=14.100.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91.
    ===
    WRN: No matching native image found.
    LOG: IL assembly loaded from c:\projects\GoogleDataToAzureSql\bin\Debug\Microsoft.SqlServer.BatchParserClient.dll.
    
    
    *** Assembly Binder Log Entry  (3/8/2018 @ 3:10:47 PM) ***
    
    The operation was successful.
    Bind result: hr = 0x0. The operation completed successfully.
    
    Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
    Running under executable  c:\projects\GoogleDataToAzureSql\bin\Debug\GoogleDataToAzureSql.exe
    --- A detailed error log follows. 
    
    === Pre-bind state information ===
    LOG: DisplayName = Microsoft.SqlServer.BatchParserClient, Version=14.100.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91
     (Fully-specified)
    LOG: Appbase = file:///c:/projects/GoogleDataToAzureSql/bin/Debug/
    LOG: Initial PrivatePath = NULL
    LOG: Dynamic Base = NULL
    LOG: Cache Base = NULL
    LOG: AppName = GoogleDataToAzureSql.exe
    Calling assembly : Microsoft.SqlServer.ConnectionInfo, Version=14.100.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91.
    ===
    WRN: No matching native image found.
    LOG: IL assembly loaded from c:\projects\GoogleDataToAzureSql\bin\Debug\Microsoft.SqlServer.BatchParserClient.dll.
    
    

    Am I misreading this?  What could be causing the error loading Microsoft.SqlServer.BatchParser that is not reported in the Fusion Log?

    Jonathan Boarman

    Thursday, March 8, 2018 9:41 PM
  • Hi all, 

    i am currently the owner for SMO and I would like to try to fix any outstanding issues with the batchparser DLL ASAP.

    Based on this thread it looks like there were multiple issues:

    1. The layout of the nuget package and the targets file didn't properly place the native DLLs when a consuming app was compiled, and

    2. Even when the correct copy of batchparser is in the appropriate folder and the C runtime is installed, it won't load. 

    Are both of these issues still active, or just the second one? If someone can post a sample application to aka.ms/sqlfeedback along with a description of the current state of the problems it will help me track it a bit more formally than trying to work through these forum comments.

    thx much


    This posting is provided "as is" and confers no rights.

    Sunday, April 15, 2018 4:45 PM
  • oh, for a quick example, I installed VS 2017 and created a minimal NetFx 4.6.1 console app and added the SMO Nuget dependency.

    When I built it with AnyCPU I got the expected exception of not loading batchparser.

    When I built it with x86 or x64, it ran fine.

    this is the Modules window entry for the x86 build in the debugger:

    Microsoft.SqlServer.BatchParser.dll Microsoft.SqlServer.BatchParser.dll C:\Users\davidshi\source\repos\smobatch\bin\x86\Debug\Microsoft.SqlServer.BatchParser.dll Yes No Skipped loading symbols. 20 2017.0140.1000.169 ((SQLServer).170822-2340) 8/22/2017 5:28 PM 56820000-5685E000 [23784] smobatch.exe [1] smobatch.exe

    this is the code

     static void Main(string[] args)
            {
                var server = new Server(args[0]);
                var database = server.Databases[args.Length > 1 ? args[1] : "master"];
                var query = args.Length > 2 ? args[2] : "select top 10 * from sys.views";
                try
                {
                    database.ExecuteNonQuery(query);
                }
                catch (Exception e)
                {
                    Console.WriteLine("ExecuteNonQuery threw {0}", e);
                }

    }

    The only way batchparser is referenced in the csproj file is through the targets file:

      <Import Project="packages\Microsoft.SqlServer.SqlManagementObjects.140.17235.0\build\net40\Microsoft.SqlServer.SqlManagementObjects.targets" Condition="Exists('packages\Microsoft.SqlServer.SqlManagementObjects.140.17235.0\build\net40\Microsoft.SqlServer.SqlManagementObjects.targets')" />


    This posting is provided &quot;as is&quot; and confers no rights.

    Sunday, April 15, 2018 5:14 PM
  • Hey all,

    Apologies for the delay! I've finally been able to investigate this and it turns out the issue has been due to missing VC Runtime dependencies. You can solve this by downloading and installing the appropriate redist (https://www.microsoft.com/en-us/download/details.aspx?id=40784) for the architecture of the computer running the application.

    Note this doesn't solve the issue with AnyCPU using the x86 version of BatchParser. It's suggested that if you plan on using any functionality that relies on BatchParser (such as database.ExecuteNonQuery or the Restore functionality) that you build your application specifically targeting x86/x64 and distributing as appropriate.

    Let me know if this doesn't solve your issues.

    -Charles Gagnon (chgagnon@microsoft.com)
    When i try that, IIS Crashes....
    i'm writing self updating module that should also update sql database, and it receives a batch of queries.
    Thursday, April 19, 2018 5:13 AM
  • Hi.

    I've just added Microsoft.SqlServer.SqlManagementObjects v140.17267.0-preview via Nuget to one of our solutions to replace local copies of the SMO libraries, and I'm getting this exact error when trying to build and distribute on Platform = AnyCPU. I've switched the platform to x64 for now, but it's not ideal.

    I tried taking local copies of the x86 and x64 dlls and manually referencing them from my project, but no matter which one I used I got architectural mismatch errors.

    This is with Visual Studio 2015 and a .net 4.5 WPF app.

    It's really frustrating. The client that logged the original 'missing BatchParser' error refuses to install the redist for SMO, so we've got to handle it our side.

    Monday, May 28, 2018 1:04 PM
  • even nuget does not provide matched versions...
    Monday, May 28, 2018 1:42 PM
  • Hello

    Check that you have installed in your SQL Server computer at least Microsoft® SQL Server® 2016 Shared Management Objects

    That would do the trick

    Saludos

    RubenC


    Saludos rubenc http://foro.controlc.com.mx

    Thursday, August 2, 2018 2:20 PM
  • Why should this be required? I thought the whole point is that SMO 2017 by itself supports all versions of SQL Server.
    Monday, August 27, 2018 3:31 PM
  • I've got to get a project moving - I can deal with deploying it later.  What part of the SQL 2016 Shared Management Objects need to be installed for so it will recognize Version 14.100.0.0 of the Microsoft.SqlServer.BatchParser and Microsoft.SqlServer.BatchParserClient?
    Monday, September 17, 2018 8:14 PM
  • Any update on this?

    I am getting same error.

    Friday, September 28, 2018 12:54 PM
  • Same with me too, is there an update on this <g class="gr_ gr_21 gr-alert gr_gramm gr_inline_cards gr_run_anim Punctuation only-ins replaceWithoutSep" data-gr-id="21" id="21">please</g>. I don't want to install SQL Management studio or part of it. Is there a way out for this?

    Wednesday, October 24, 2018 11:28 AM
  • I've replied a couple of different times with different results, but I've deleted them because each time I discovered a problem with my replies (explanation below). This is my final reply.

    I am having this issue with the NuGet package version 140.17283.0 when I build my project with AnyCPU.

    I have verified that I can build my project using the x86 or x64 platform and the program WILL run.  However, if I build it with AnyCPU, it will NOT run.

    I have worked around the problem by manually adding references to the following assemblies from the "runtimes\win-x86\native" folder to my project, and enabling "Copy Local":

    Microsoft.SqlServer.BatchParser.dll
    Microsoft.SqlServer.Xe.Core.dll
    Microsoft.SqlServer.XEvent.Linq.dll

    Now, when I include these references and build with AnyCPU, my program will run.

    There is clearly something wrong with how the NuGet package is bundled that affects the ability to build runnable projects using the AnyCPU platform.

    What made this even more confusing for me was the fact that I am also using Costura/Fody to embed assemblies in my EXE.  I discovered that unless I enable the CreateTemporaryAssemblies option in my FodyWeavers.xml file, the program will behave exactly the same as if the DLLs are missing, even if they are embedded in the EXE.

    Therefore, if you are having this problem and you are using Costura/Fody, modify your FodyWeavers.xml file with the CreateTemporaryAssemblies option so the DLLs get loaded from disk instead of from memory:

    <Costura CreateTemporaryAssemblies='true' />

    I hope this is helpful to anyone having the same problems I had with this NuGet package.

    Tuesday, November 6, 2018 2:32 AM
  • Just tried it and it worked for me! Thanks for your post! But as you mentioned it does not solve the problem that you can't use "any CPU" in the build settings
    Friday, November 16, 2018 3:17 PM