Exceptions thrown on startup

[m3taphysics]

Hello, I am not sure wahts causing this but it appears on startup I get LOTS of exceptions. Removing Costura appears to fix it. If you can give me an idea of somthing to try or look at, I can hopefully solve the problem :).

First-chance exception at 0x000007FEFD13940D in DataForge.exe: Microsoft C++ exception: EEFileLoadException at memory location 0x00000000001EAEE0. First-chance exception at 0x000007FEFD13940D in DataForge.exe: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000. First-chance exception at 0x000007FEFD13940D in DataForge.exe: Microsoft C++ exception: EEFileLoadException at memory location 0x00000000001EAEE0. First-chance exception at 0x000007FEFD13940D in DataForge.exe: Microsoft C++ exception: EEFileLoadException at memory location 0x00000000001EBB50. First-chance exception at 0x000007FEFD13940D in DataForge.exe: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000. First-chance exception at 0x000007FEFD13940D in DataForge.exe: Microsoft C++ exception: EEFileLoadException at memory location 0x00000000001EBB50. First-chance exception at 0x000007FEFD13940D in DataForge.exe: Microsoft C++ exception: EEFileLoadException at memory location 0x00000000001EBAE0.

[distantcam]

Is your app written in C++? Costura won't work with C++ apps.

Is your main method in a class with other references to libraries embedded by Costura? If so try moving your main method into a class on it's own.

[m3taphysics]

Hey no it's a WPF app which uses a C++ unmanaged DLL though does that matter?

Can you explain how to correctly setup my main method?

Thanks On 15 Apr 2015 03:22, "Cameron MacFarland" notifications@github.com wrote:

Is your app written in C++? Costura won't work with C++ apps.

Is your main method in a class with other references to libraries embedded by Costura? If so try moving your main method into a class on it's own.

— Reply to this email directly or view it on GitHub https://github.com/Fody/Costura/issues/107#issuecomment-93155483.

[distantcam]

Just put the main method in a separate class.

class Program {
    static void Main(string[] args) {
        Loader.Run(args);
    }
}

class Loader {
    static void Run(string[] args) {
        // Your actual main code.
    }
}

Also for unmanaged code Costura doesn't always work, and you may be better off not using Costura for them. The problem is unmanaged code handles it's own dependencies and so it may have custom code to look for dependencies in files in different paths, or with different names.

[m3taphysics]

Hmm its not added as a reference to the project but I do use some of its methods by loading the DLL at runtime. That shouldn't affect costura should it?

I'll try the main method thing when I get In to work :). On 15 Apr 2015 06:17, "Cameron MacFarland" notifications@github.com wrote:

Just put the main method in a separate class.

class Program { static void Main(string[] args) { Loader.Run(args); } }

class Loader { static void Run(string[] args) { // Your actual main code. } }

Also for unmanaged code Costura doesn't always work, and you may be better off not using Costura for them. The problem is unmanaged code handles it's own dependencies and so it may have custom code to look for dependencies in files in different paths, or with different names.

— Reply to this email directly or view it on GitHub https://github.com/Fody/Costura/issues/107#issuecomment-93192749.

[m3taphysics]

This is the application entry point:

