Closed ericwj closed 6 years ago
@ericwj Yes, that sounds promising; thank you for offering to help.
Considering #19, I was planning to do the following once .NET Core 2.1 is released:
McMaster.Extensions.CommandLineUtils
; it's overkill for parsing a few arguments.I believe having this available as a global tool would solve your use case of running it with only the runtime available, and indirectly also point (2), after running dotnet tool install --global dotnet-xdt
.
How does that sound? Would it fit your use case, or is the availability of a netstandard library that you can reference in your app more important?
It'll still need the SDK.
Just running publish on the project and releasing it to the GitHub releases page (so it can be downloaded) will solve 2.
However I figure it is way easier to have it as a DLL so this can be inbox in the deployed app - it could even load and run the source and transform from a resource instead of from the file system and do fancy stuff such as expecting an environment name and the secret my app needs to boostrap Azure Key Vault.
With PR #25, a CLI global tool and a .NET Standard library are published (but currently unlisted) on NuGet.
You can install the tool with:
dotnet tool install --global dotnet-xdt --version 2.1.0-preview.2
# and then
dotnet xdt --help
Alternatively, reference and use the library in a custom app or command-line tool:
dotnet add package DotNet.Xdt --version 2.1.0-preview.2
Version 2.1.0-rc.1 is now available on NuGet for both dotnet-xdt
CLI tool and DotNet.Xdt
library.
The standalone dotnet-xdt.exe
for .NET 4.6.1 is downloadable from AppVeyor and dotnet-transform-xdt
2.0 remains available as a project-level tool for all .NET Core versions.
Unfortunately this can only run with the SDK installed. I want to run this standalone on a server with just the runtime available.
Would you accept a PR to
This would allow a scenario where a deployed app using this can simply accept a switch to do a transform, no additional tools needed to carry around.
Also add some TargetFrameworks and pack the stuff for .NET Core 2.0 and 2.1 in the same package.