locked
Dlls not loading after adding ARM platform to solution RRS feed

  • Question

  • I have a solution containing only C++ projects and some unit test projects.

    During the test runs I often explicitly load dlls which are located in the same directory as the test assembly. This has been working since I started using unit testing.

    Last week I added the ARM platform to the solution in order to evaluate UWP. This caused Visual Studio to add Debug/Release|ARM configurations to all the projects including the test projects.

    When I wanted to run the tests this morning, loading of dlls suddenly did not work anymore (the selected configuration was Debug|Win32). I had to manually remove the ARM configurations from the test vcxproj files before it worked again.

    Is this expected or erroneous behaviour?

    Update: in the meantime I have unloaded and reloaded the solution and my workaround does not work anymore. I tried unloading/reloading of the test project about 10 times and only three times a was able to load the dlls properly.

    For now I have added a call to SetDllDirectory in the test code, but this is very unsatisfactory since dll loading in tests had been working before as I wrote above.

    Please comment.

    • Edited by hpetschko Monday, June 13, 2016 2:25 PM
    Monday, June 13, 2016 8:06 AM

Answers

  • Hi Hansjoerg,

    I could repro this issue in my side.

    Actually if I clean and rebuild the whole solution(two projects), the test still is failed if I run it.

    One workaround is that change the dll's path from:

    HMODULE hmod = ::LoadLibraryW(L"DllLoadTest.dll");	

    to

    HMODULE hmod = ::LoadLibraryW(L"C:\\Users\\xxx\\Documents\\Visual Studio 2015\\Projects\\DllLoadTest\\Debug\\DllLoadTest.dll");

    It seems that we need to use the absolute path.

    Best Regards,

    Jack


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    Friday, June 17, 2016 10:13 AM

All replies

  • Hi hpetschko,

    >>Last week I added the ARM platform to the solution in order to evaluate UWP. This caused Visual Studio to add Debug/Release|ARM configurations to all the projects including the test projects.

    Do you get any error messages during you run your test? Is it the VC++ unit test project?

    Click->Build->Configuration manager, there you could set the platform target for every project. So there you could select different platform targets for different projects.

    Like the following screen shot, I could run the test well.

    I could run the test well in VS2015 even if I select the "ARM" platform target.

    So if you test it using a simple test project, how about the result? I think we would analyze the detailed error messages.

    Best Regards,

    Jack


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, June 14, 2016 11:03 AM
  • Hi Jack,

    I did some more experiments, and here are my findings so far:

    1) I loaded my solution which contains the software (VC++) to be tested and the tests (VC++) as well. I removed the call to SetDllDirectory (see my first mail), built the test and it ran successfully, which means that the dlls could be loaded.

    2) I unloaded the solution, then reloaded it and ran the test again. The dlls could not be loaded and the test failed. There were no error messages in the output window.

    3) I unloaded the test project only and reloaded it. Trying to run the test directly afterwards did not succeed (actually the test did not even start), and in the output window I could see the error message: 'The operation was canceled.'

    4) I did some pseudo editing in one of the source files of the test project, built it again (not rebuilt, only built) and ran the test successfully several times in a row.

    5) I unloaded the test project, reloaded it and the result was the same as in 3)

    My setup: Windows 10 Enterprise, VS 2015 V 14.0.25123.00 Update 2

    Next I will create a small solution containing a dll and a test project which explicitly loads the dll. I will add the ARM platform later and see if this changes anything.

    Regards

    Hansjoerg

    Tuesday, June 14, 2016 4:13 PM
  • Hi Hansjoerg,

    >>Next I will create a small solution containing a dll and a test project which explicitly loads the dll. I will add the ARM platform later and see if this changes anything.

    If you get any latest information, please feel free to let me know.

    In addition, if a simple solution works well, I suggest you create a new blank solution, and then add all projects' files to the new blank solution, and then clean and rebuild the solution/projects, check it again.

    Best Regards,

    Jack


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Wednesday, June 15, 2016 8:37 AM
  • Hi Jack,

    well I think, I made a mistake here.

    In fact I changed two things simultaneously, of which one has caused the problems, though not the one which I thought it was.

    I indeed made massive changes to the project files by adding the ARM platform. But I also changed my behaviour - a little bit.

    And it was this small change which caused the problems: Monday morning I thought 'let's do some testing', loaded the solution and started the test. Which failed. Normally I do the testing after I have made changes to the code, so after having built the solution. This scenario is still working, even after having added the ARM platform. One can also see this pattern when examining the experiences I described in my previous post.

    As announced I have created a small test solution with a dll and a native unit test project. And with it I can perfectly reproduce what I have described:

    1) Both dlls are in the same directory
    2) In the test method I call LoadLibraryW with only the name and extension of the dll, no absolute path given
    3) After having built the solution this works
    4) Running the test right after having loaded the solution fails
    5) Making pseudo changes to the loaded dll's code and building makes the test succeed again

    Thus I have to change my question: Why does explicitly loading a dll in a unit test fails after loading the solution, but succeeds after having built it after loading?

    Best regards

    Hansjoerg

    Wednesday, June 15, 2016 7:14 PM
  • Hi Hansjoerg,

    Would you please share us the detailed error message during you run your test?

    >>Making pseudo changes to the loaded dll's code and building makes the test succeed again.

    Not very sure that whether I understand this issue correctly, if you build your whole solution after you change the code, whether you will get some information like "projects are out of date" in your output window. It seems that the code changed was not updated/saved like this case:

    http://stackoverflow.com/questions/2646858/visual-studio-2010-isnt-building-before-a-run-when-there-are-code-changes

    During the test project loaded the dll file which was editing, and not saved, maybe it would share us some information like "the process or dll file was called by other processes" or "couldn't find and load it" errors. Maybe you could share us the detailed error you got in your side. But my understanding is that the real issue is that the code changes was not really saved and called, that's reason why it works well after you build it.

    Best Regards,

    Jack


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Thursday, June 16, 2016 6:47 AM
  • Hi Jack,

    here is how I think you can reproduce the problem:

    1) Create a Win32 project (and implicitly a new solution): Templates/Visual C++/Win32 Project and name it DllLoadTest. In the application settings choose Dll and remove SDL checks. Do not make any changes to the source code.

    2) To the same solution add a test project: Installed/Visual C++/Test/Native Unit Test Project, accept the default name UnitTest1. In the automatically created test method TestMethod1 add the following code

       HMODULE hmod = ::LoadLibraryW( L"DllLoadTest.dll" );
       if ( hmod == nullptr )
           Assert::Fail();

    3) Build the solution. Both dlls are created in the directory SolutionDir/Debug.  Run the test. It should succeed.

    4) Close the solution, reload it and run the test. It should fail. WHY?

    5) In TestMethod1 add a space, remove it again and build the project. Then run the test. It should succeed. WHY NOW?

    That's it. As you can see, there were no code changes between the steps 3 and 4.

    I hope this helps.

    Best regards

    Hansjoerg

    Thursday, June 16, 2016 9:10 AM
  • Hi Hansjoerg,

    I could repro this issue in my side.

    Actually if I clean and rebuild the whole solution(two projects), the test still is failed if I run it.

    One workaround is that change the dll's path from:

    HMODULE hmod = ::LoadLibraryW(L"DllLoadTest.dll");	

    to

    HMODULE hmod = ::LoadLibraryW(L"C:\\Users\\xxx\\Documents\\Visual Studio 2015\\Projects\\DllLoadTest\\Debug\\DllLoadTest.dll");

    It seems that we need to use the absolute path.

    Best Regards,

    Jack


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    Friday, June 17, 2016 10:13 AM