StackOverflowException - how to debug?

[nmarler]

(Is this proper forum for this type of question?)

Costura was working quite nicely for me, but looks like I've done something it does not like. When I launch my application I'm receiving a StackOverflowException inside Costura.AssemblyLoader.ResolveAssembly.

I'm working with a Prism app (WPF), the exception occurs when I call my Bootstrapper.Run method, so I assume there is some problem with loading the Prism libraries

Any advice is appreciated to save time, maybe something simple you might know about.

Thanks

Nate

[distantcam]

As of 0.8 you can now step through the Costura template.

Debugging (from the wiki)

Hope that helps.

[nmarler]

(Ugh. Sorry I missed the wiki)

Ok, so now I see the problem but don't know how to fix, maybe you can advise. My executable references two different versions of an assembly, happens to be Microsoft.Practices.Unity 2.1.505.0 and 3.0.0.0. So in Costura's ILTemplate.cs the referencedAssemblies array contains an entry for each. When the ResolveAssembly method is called to resolve the 3.0.0.0 version, referencedAssemblies is enumerated, and it comes across the 2.1.505.0 version first and immediately calls Assembly.Load (line 27) resulting in StackOverflowException soon after. Maybe it should continue to enumerate the entire array before giving up and calling Assembly.Load?

I have confirmed that things do work properly when the referenced DLLs are left in same folder as the EXE. No surprise, because Costura's ResolveAssembly is not called, but just to let you know that things do work properly when Costura is not called upon to resolve the assembly.

Thanks,

Nate

[distantcam]

Hmmm, ok.

You could exclude Microsoft.Practices.Unity from Costura, causing both to be loaded from disk.

But I'm wondering why do you have 2 different versions of Unity? Could you redirect the versions to 3.0?

Redirecting Assembly Versions

[nmarler]

I think I've been down that path with no luck, but it started to involve more .NET plumbing than I'm familiar with. Here's what I've found out...

• No project in my solution references the 2.1 version, everything references the 3.0 version
• This is confirmed by NuGet manager, which shows only the 3.0 version as an installed package
• Also, using RedGate's .NET Reflector tool I can see that my application in fact dependent on both versions, which is consistent with Costura's enumeration of its referencedAssemblies array
• As far as I can tell, one of my dependent (3rd party) assemblies is marked as being dependent on the 2.1 version, and so it gets added to my application's list of dependencies (is that how that works?). (The specific 3rd party assembly happens to be Microsoft.Practices.Prism.UnityExtensions, not sure if that matters)
• Turns out that my app.config already includes for the Unity assembly. I'm not sure how it got there, maybe NuGet? or Costura? Anyway, I've confirmed that the statement makes it un-altered into the final MyApp.exe.config file that get generated (I was unaware of the new automatic binding redirect functionality your linked article described. My app targets .NET 4.5, I'm using VS 2013).
• No luck excluding Unity from Costura. I'm using <Weavers><Costura ExcludeAssemblies='Microsoft.Practices.Unity'/></Weavers>, but the StackOverflowException still gets thrown (the recommended Target section in my project file still deletes it?)

Interested to know if you think that Costura's ResolveAssembly method is bailing out early, or maybe the fix is more complicated than that

Hope that helps, thanks

[distantcam]

@SimonCropp Could you please explain line https://github.com/Fody/Costura/blob/master/Template/ILTemplate.cs#L25 to me?

if (assembly.Name == requestedAssemblyName.Name && assembly.Version != requestedAssemblyName.Version)

I don't understand why the version check passes if they're not the same.

[SimonCropp]

I think it was because .net was firing a AssemblyResolve for an assembly with an incorrect version number, probably dues to some binding redirect issue. But looking at it now I dont think that is a case we should handle.

And obviously a shitty commit on my part since i did not add a unit test of valid comments so even if the change is justified it should be rolled back. i can then try to replicate again and raise a proper issue for it.

[distantcam]

Ok, I've removed that code in 1.0.

I agree, if the assembly resolver is failing for assemblies that are not managed by Costura, we shouldn't be dealing with it.

[nmarler]

Looks like the fix is working for me. Thank you, I've got Costura back up and running

(Good timing, delivery due this week!)
—
Sent from Mailbox for iPhone

On Sat, Feb 1, 2014 at 2:45 AM, Cameron MacFarland
[email protected] wrote:

Ok, I've removed that code in 1.0.

I agree, if the assembly resolver is failing for assemblies that are not managed by Costura, we shouldn't be dealing with it.

Reply to this email directly or view it on GitHub:
#48 (comment)