@U2M7EC8KU Congrats. Windows only?

No it works on .NET core too. Basically targeting .NET Framework (Window) and .NET Core (cross platform). Problem for it on .NET Core is that MS took away saving binaries to hard disk via Reflection.Emit()... a problem that is rumored to be fixed with .NET Core 8.

ah cool, I was confused by cljr.exe, so there is a cljr binary for macOS too?

yeah on Mac you'd run it with dotnet cljr.dll <params>

it builds both cljr.exe and cljr.dll on windows and you use the exe version there.

ah cool, so you could make a bash wrapper that does that for you basically

yup

i have been focused on Windows/.NET framework as I'm also integrating with Office (think: legacy app modernization). But one of the main use cases is microservices so you'd want those to run on Core to deploy cross platform.

.NET is relative hot mess because of the runtime fragmentation over the years (.NET, silverlight, core, standard, winRT, etc). They are trying to tie it all back together again into Core, but because of the Reflection.Emit() restriction the perf on Core is slightly less on startup as the runtime has to compile the entire core clojure library on the fly. Once it's running it's fast; but the startup can take a few seconds. It's much quicker on .NET framework with precompiled libraries.

i need to add detail about deps.edn for CLR purposes. Will add that to the readme over the weekend.

@U2M7EC8KU Have you considered that some libraries may target both JVM and CLR, and how does a deps.edn for such a library look like if it has JVM + CLR dependencies?

there are toplevel CLR-specific keys: :clr-deps and :clr-aliases. These are ignored by JVM tooling. cljr ignores :deps and :aliases.

cool!

There, it's mostly documented already. LOL.

{:paths ["src/main/" :another-project-dir]

 :clr-deps
 {Some.Local.Library {:local/root :some-local-dir}
  }

 :clr-aliases
 {:some-local-dir "C:\\libs\\"
  :another-project-dir "C:\\projects\\another-project\\"}

 :nuget/repos []

 }

Keeping in mind there could also be :deps and :aliases keys in the same file, that's the current functionality. adding git and nuget are the next two big priorities besides expanding aliases for tool execution.

Some.Local.Library => this needs to be a qualified symbol

It will be Some.Local.Library.dll on the hard drive, located at :some-local-dir.

Qualified names will relate more to nuget dependencies and git repos

I'd say that should be:

{:clj-deps {org/lib {:local/root "Some.Local.Library.dll"}}}

OK, that's good feedback. Can make it a feature or enhancement request on the Issues tab.

well wait

:local/root requires a path on the local drive, which in this case is provided by an alias

.NET formal names can be used in the first part of the k/v pair, but when referring to a specific folder, the short name of the assembly is enough.

another thing worth point out is that assemblies and jar files aren't quite the same thing. If the DLL is compiled by ClojureCLR, each namespace gits its own DLL, so the "correct" thing to do here will be somewhat dictated by a) .NET exigencies and assembly loading logic, and b) the design decisions that went into ClojureCLR up to this point. Java conventions will only be "somewhat" useful.

But yes - everything is on the table for discussion at this point.

Once the functionality is such that we're past the chicken-egg connundrum of needing cljr to build cljr, the implementation will move to Clojure - porting the tools related projects that currently are JVM specific.

But dependency management will require different logic on .NET than it does on the JVM, so I'm waiting to see how far NuGet integration handles that for us.