.net framework - Warning while running NGen: "Cannot hardbind to System.Core"

08
2014-07
  • rojomoke

    While running ngen on the dll's that constitute our product, one in particular comes up with this message:

    1>    Compiling assembly C:\folder\component.dll (CLR v4.0.30319) ...
    1>WARNING: Cannot hardbind to System.Core, Version=4.0.0.0, Culture=neutral,     PublicKeyToken=b77a5c561999e089 because dependency does not have a native image (check FusLogVw for reason)
    1>component, Version=99.99.99.99, Culture=neutral, PublicKeyToken=null <debug>
    

    This happens on multiple systems, Windows 7 and XP, with .NET 4.0 installed.

    I can't find anything relevant via Google, or on this site, although Recurring crash: "An unhandled win32 exception occurred in mscorsvw.exe". How to diagnose/fix? seems similar.

    Can anyone tell me why this one particular DLL might produce this message, while none of our other components do?

  • Answers
    Know someone who can answer? Share a link to this question via email, Google+, Twitter, or Facebook.

    Related Question

    networking - running a.net application on a network share
  • Brad

    I have a .net 2.0 winform application that I would like users to run from from a network share. Are there any disadvantages to doing this?


  • Related Answers
  • John T

    If the application was coded to use configuration files in the same directory, users will encounter problems. I'm sure you also don't want to give write permissions to the network share for users. Make sure the application can be configured to write user settings to their home directory if it saves any.

    .NET applications also don't allow you to use DLLs on networked or mapped drives. You can read how to fix this here.

  • heavyd

    There are a few gotcha's you have to watch out for running .NET applications from a network share. Specifically, .NET applications fun from a network share by default run at low trust, meaning they will not be granted to several system resources including file access, registry, etc. So if the application is not specifically designed to run at low trust, you will likely run into problems.

    According to Brad Adams at Microsoft, there are no security concerns running applications like this and there is a nice tutorial from a Microsoft blog on how to work around this low-trust issue. Once that is fixed, your application should run just like any other .NET app.