    /// <summary>
    /// Application Entry Point.
    /// </summary>
    [System.STAThreadAttribute()]
    [System.Diagnostics.DebuggerNonUserCodeAttribute()]

[System.CodeDom.Compiler.GeneratedCodeAttribute("PresentationBuildTasks", "4.0.0.0")] public static void Main() { DataForge.App app = new DataForge.App(); app.InitializeComponent(); app.Run(); }

But its auto generated by visual studio? in App.g.i.cs?

On Wed, Apr 15, 2015 at 6:29 AM, Ashley Canning ashley.canning@gmail.com wrote:

Hmm its not added as a reference to the project but I do use some of its methods by loading the DLL at runtime. That shouldn't affect costura should it?

I'll try the main method thing when I get In to work :). On 15 Apr 2015 06:17, "Cameron MacFarland" notifications@github.com wrote:

Just put the main method in a separate class.

class Program { static void Main(string[] args) { Loader.Run(args); } }

class Loader { static void Run(string[] args) { // Your actual main code. } }

Also for unmanaged code Costura doesn't always work, and you may be better off not using Costura for them. The problem is unmanaged code handles it's own dependencies and so it may have custom code to look for dependencies in files in different paths, or with different names.

— Reply to this email directly or view it on GitHub https://github.com/Fody/Costura/issues/107#issuecomment-93192749.

[distantcam]

That's the standard WPF main, which should be ok unless you're referencing anything else in App.

What is DataForge.exe? Is it being embedded by Costura?

[m3taphysics]

Thats the main executable. Thats where I have installed Costura.

On Wed, Apr 15, 2015 at 7:30 AM, Cameron MacFarland < notifications@github.com> wrote:

That's the standard WPF main, which should be ok unless you're referencing anything else in App.

What is DataForge.exe? Is it being embedded by Costura?

— Reply to this email directly or view it on GitHub https://github.com/Fody/Costura/issues/107#issuecomment-93218159.

[m3taphysics]

Whats more interesting is - the exceptions are thrown but the application runs fine if they are ignored...!

On Wed, Apr 15, 2015 at 7:24 AM, Ashley Canning ashley.canning@gmail.com wrote:

This is the application entry point:

