Referenced assemblies not being cached?

asilva
edited August 2011 in Photon Server
We're trying to add a physics package to our Photon server application. We've done this by implementing a wrapper dll in managed C++ which wraps the functionality contained in NVIDIA's PhysX package (native C/C++ dll's). The reference lineage looks like this:
Our derived Photon server app (C#)
               |
          references
               |
               V
Our PhysX wrapper dll (Managed C++)
               |                                  
      links at runtime with
               |
               V
NVIDIA PhysX dll's (Native C/C++)

Unfortunately, we're unable to turn on EnableAutoRestart for our application with this setup. It seems that the bottom level dlls do not appear in the Cache folder with the other dlls so they don't get loaded when that setting is true (and consequently, our physics doesn't work). If we set it to EnableAutoRestart = false, it looks like it doesn't use the Cache folder (i.e. we deleted it to make sure) and just loads the dlls that are there in the same folder, as one would expect.

As a test, we built a managed C++ dll that was being referenced by our physx wrapper to see if it was a native vs. managed issue and it's not - the referenced assembly did not get cached either.

So, does Photon only cache assemblies that are referenced by the server app and NOT their dependencies? If so, is this something that will be addressed at some point in the future so that we can turn EnableAutoRestart back on? This is going to be a fairly serious bottleneck to always have to manually restart the server every time we make a change.

Comments

  • I am not sure if there is a work-around. We use a standard approach to host the .NET Runtime so I assume only Microsoft can fix it.
    We are currently busy finishing Photon 3.0 so it might take a while until we can build a test that reproduces the issue.
  • I think you might be misunderstanding the issue (or maybe I didn't do a good job of explaining it :).

    Everything works fine when EnableAutoRestart is disabled because the runtime is looking in the bin directory where all the dlls are located (this is the part that would be Microsoft's issue, but it works fine, so I don't believe that it is). When EnableAutoRestart is true, Photon seems to implement some caching system where the dlls that the runtime knows about are put into separate Cache folders. The dlls that are more than 1 level deep, whether they be managed or native, are not placed in any Cache folder so the dlls that depend on them don't load properly.

    Does this help clear things up at all?
  • I understood, sorry for being unclear.
    The shadow copying (which is necessary to allow you to change files in the bin folder while photon is running) is an appdomain hosting feature from microsoft and given we used the microsoft libraries correct we wouldn't be able to fix it. However, after taking a quick look at the sources I identified a possible bug.
    I'll keep you updated.
  • Ah ok. Sorry for the misunderstanding. I wasn't aware that the shadow copying was provided by Microsoft.

    Looking forward to hearing back about the possible bug.

    Thanks for looking into it!
  • well that wasn't a bug it turns out. shadow copying just doesn't include unmanaged dlls.
    we are still investigating if there is a solution.
    By the way, did you manage to load the unmanaged dll with .net 4 ?
  • Actually, as I said above, I did a test where the wrapper dll also referenced a managed dll in addition to the unmanaged dlls and the managed one did not get shadow copied, either.

    Also, everything loads fine if I turn off EnableAutoStart, so yes, it is working with .net 4 (unless you mean something else by your statement).
  • Ok, good to know. Thank you.
    I had problems to load the unmanaged dll with .net 4 (Mixed mode assembly is built against version 'v2.0.50727' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information). If it works for you I did something wrong.