Console output not being displayed

Dec 19, 2012 at 11:50 AM
Edited Dec 19, 2012 at 11:50 AM

I've used ILMerge-GUI and it did its job, by joining my DLL (from EPPlus - http://epplus.codeplex.com/) to my piece of code. But I found very frustrating that the console window is no longer displayed. So, all my messages are not shown to the final user.

Am I doing something wrong?

Thanks in advance!

Developer
Dec 19, 2012 at 11:58 AM

Hi,

I'm not sure what you mean by a console window. I rewrote the old VB version in C# and now run ILMerge as a assembly so do not use any commandline execution anymore, hence no console window.

Did you check the logfile option?

I could add a popup/listview with the logfile messages in it if you like.

regards
Wim van der Vegt

Dec 19, 2012 at 12:02 PM

Actually, I could reproduce the problem with the "vanilla" ILMerge, when I set the "/target" to "winexe". My application should be merged with a "/target:exe" switch, as this is a console. I'll look at the source code now to see if this can be done in the current version of ILMergeGui.

Dec 19, 2012 at 12:13 PM

Hi wvd_vegt. I've added a bit more information to this case. I believe it's related to fix: 8737. It's an issue caused by having the TargetKind hardcoded on the code...

Developer
Dec 19, 2012 at 12:15 PM

Hi,

It has been a while since i worked on IlMerge-gui takes the file marked as primary to determine the target type (so if it's an exe file it merges dll's into an exe, otherwise it combines assembly dll's into a new one).

I have some improvements still to publish like the /internalize switch and merging XmlDocumentation too.

regards
Wim van der Vegt

Dec 19, 2012 at 12:20 PM

I see that, but I don't think you can determine if the target is a "winexe" or a "exe" (please correct me if I'm wrong). In this case, maybe it would be good to have a combobox on the interface and let the user to choose which target is more apropriate.

For my needs, unfortunately I will have to stick with commandline ILMerge, as I really need the messages for the final user :(

Regards

Developer
Dec 19, 2012 at 12:21 PM

Hi,

According to the sometimes conflicting documentation (and figures vary a bit), the value of 3 makes sure that the assemblies are merged into the one marked as primary, maintaining it type. So you cannot merge all dll's into an executable.

I must have tested it and it worked on my machine (or i would not have published it). In the releases before 8737 the target kind was rigged to 2 which was always an executable, no matter the primary assembly.

regards
Wim van der Vegt

Dec 19, 2012 at 12:26 PM

Ok, you got me. I'm downloading the project right now. If I am able to compile it (and it doesn't takes me a lot of time), I'll test and see if I can suggest anything, =)

Dec 19, 2012 at 12:33 PM

Hey! It worked from the source code!!!

Have you updated the "clickonce" version after you changed the TargetKind from "2" to "3"????

Developer
Dec 19, 2012 at 12:34 PM

Hi,

Normally a dll does not have the entry point to be an exe file. So it should be possible to use the automatic mode. Can you post/mail me a saved settings file for me to see what you exactly want?

But I will see if i can squeeze in a combobox somewhere in the user-interface.

About the console output, is the content of the logfile not enough? Can you post/mail a sample what you need?

regards
Wim van der Vegt

 

Developer
Dec 19, 2012 at 12:35 PM

Hi,

Could be that the rebuild failed. I have to check my own version.

regards
Wim van der Vegt

Dec 19, 2012 at 12:37 PM

Ok. Please take your time to review that afterwards.

I will keep the source code around here now, and use it from there. So, I'm all good now! :)

Thanks for your efforts!

Developer
Dec 19, 2012 at 1:41 PM

Hi

I've updated the click-once installer (indeed forgot to build it, and uploaded the old one, so sorry and thanks for reporting it).

The new version has two extra options, merge xml documenation and internalize. The latter changes 'public' method in assembly dll's that are being merged into a main executable into 'internal' methods.

This is a important step for preventing dissassembly and successfull Obfuscation.

If you have any suggestions for improvement, please post them.

regards
Wim van der Vegt