locked
LoadPackagedLibrary is broken or at least very counterintuive and undocumented

    Question

  • I've been trying to use LoadPackagedLibrary to load a dll from in my appx...

    Looking around there seems to be a consensus that the documentation for this is woefully inadequate and that there are no examples of use.

    The workaround from the previous thread I found about the issue...

    http://social.msdn.microsoft.com/Forums/en-US/winappswithnativecode/thread/c5636e14-422f-4ab0-b608-2609ad8198e4/?prof=required

    ... simply does not work.

    There is a C# oriented question of a similar nature which appears to have been ignored:

    http://social.msdn.microsoft.com/Forums/en-US/winappswithcsharp/thread/8db1e07e-e41e-4293-93dd-1f1a9a8e5dab

    Any help would be greatly appreciated. It would be nice if we can fix the documentation issue too - MS documentation and tools are usually so good, and there is quite a lot pointing at this function as an answer, but then not quite enough substance in the page itself to make the information it provides genuinely helpful.

    http://msdn.microsoft.com/en-gb/library/windows/desktop/hh447159(v=vs.85).aspx

    Thursday, January 03, 2013 7:37 PM

All replies

  • Can you describe the problem you are having in some detail?
    Thursday, January 03, 2013 9:47 PM
  • sorry for such a delayed reply. basically it seems that there is no combination of paths in the package or in the parameter that allows me to load a .dll - and there is no suggestion in the docs as to how to ensure that it works in terms of where to place a .dll in the package - if there is any special requirement for a location at all.

    i might be able to create a simple repro case, but sadly i have deadlines and targets and not much spare time for even this at the moment.

    thanks for the reply though.

    Tuesday, March 19, 2013 5:52 PM
  • There are essentially two cases here for using LoadPackagedLibrary()

    (1) Referencing a DLL that has been built outside of the VS 2012 solution you are working in:

    • Add the DLL to the project and mark as 'Content=true' so it gets copied into your AppX
    • Make sure the DLL is built using VS 2012 using the DLL CRT. This is the real trick as you cannot have a DLL which needs some older CRT DLL or use static linking.
    • Make sure you have a version of the DLL added as assets for each architecture (x86, x64, arm) which you will have to manage manually. A x64 app can only load x64 DLLs, etc.
    • Remember that this DLL has to pass the WACK tool certification to publish your AppX package.

    (2) Referencing a DLL that is built by your VS 2012 solution

    • Make sure you go to References... for your main EXE project and add a Reference to your DLL project(s)
    • If you use implicit linking rather than explicit linking via LoadPackagedLibrary, it just works
    • To use explicit linking, you need to set Copy Local=true for that reference to get the DLL into your AppX package.

    It's pretty easy to see what's happening by going to Debug\<app>\AppX in your built main EXE project to see if the DLLs got placed in there or not as expected.

    You can't use LoadPackagedLibrary to load a system DLL. You can only use implicit linking for system DLLs.

    Wednesday, March 20, 2013 7:34 PM
    • Make sure the DLL is built using VS 2012 using the DLL CRT. This is the real trick as you cannot have a DLL which needs some older CRT DLL or use static linking.

    I have a 3rd party binary DLL linked against MSVCRT90. I cannot recompile it for use in my LOB app (so Store is not an issue here, neither is WACK).

    Is there really now way to include the older CRT dlls (with proper manifest)?

    I managed to get this to work on some systems, but it fails on others with "The Visual Studio Runtime has been initialized incorrectly" or something along those lines.

    Friday, June 13, 2014 10:30 PM
  • All DLLs you deploy with your Windows Store app for Windows 8.0 must be built with VS 2012. For Windows Store app for Windows 8.1 must be built with VS 2013.
    Saturday, June 14, 2014 12:42 AM