JJ.Framework.Compilation.Core 4.7.7023-preview

JJ.Framework.Compilation.Core

[ Pre-Release ]

A simple wrapper for the dotnet.exe CLI.

To kick off compilations of .NET projects at runtime, this tool can be helpful for testing build-related behaviors of your code keeping it close the the logical flow of behavior of dotnet related actions.

The problem this package solves, is managing the call around Process.Start, kicking off dotnet.exe, which comes with subtle issues.

Error Handling

One of the issues, is that the output of the dotnet.exe process indicates error or success in subtle ways that aren't trivial to interpret. If handled incorrectly it would swallow the error that you were actually trying to test or your logic will dwell into undefined behavior.

This package will throw an exception if such error occurs, so your logic can act appropriately. A future version would allow a nothrow option, which places the responsibility on you, the caller, to inspect the Result output, which offers a structured view on what happened, including error codes, output text and parameters used.

Parameterization

Another issue is parameterization of dotnet.exe. This package gives a strongly-typed view on those parameters, so there is less confusion about the basics that can be used with dotnet.exe, because they are hard-coded into the interface.

Default parameterizations ensure protection against traps that come with heavily conccurent situations, which also comes with trap doors in the dotnet CLI. These defaults are on by default (that's what default means), but you can turn these things on and off individually in a code-first matter.

Extensibility

The Compilation.Core package offers explicit methods and parameters for commonly used dotnet.exe commands. The interface also supports a flexible (structured but string-based) way to call any other command.

Alternatives

As mentioned, calling Process.Start("dotnet.exe" ...) yourself is an alternative but comes with caveats that this library explictly solves.

There are CLI wrappers out there not specifically tailored to dotnet.exe, which may simplify some of the logic, but don't address the specific issues for the .NET CLI, which means you'll still be manually solving them, face undefined results, and not focusing as much on your behavioral (testing) logic.

[ TODO: Add link to CLI wrapper package. ]

There are also big MSBuild-wrapper libraries that though powerful, do not offer the simplicity that this package does.

[ TODO: Add link to one. ]

This is simply a lightweight in-between option that's both simple and full-proof for basic compilation and other actions you could run using dotnet.exe in a strongly-typed way at runtime.

Features

• One Utility class:
  • Single entry point DotNet class so you can simply call DotNet.Build().
• Explicit Commands
  • Restore() | Build() | Rebuild() | MSBuild() | MSRebuild() | InstallPackage(id, ver) | UninstallPackage(id) | (Clean and Test in the future.)
• Custom commands and parameters:
  • Commands and arguments not explicitly supported can still be used e.g.:
  • DotNet.Exe("pack")
• Result object with error info, output and parameters used:
  • Build => new DotNetResult { Suffessful, Args, Opts, OutputText, ... }
• Logging & Diagnostics
  • Throws when expected. Does not swallor errors.
  • (nothrow option in the future.)
  • .ToString() with well-readable overview of the current state of options, args and result objects .
  • Well formatted debugger displays.
  • Logging actions for flexibly logging output.
  • Logging verbosity adjusts to .NET's own verbosity setting (use DotNetOptions.Verbosity)
  • Support for log file output and bin logs.
  • Methods for checking emptiness, filled-in-ness or defaultness of opts, args or result.
• Options object:
  • For set-and-forget parameterization you can pass along any command.
  • Example:
  • var opt = new DotNetOptions { BuildConf = "Release", Dir = "C:/MyRepo" };
  • Build(opt);
  • Or:
  • Build(new { Dir = "C:/MyRepo", BuildConf = "Release" })
  • Or:
  • Build(opt with { BuildConf = "Release" }
• Parallelism:
  • Well-behaved under parallel load.
  • Default options for well-behaved parallel execution
  • Can be turned off/tuned to your needs.

Pre-Release

I'm releasing this prematurely. I almost never do this. I was going for fully tested, and fully worked out, but things have been slowing me down.

AI-generated tests had been weighing down on me, because I had to redo them without the courage to throw any existing tests away.

Then dotnet.exe experienced hanging behavior for the 2nd time during this project and after that I had basically had it wit it.

This tool is good. But the polish is currently missing. I don't want to withhold it from anyone that could use it.

But I'm pretty much done with it right now. It doesn't seem to be anyone's priority to keep dotnet.exe working reliably, performant, under concurrent load, even thouhg it has been capable of it at some points in time, only to regress again. And this whole project is based on that premise, so I'm leaving it at this. Sorry for the rant. I don't usually do that in a package README. I'm off to focus on other things now.

Planned Features

These features were planned for the final release, before this project was pushed into perpetual pre-release state:

• nothrow option
• Input sanitization / validation
• Extra commands: Clean, Test.
• Diagnostics texts fine-tuning
  • Some newer options are not always currently displayed, such as bin log and log file paths.
  • Logging and diagnostics may not be fully covered by unit tests.
  • Diagnostics texts usually look good, but there may be edge cases in which they do not.

Release Notes

2026-06-22 | 4.7 : Preview Release

• Brand new dotnet.exe CLI wrapper. Run compilations and other dotnet actions programmatically at runtime.
• Preview release. Works in general. More coverage derised. More features desired.

💬 Feedback

Questions or found an issues? Let me know.