wildcards work differently than ILMerge wildcards

[kellypleahy]

In ILMerge, we use a command line argument set like:

/wildcards /allowDup /closed /targetplatform:"v4,$($env:ProgramFiles)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0" /lib:$($source.dir)\CapitalModelInputBuilderConsole\bin\Release /out:$($build.dir)\CapitalModelInputBuilder.exe CapitalModelInputBuilderConsole.exe *.dll

where the .exe and *.dll are relative to the "lib" folder supplied via the /lib argument.

In ILRepack, this command line doesn't find the exe or DLLs instead looking in the current working directory only. I'm not sure if ILMerge looks in CWD+lib folders or only in lib folders or what, but it seems to be a difference in behavior.

My assumption given the nature of the consistency between the arguments in ILMerge and ILRepack is that you intend for the behavior to be identical, hence my filing of this issue.

[gluck]

Although compatibility with ILMerge is indeed what I sought (thanks for noticing the discrepancy), I think this behaviour is pretty unclear/risky (you and I can't really tell how it works w/o testing all cases).

Relative path arguments are commonly resolved from CWD, you can root them (both the glob and the exe) if you want absolute one, there's no real need for more magic.

Fixing it could cause regressions to ILRepack users, and the issue should be fairly obvious (you tell me) when migrating, don't think I'm going to fix it.

[kellypleahy]

It makes it impossible for us to use your code given the way our build system works. Is it possible you could add this behavior as a special argument? If that's the case we could just pass that arg. Fully qualifying all paths doesn't work given the way our build system works. In that case we'd need to fork or just keep using ilmerge.

I understand it is your project so I'm definitely not going to presume to tell you what to do ;).

I actually think the ilmerge behavior makes more sense personally as who would want to resolve dependencies from cwd and not where the assemblies are that you are using, but that is your call, of course. On Jul 7, 2016 15:23, "Francois Valdy" [email protected] wrote:

Although compatibility with ILMerge is indeed what I sought (thanks for noticing the discrepancy), I think this behaviour is pretty unclear/risky (you and I can't really tell how it works w/o testing all cases).

Relative path arguments are commonly resolved from CWD, you can root them (both the glob and the exe) if you want absolute one, there's no real need for more magic.

Fixing it could cause regressions to ILRepack users, and the issue should be fairly obvious (you tell me) when migrating, don't think I'm going to fix it.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gluck/il-repack/issues/159#issuecomment-231062448, or mute the thread https://github.com/notifications/unsubscribe/AADP2DmpIUEgaltQXuS-Ny8fOjyYt0u4ks5qTO_agaJpZM4I5WOf .

[gluck]

Code's open :smile: Feel free to fork, add this extra arg and report here. If the diff is simple enough I may consider merging it, but I'm really not sure.

Out of curiosity, what kind of build system (if public) doesn't allow injecting absolute paths in commands it calls ?