none
NGEN doesn't seem to be working with large application (using MEF) RRS feed

  • Question

  • I have a large application with upwards of 100 class libraries and one executable. The application uses a lot of MEF for dependency injections (don't know if this affects NGEN).

    I have run NGEN on the executable and the process seems to complete successfully. I verified that *.ni.dll files were created for *some* of the dependencies of my executable. When I launch the application, however, it appears that all the MSIL DLLs are loaded from the binaries directory (I've verified using the Modules window in the VS2010 debugger as well as the ProcessExplorer sysinternals tool).

    How can I go about troubleshooting why the native binaries aren't being loaded up?

    Thanks!


    • Edited by sohummm Tuesday, June 28, 2011 7:19 PM added more info to title
    • Moved by Paul Zhou Monday, July 18, 2011 8:58 AM (From:Common Language Runtime)
    • Moved by spacewrangler Tuesday, August 2, 2011 5:15 AM (From:Building Development and Diagnostic Tools for .Net)
    Tuesday, June 28, 2011 7:18 PM

All replies

  •  

    Hi,

     

    According to MSDN document, starting with the .NET Framework 4, the native images that are generated with Ngen.exe can no longer be loaded into applications that are running in partial trust. Instead, the just-in-time (JIT) compiler is invoked.

     

    Much further information, you can refer to:

    Ngen.exe (Native Image Generator)

     

    I hope this can help you.


    Paul Zhou [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Thursday, June 30, 2011 4:49 AM
  • As far as I am aware the application is running in full trust. This is a WPF application. Do I need to do anything special to make it run in full trust?

    Also, here is a sample log file (using fuslogvw) for what is going on. As I mentioned above, the assemblies exist in the NativeImages directory in C:\Windows\assembly:

        *** Assembly Binder Log Entry  (6/29/2011 @ 10:14:04 AM) ***
       
        The operation failed.
        Bind result: hr = 0x80070002. The system cannot find the file specified.
       
        Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
        Running under executable  C:\Path\To\My\Binaries\MyCompanyName.MyApp.exe
        --- A detailed error log follows.
       
        === Pre-bind state information ===
        LOG: User = username
        LOG: DisplayName = MyCompanyName.MyAssembly, Version=1.0.2.0, Culture=neutral, PublicKeyToken=null
         (Fully-specified)
        LOG: Appbase = file:///C:/Path/To/My/Binaries/
        LOG: Initial PrivatePath = NULL
        LOG: Dynamic Base = NULL
        LOG: Cache Base = NULL
        LOG: AppName = MyCompanyName.MyApp.exe
        Calling assembly : MyCompanyName.AnotherAssembly, Version=1.0.2.0, Culture=neutral, PublicKeyToken=null.
        ===
        LOG: Start binding of native image MyCompanyName.MyAssembly, Version=1.0.2.0, Culture=neutral, PublicKeyToken=null.
        WRN: No matching native image found.
        LOG: IL assembly loaded from C:\Path\To\My\Binaries\MyCompanyName.MyAssembly.dll
    Thursday, June 30, 2011 4:26 PM
  •  

    Hi,

     

    According to the error log, it seems that the native image is not found.

    I assume you use ngen.exe in Visual Studio Command Prompt. I think that you need to check whether you input a valid file path of the native image(assembly) and then check whether you has the privilege to access it. I suggest run Visual Studio Command Prompt as Administrator.

     

    Another possible root cause may be UAC if you are running on Windows Vista or Windows 7. You could try to disable UAC by modifying the registry.

    You can set the disableUAC  Value in the registry (HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System)  to be 0 to disable and to 1 to enable.

     

    I hope this can help you.


    Paul Zhou [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Proposed as answer by Paul Zhou Wednesday, July 6, 2011 8:04 AM
    • Marked as answer by Paul Zhou Monday, July 11, 2011 2:54 AM
    • Unmarked as answer by sohummm Friday, July 15, 2011 7:40 PM
    Friday, July 1, 2011 5:07 AM
  •  

    Hi,

     

    Has your issue been resolved? Would you mind letting us know the result of the suggestions?

     

    Now I will mark an answer, you can mark others that you think to be so useful to your issue.

    If you still have any questions about this issue, please feel free to let me know. We will continue to work with you on this issue.

     

    Have a nice day!


    Paul Zhou [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, July 11, 2011 2:54 AM
  • I am running it from the Visual Studio Command Prompt. I'm not sure what you mean by:

    I think that you need to check whether you input a valid file path of the native image(assembly) and then check whether you has the privilege to access it. I suggest run Visual Studio Command Prompt as Administrator.

    I can try running the command prompt as Admin.

    I don't think UAC is the issue because I have UAC turned off.

    Friday, July 15, 2011 7:36 PM
  • Running as admin did not change the result. It is still loading the DLLs from near the application.
    Friday, July 15, 2011 7:41 PM
  • Move to Building Development and Diagnostic Tools for .Net forum for better support.
    Paul Zhou [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, July 18, 2011 8:59 AM