    /// <summary>
    /// Application Entry Point.
    /// </summary>
    [System.STAThreadAttribute()]
    [System.Diagnostics.DebuggerNonUserCodeAttribute()]

[System.CodeDom.Compiler.GeneratedCodeAttribute("PresentationBuildTasks", "4.0.0.0")] public static void Main() { DataForge.App app = new DataForge.App(); app.InitializeComponent(); app.Run(); }

But its auto generated by visual studio? in App.g.i.cs?

On Wed, Apr 15, 2015 at 6:29 AM, Ashley Canning ashley.canning@gmail.com wrote:

Hmm its not added as a reference to the project but I do use some of its methods by loading the DLL at runtime. That shouldn't affect costura should it?

I'll try the main method thing when I get In to work :). On 15 Apr 2015 06:17, "Cameron MacFarland" notifications@github.com wrote:

Just put the main method in a separate class.

class Program { static void Main(string[] args) { Loader.Run(args); } }

class Loader { static void Run(string[] args) { // Your actual main code. } }

Also for unmanaged code Costura doesn't always work, and you may be better off not using Costura for them. The problem is unmanaged code handles it's own dependencies and so it may have custom code to look for dependencies in files in different paths, or with different names.

— Reply to this email directly or view it on GitHub https://github.com/Fody/Costura/issues/107#issuecomment-93192749.

[m3taphysics]

So, removing this line:

<Target Name="CleanReferenceCopyLocalPaths" AfterTargets="AfterBuild;NonWinFodyTarget"> <CosturaCleanup Config="FodyWeavers.xml" Files="@(ReferenceCopyLocalPaths->'$(OutDir)%(DestinationSubDirectory)%(Filename)%(Extension)')" />

Fixes the problem. Presumably this is only happening in debug and the app is trying to load DLL's from this directory? So cleaning outputs breaks things. I can live without the clean output directory for now... :).

I have no idea what its trying to load though its a shame there isn't more information from the asserts.

On Wed, Apr 15, 2015 at 7:30 AM, Ashley Canning ashley.canning@gmail.com wrote:

Thats the main executable. Thats where I have installed Costura.

On Wed, Apr 15, 2015 at 7:30 AM, Cameron MacFarland < notifications@github.com> wrote:

That's the standard WPF main, which should be ok unless you're referencing anything else in App.

What is DataForge.exe? Is it being embedded by Costura?

— Reply to this email directly or view it on GitHub https://github.com/Fody/Costura/issues/107#issuecomment-93218159.

[Licshee]

It's possible that OP used both Costura & Caseless, where Caseless will break Costura's loader code for unknown reason. So the real problem is that Costura.AssemblyLoader.LoadStream(string) is broken, and can only be discovered when the referenced assemblies are removed from the output dir(or when the executable are deployed), at this point LoadStream(string) will be called and raise the BadImageFormatException, which later be caught by the .NET loader thing, and throw a FileLoadException which we finally saw. A workaround for this is moving <Costura ... /> after <Caseless ... /> in FodyWeavers.xml I have an example can reproduce similar problem: https://github.com/Licshee/FodyCcCExample

already reported as Fody/Caseless#5, but i'm still not sure whether this is a bug in Cecil or in Caseless or just the code injected by Costura

[Licshee]

@distantcam @SimonCropp can you take a look on this?

or if you are too busy working on other projects, gimme clues about how the code injection thing works then maybe i can find out how to address this

[distantcam]

@Licshee Why are you asking about a different issue on this one?

[Licshee]

the issues shares same characteristics, as the OP is not following up for months and you are not possible to reproduce the same problem, i here to provide info the OP possibly missed to mention

i have read the details from this and #106 (i suspect that's same problem and maybe or maybe not from a different project) carefully, here is the key points why i think this and that are same or related to the problem i've faced:

1. in both this case and mine, cleaning the output dir (or deploying without the referenced assemblies) results assembly fail to load, which should not happen since we are using Costura for not bringing those assemblies together with our output
2. in #106 and my issue, moving <Costura .../> to the bottom does temporarily solve the problem (uninstall & re-install Costura indeed "moves" <Costura .../> to bottom

i've spent days investigating my problem, and dug into the output IL (used ildasm, ilspy crashes when opening Costura.AssemblyLoader.LoadStream(string), and it even crashes on the Costura namespace when in IL mode), from what i learned during my investigation, i can mostly confirm it can indeed produce similar or same problem as these issues (#106 #107)

so i post what i've found here b/c i thought they are the same problem, and i believe it's not a good idea open another issue

although OP didn't state anything about Caseless, but since no-one else we know can reproduce this, i believe investigating on how Caseless & Costura work together is a good direction to solve the real problem -- Costura.AssemblyLoader.LoadStream(string) is broken by some Fody plugin(s), Caseless or something else.

[distantcam]

@Licshee So you're also getting errors from DataForge.exe? C++ errors? If so could you provide a repo for those errors?

[Licshee]

TL; DR: if you try the example i provided and use ildasm to see what's wrong, i believe you'll immediately get what i was trying to tell.

EEFileLoadException is the C++/CLI equivalent to System.IO.FileLoadException, and an EEFileLoadException should only happens when the C++/CLI code fails to load an IL assembly, thus it has nothing to do with C++, as we know Costura can do nothing to a native DLL, it's just System.IO.FileLoadException.

sometimes EEFileLoadException can be seen when loading mixed DLL from IL code, but in every & any case i've seen that's b/c the DLL being loaded is, in-fact, trying to access an IL assembly and something went wrong.

if the mixed DLL is missing, you should get System.IO.FileLoadException, if there is something wrong with the DLL, you should also get something other than EEFileLoadException

i don't write C++, i don't have the code, but i have experience working with C++/CLI code, and the example i've shown above can produce exactly the same exception(in the .NET equivalent form), with one additional condition OP didn't mention (possible didn't realize that's the cause)

if you still want an example throws EEFileLoadException, i can show you one some hours later, but i believe the C# example should be enough for now

[distantcam]

@Licshee Costura is a project about loading libraries at startup. You have incorrectly assumed that because this issue is about errors loading libraries at startup and you're project is having issues loading libraries at startup they are the same issue.

You said your issue was being caused by Caseless. I can see how that would happen. But without more information I wouldn't presume that the same fix would work for this issue too. That's why I don't like that you've combined your issue with this one. If you had opened a separate issue, and as part of fixing that this issue was also resolved, great. But now if fixing your issue does not resolve the original issue, do I close this?

[Licshee]

in short: i saw "needs repro" label, then i didn't want to open another issue blindly and leave this issue open forever

i can't assume my issue is caused by Caseless, in fact, i don't know who or what i should blame. so i'm not sure if i should count it as a Caseless issue, or a Constura issue. that's why i came here to see if any ppl reported same problem, and then i saw this and #106

i understand the reason you hope me to open a new issue, but just from what i know about this problem, i believe they are exactly the same problem, and OP is not following anymore, that's why i wanted to combine.

since you are already stating it directly, i will stop trying to combine my case into this issue, from now on just let someone (maybe me again) get you a C++/CLI example later to investigate

just another question: do you think i should open another issue in this Costura repo? since there is already Fody/Caseless#5

[SimonCropp]

if this issue still occurs in v2 please upload a small solution that reproduces the problem