PowerShell module manifest

[jhoek]

Link to issue(s) this covers

Problem

Previously, ICSharpCode.Decompiler.PowerShell did not contain a module manifest (as stated in the README for the project).

Solution

Added a module manifest, plus the logic to copy it to the build target folder.

Please note that even with the new manifest, the module would still not be auto-discovered by PowerShell. For that to work, the compiled module (and all its dependencies) need to live in a folder on your $env:PSModulePath with the exact same name as the module itself; if the module is published to, and subsequently installed from, the PowerShell gallery, this requirement is automatically taken care of by PowerShellGet.

Also, I wasn't quite sure which version no. to use in the manifest. The decompiler itself appears to be version 8.0.0.0, so that's what I used. Please feel free to adapt as you see fit.

P.S.: Forgive me my ignorance, I couldn't get your pre-commit hook to run on Mac OS; it seems very Windows-oriented?

Thank you for considering my pull request!

[christophwille]

Yes, our dev workflows are definitely Windows-oriented, simply because the core team works exclusively on Windows.

[christophwille]

Thanks! I will adapt the README to denote that the manifest is no longer missing.

[jhoek]

Thank you, @christophwille!

Now that we have a proper module manifest in place, how do you feel about publishing the module to powershellgallery.com, making it a lot easier to e.g. make decomplication part of a (GitHub/Devops) workflow/pipeline?

[christophwille]

Bit of historic background first - ilspycmd and the ps cmdlets started their respective lifes as proof of concepts to verify that we built the decompiler library properly x-platform. ilspycmd turned into dotnet tool that is actively maintained, no one has really touched the ps cmdlets since they were initially built (I will admit that the cmdlet design process was "looks ok" and nothing any more fancy than that).

Having said that - especially the design part - has me a bit hestiant of turning it into a properly supported tool (I view publishing to a registry as that). Simply putting something out there that hasn't been touched in years and no one really has any intent on improving on or supporting / bug fixing has me worried.

[jhoek]

I see. I guess what you are saying is that, should I wish to run ILSpy in e.g. a GitHub workflow, I'd be better off using the corresponding dotnet tool than the PowerShell interface, anyway? Fair enough. Thanks for your explanation!

P.S.: For the future - if there's any ILSpy expert that would like to cooperate on getting the cmdlets to that same quality level, I'd gladly contribute what I know about PowerShell.

[christophwille]

ilspycmd has a lot more options, but compared to PS no object model. So yes, there is a use case for the PS cmdlets.