none
SQL CE 3.5 SP2 private deployment: Can the the x86 SQL CE directory be shared with other x86 DLLs?

    問題

  • Following ErikEJ's guidance in http://erikej.blogspot.com/2012/05/private-deployment-of-sql-server.html, can other 32-bit DLLs be deployed in or above this directory, or is the distinction of AMD64/x86 DLLs somthing unique to SQL CE?

    For example, if I build my VS 2010 project targeting AnyCPU, the default (Debug) build output folder is /bin/Debug.  With the AMD64 and x86 DLL folders for private deployment of SQL CE, I get an output directory structure like bin/Debug/x86 and bin/Debug/x86 which is understandable.

    But when my build configuration is x86, the default build output folder is /bin/x86/Debug and with the SQL CE 23/64-bit DLL distinction, I find that my output folder structure is /bin/x86/Debug/x86 and  /bin/x86/Debug/AMD64 which is confusing.

    Since I am targeting only 32-bit, for a simpler deployment folder structure can I:

    • specify /bin/Debug as the default output path,
    • put the x86 and AMD64 folders under Debug for the SQL CE x86 and AMD64 DLLs
    • put the remaining x86 DLLs in /bin/Debug as the root application path

    Thanks for any guidance.


    -BGood

    2012年6月12日 下午 07:00

解答

  • ErikEJ,

    "Delete everything in your project's bin folder, build and then see what is there" was a very good suggestion.  I had included several directories and items as content, some of which were under /bin, hence the repeating directory structure.  Now the hierarchy is:

    /bin
    .../x86
    ....../Debug

    Which is what one might expect.  Unfortunately, the application no longer runs which is probably due to the missing dlls, including the ones for SQL CE.  Now I need to add some of them back in. 

    Thanks.


    -BGood

    • 已提議為解答 ErikEJMVP, Moderator 2012年6月18日 上午 10:20
    • 已標示為解答 BGood 2012年6月18日 下午 12:09
    2012年6月13日 下午 05:24

所有回覆

  • You are just deploying the files from  /bin/x86/Release, so do not spend too much time looking at them.

    The distinction of AMD64/x86 DLLs is something unique to SQL CE, as noted in my blog, yes.


    Please mark as answer, if this was it. Visit my SQL Server Compact blog

    2012年6月13日 上午 10:00
    版主
  • Thanks, ErikEJ.  To clarify your answer, my question had deployment aspects relevant to both SQL CE and Visual Studio:

    • specify /bin/Debug as the default output path,
    • put the x86 and AMD64 folders under Debug for the SQL CE x86 and AMD64 DLLs
    • put the remaining x86 DLLs in /bin/Debug as the root application path

    I understand your answer to mean that with respect to the root application folder of a specific build configuration (in my case could be /bin/x86/Debug or /bin/x86/Release), irrespective of the root folder SQL CE private deployment uses x86 and AMD64 subdirectories to differentiate SQL CE DLLs and I should not plan on using those folders for other x86 DLLs I deploy.  Correct?

    With respect to the more general Visual Studio deployment question, under Project > Compile > Build output path I can specify a root output folder for my project Builds.  My current compile settings are: Configuration-Active (Debug) and Platform-Active (Any CPU) and the Build output path VS suggests is bin/x86/Debug.  But when I look in my root project folder in solution explorer I have the following /bin folder hierarchy which I find very confusing:

    Solution
    ...\Project
    ......\bin
    .........\Debug
    ............\AMD64 (SQL dlls)
    ............\bin
    ...............\Debug (Interop.SHDocVw.dll)
    ............\x86 (SQL dlls)
    ............(reference dlls)
    .........\Release (nothing yet)
    .........\x86
    ............\Debug
    ...............\AMD64 (SQL dlls)
    ...............\bin
    ...............\x86 (reference dlls)
    ............\Release

    Is this rat's nest of directories normal for Visual Studio or do I have something misconfigured?  I am thinking that this crazy /bin directory hierarchy may be the result of including some deeply-nested project reference or content with CopyLocal=True.

    For deployment, this is not particularlyt problematic because my build installer can just pick out what it needs from the rat's nest.  But I really would like to clean this up if possible before proceeding to the Release configuration where the rat's nest would probably be duplicated again.

    So, back to my original question, since I am buyilding solely for x86 deployment, can I simply specify /bin/Debug for the build output directory and eliminate the x86 and AMD64 references to simplify things?

    And where should I looking for the Include/CopyAlways component(s) which are causing this rat's nest?  Thanks.


    -BGood


    • 已編輯 BGood 2012年6月13日 下午 04:26
    2012年6月13日 下午 04:24
  • The odd file in /Project/Bin/Debug/Bin/Debug looks like a Internet Explorer reference.

    I do not  know how to avoid the x86 part of the path.

    I would delete everything in your project's bin folder, build and then see what is there.


    Please mark as answer, if this was it. Visit my SQL Server Compact blog

    2012年6月13日 下午 04:30
    版主
  • ErikEJ,

    "Delete everything in your project's bin folder, build and then see what is there" was a very good suggestion.  I had included several directories and items as content, some of which were under /bin, hence the repeating directory structure.  Now the hierarchy is:

    /bin
    .../x86
    ....../Debug

    Which is what one might expect.  Unfortunately, the application no longer runs which is probably due to the missing dlls, including the ones for SQL CE.  Now I need to add some of them back in. 

    Thanks.


    -BGood

    • 已提議為解答 ErikEJMVP, Moderator 2012年6月18日 上午 10:20
    • 已標示為解答 BGood 2012年6月18日 下午 12:09
    2012年6月13日 下午 05:24