DLL reference

This is probably pretty straight forward, but could someone point me in the right direction? I am new to Windows programming, and even though I followed the SDK and have copied all the respective dll's into my development folder, when I try to open a database connection using Sage_SA_dblyr.dll, I get an error stating that it can not be loaded. I have the correct version of ,NET installed, and have set my environment to x86.

Any pointers would be greatly appreciated.

Thanks

Parents
  • 0

    Hi,

    when I try to open a database connection using Sage_SA_dblyr.dll, I get an error stating that it can not be loaded.

    My install of the SDK shows that file in the sample EXE folder for CPP and VB, it probably has to be in the same folder as the EXE, or in the PATH.   You may get more error info if you open a command prompt in the compiler output folder and run it from the command line.  

    Make sure you can open the data with the Sage 50 application, and that you aren't trying to open a company that is already open in single-user mode.

       If you're using the sample data in C:\Users\Public\Documents\Simply Accounting\2019\Samdata, the login name is sysadmin and the password is blank.

       If you're using a copy of 'real' company data, the password is never longer than 7 characters, and the username may be case-sensitive.

    Are you using the exact version of the SDK to match the data?  The SDK may not be compatible with other data versions.  On a fresh install of the 2019.1 release, the sample file updates from 2019.0 to 2019.1 the first time it is opened with the Sage 50 application.  It won't open with the 2019.1 SDK until it's been updated.

    Can you open the data using one of the three precompiled EXE samples?

    Which language are you using?   There are c#, C++, and VB code samples in the SDK.

    I hope that helps, please post back!

  • 0 in reply to RandyW

    Hi Randy,

    Thanks for getting back to me.

    I have created a dummy set of books with a password. Both the versions of the accounts and the SDK are the same version, as I have turned off auto-update in Sage. I have copied all the dll's to the same debug directory that the exe file is running from, and have set all the references in the IDE (vb by the way). When I try to set this dll as a reference, it fails. And yes, I can access the accounts using all the three precompiled exe samples.

  • 0 in reply to darrelcouzens

    Hi Darrel,

    I have copied all the dll's to the same debug directory that the exe file is running from, and have set all the references in the IDE (vb by the way).

    As a test, try copying the sample EXE file to that directory and running it.  If it runs, then the DLLs are in the right place and available.  If not, then the problem is outside your code.

    When I try to set this dll as a reference, it fails.

    If you're seeing this while working in the IDE, possibly the target is set to 64 bit instead of 32 bit?

    Generally, DLLs have to be the same 'bitness' as the executable.

    The Sample.vbproj has this section that tells the compiler to target X86  (32 bit):

    <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
        <OutputPath>.\</OutputPath>
        <DocumentationFile>Sample.xml</DocumentationFile>
        <DebugSymbols>True</DebugSymbols>
        <DefineDebug>True</DefineDebug>
        <DefineTrace>True</DefineTrace>
        <DefineConstants>Win32=True</DefineConstants>
        <PlatformTarget>x86</PlatformTarget>
        <NoWarn>42016,42017,42018,42019,42032,42353,42354,42355</NoWarn>
        <DebugType>full</DebugType>
        <CodeAnalysisRuleSet>AllRules.ruleset</CodeAnalysisRuleSet>
        <Prefer32Bit>false</Prefer32Bit>
      </PropertyGroup>

    A new file created in the VB IDE might default to a 64 bit target.

  • 0 in reply to RandyW

    Hi Randy,

    From what you're saying, the problem is outside the code as the Sample vb app doesn't work in that directory I have set the processor to 32bit in the IDE with the same properties as the Sample app. I have also added the path to the directory to the PATH even though the path to the Sample is not included. Any pointers would be greatly appreciated.

    Thanks!!

  • 0 in reply to darrelcouzens

    As a test, I made a change, recompiled the sample, and loaded it with no trouble.

    I then tried copying only the debug folder, and then only the executable in a new folder.  It would load every time.

    BUT, this was while the Sage 50 client application (of the same version) was loaded.  According to Help | About Sage 50 | (Support Info button), sort by name, there's SAGE_SA_DBLYR.dll version 26.10.0000.001 size 275288, dated 2018/12/07 loaded from c:\Program Files (x86\Sage 50...

    According to:

    https://docs.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-search-order

    DLLS of the same name will load from memory first, ignoring a copy in the same folder

    If not already loaded, it will load from the cache, if not, and not in the folder, from the path.

    So... maybe turn it off, and turn it on again?

    Only Microsoft dlls seem to end up cached in:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs.

    So it's probably not caching the Sage DLLs.

  • 0 in reply to darrelcouzens
    Any pointers would be greatly appreciated.

    I tried to make it fail to load, so that I could help you troubleshoot, and was more than a little surprised to see that the sample application would load with NO OTHER FILES IN THE FOLDER. 

    Windows somehow helped my application find and use Sage 50 Accounting 2013 DLLs from C:\Windows\SysWOW64, in the sample (VB) application built with the 2019.1 SDK.  I used Windows Sysinternals 'Process Explorer' to check:

    https://kb.froglogic.com/display/KB/Getting+a+list+of+DLLs+currently+loaded+in+a+process

  • 0 in reply to RandyW

    Hi Randy,

    I tried to run it outside the SDK folder structure, and it will load as it is just loading Windows form components. However when you try to run the function to make the connection to the accounts db, it fails with the same error.

    I also put my exe in the sample folder and it runs as it should, however if I make a sub-folder under the sdk sample folder, that fails too. And I added

    I have looked in my PATH to see if the sdk folder is listed there, but no. I also put SetDllDirectoryA function as the first line of code pointing to the development directory, but still no.

    As far as I can see I have the same project properties as the sample, and have re-read the docs, but nothing jumps out.

  • 0 in reply to darrelcouzens
    I tried to run it outside the SDK folder structure, and it will load as it is just loading Windows form components. However when you try to run the function to make the connection to the accounts db, it fails with the same error.

    Hi Darrel,

    If I understand correctly:

     - The precompiled VB.NET sample program runs fine, and you can recompile it and run it from the IDE / from the Debug folder, and it will open the company file you select, and count the number of records in it.

     - The sample file code in Module1.vb finds the data access functions in Sage_SA_dblyr.dll

     - Your code compiles and runs in the IDE (debug folder), then fails to locate the DLL on opening the company file?

    I also put my exe in the sample folder and it runs as it should, however if I make a sub-folder under the sdk sample folder, that fails too.

     - Your compiled EXE runs normally in the sample folder, outside of the IDE, including running after a workstation restart / clean boot?

     - I would expect that the application would fail when run under any folder that did not include the DLLs, however remember that if you have any version of Sage 50 running, or another application has successfully loaded the DLL, or the DLL is still hanging around in memory or in cache, your application may work even when it shouldn't.

    I have looked in my PATH to see if the sdk folder is listed there, but no. I also put SetDllDirectoryA function as the first line of code pointing to the development directory, but still no.

    If the software runs and loads the DLL, Process Explorer can help you find out where & which version but is not be much help if it doesn't load *at all*

    Process Monitor (stop capture, filter the Process Name for your executable name, filter the 'path' for 'dblyr', then start capture) can probably tell you what the application and operating system tried to do, here you see it trying to load the DLL from the current folder, failing, then finding a name match elsewhere:

    Sage_SA_dblyr.dll loading

