Chris, thanks for your reply. Us Douglas Adams fans have to stick together ; )
This problem appears in both debug and release mode. It only seems to occur when you choose “Line-level and method-level timings”, which sadly is what I need. The fact that one of my consoles works perfectly and one fails is baffling, considering that the simpler of the two manifests the problem (wouldn’t you think that the complex one would be more likely to break LOL).
I don’t believe this is caused by a corrupt PDB since I was able to readily reproduce the problem in a new project by creating a simple wizarded console using the C# code I showed in the first post there, and as I mentioned it still happens in both debug and release.
I’m using Visual Studio 2008 SP1 to build the project(s) on and x64 machine, all assemblies configured for “Any CPU” - and even on the off chance that the pre-built Unity assemblies might be the problem I downloaded the source and built them myself – even when I build the project with the actual unity source, attach to the project with a debugger when it’s loaded by ANTS but before the Unity .ctor and then attempt to step into the Unity .ctor “UnityContainer unity = new UnityContainer();” it crashes immediately with:
Message="Bad unmanaged code entry point."
at UnityUnderANTS.Program.Main(String args) in C:\\Temp\\UnityUnderANTS\\UnityUnderANTS\\Program.cs:line 16
I have carefully examined the build settings for the unity assemblies and they look like entirely typical pedestrian assemblies to me. If you run that sample project I posted under the debugger only and look at the loaded modules in the debugger here’s what it lists:
Again this doesn’t look especially fishy to me. I can even force the Unity assemblies to load first as follows:
This works fine, even under ANTS - until I try to new up Unity, and then it still crashes as before. Finally, if I attach to the project with a debugger when it’s loaded by ANTS but before the .ctor and then set breakpoints both in the Unity .ctor and its base I don’t hit those breakpoints – it’s like something lower level is crashing me.
As to your other question, I don’t use Unity in any different *way* between either of my console applications – they both allocate a container using ‘new’ as shown above. One big endemic difference though is that the ‘working’ scenario uses the .NET Application Extensibility namespace (described here http://msdn.microsoft.com/en-us/magazine/cc163476.aspx
). Each AddIn loaded in my pipeline builder still ‘news up’ a Unity container though. Clearly something about the context in which my AddIn is called by the pipeline builder is serendipitously making this work.
I did try one last experiment of creating a new AppDomain and then allocating my unity container inside a new AppDomain (as that’s what happens with the pipeline builder) but that did not work either – so something else about the pipeline builder is magic besides its use of AppDomains.