Open natemcmaster opened 7 years ago
That sounds great. I looked at the details: do you think it should be extended in all 3 ways that the document describes?
I would recommend 2 for sure.
1 is more effort but likely worth it.
3 has less value at the moment as ILMerge is already a console tool. Adding PATH means users can just run ilmerge.exe
instead of dotnet.exe ilmerge
.
By the way, I'd be happy to make a PR if you would take it.
Sure! Even better...
Ok. I'll make a PR for item 2. Item 1 might take more effort so I'l do that separately.
There is enough compatible API that I don't think this tool will run on .NET Core 1.x without major rewrites. I took a wack at compiling ILMerge for .NET Core 2.0 (not released yet). However, it's almost compatible with .NET Core 2.0. There is only one incompatible API. Marshal.GetTypedObjectForIUnknown.
Nodes.cs(752,71): error CS0117: 'Marshal' does not contain a definition for 'GetTypedObjectForIUnknown' [C:\dev\ILMerge\System.Compiler\System.Compiler.csproj]
Reader.cs(2258,73): error CS0117: 'Marshal' does not contain a definition for 'GetTypedObjectForIUnknown' [C:\dev\ILMerge\System.Compiler\System.Compiler.cspro
j]
Reader.cs(2280,70): error CS0117: 'Marshal' does not contain a definition for 'GetTypedObjectForIUnknown' [C:\dev\ILMerge\System.Compiler\System.Compiler.cspro
j]
See https://github.com/natemcmaster/ILMerge/commit/aa1daf963c2bd8466b7b413c9dd395e9c02b7234
@natemcmaster What about Marshal.GetObjectForIUnknown(IntPtr pUnk) as replacement?
@Fabi I'm not actually sure what either of those APIs do. I'd have to take a closer look at what this code is doing.
Also, some of these more-obscure interop APIs may be present, but will throw PlatformNotSupported
on non-Windows platforms. See https://github.com/dotnet/corefx/blob/0e718a78b591dfbd46ccd7ac9411d15c4cdb46eb/src/System.Runtime.InteropServices/tests/System/Runtime/InteropServices/MarshalTests.cs#L315-L325
Any progress on this again?
@mike-barnett and I started looking at this but it fell off my radar. At this point, I would actually recommend making it a .NET Core 2.1 global tool instead of a project tool named dotnet-ilmerge. The tool's usage doesn't need to hang off "dotnet" anymore. It could just be:
$ dotnet tool install -g ilmerge
$ ilmerge One.dll Two.dll
Thoughts? @mike-barnett
That actually makes more sense.
Fine by me! Let me know if there's anything you need from me.
Would be awesome to make ilmerge available as a command line tool along with the .NET Core CLI.
Details on extending the CLI: https://docs.microsoft.com/en-us/dotnet/articles/core/tools/extensibility