Reply
  • 0 in reply to darrelcouzens
    I tried to run it outside the SDK folder structure, and it will load as it is just loading Windows form components. However when you try to run the function to make the connection to the accounts db, it fails with the same error.

    Hi Darrel,

    If I understand correctly:

     - The precompiled VB.NET sample program runs fine, and you can recompile it and run it from the IDE / from the Debug folder, and it will open the company file you select, and count the number of records in it.

     - The sample file code in Module1.vb finds the data access functions in Sage_SA_dblyr.dll

     - Your code compiles and runs in the IDE (debug folder), then fails to locate the DLL on opening the company file?

    I also put my exe in the sample folder and it runs as it should, however if I make a sub-folder under the sdk sample folder, that fails too.

     - Your compiled EXE runs normally in the sample folder, outside of the IDE, including running after a workstation restart / clean boot?

     - I would expect that the application would fail when run under any folder that did not include the DLLs, however remember that if you have any version of Sage 50 running, or another application has successfully loaded the DLL, or the DLL is still hanging around in memory or in cache, your application may work even when it shouldn't.

    I have looked in my PATH to see if the sdk folder is listed there, but no. I also put SetDllDirectoryA function as the first line of code pointing to the development directory, but still no.

    If the software runs and loads the DLL, Process Explorer can help you find out where & which version but is not be much help if it doesn't load *at all*

    Process Monitor (stop capture, filter the Process Name for your executable name, filter the 'path' for 'dblyr', then start capture) can probably tell you what the application and operating system tried to do, here you see it trying to load the DLL from the current folder, failing, then finding a name match elsewhere:

    Sage_SA_dblyr.dll loading

Children
No Data