In reply to@corngood:corngood.com
Is there a project file you can use instead of the sln? Publishing an sln often causes problems. Also can you share what happens when you run `fetch-deps`? Feel free to @ me on the PR if you'd rather discuss there.

Ah, I see. fetch-deps works because it's only restoring the SDK-style projects: Enemizer.CLI.Core.csproj and EnemizerLibrary.csproj.

Do you actually need the whole solution, or can you get away with just building one or both of those projects?

Alternatively you might be able to build it as-is using mono/xbuild. The only thing I see in nixpkgs using xbuild is keepass.

In reply to @corngood:corngood.com

Ah, I see. fetch-deps works because it's only restoring the SDK-style projects: Enemizer.CLI.Core.csproj and EnemizerLibrary.csproj.

Do you actually need the whole solution, or can you get away with just building one or both of those projects?

Alternatively you might be able to build it as-is using mono/xbuild. The only thing I see in nixpkgs using xbuild is keepass.

In reply to@corngood:corngood.com
I think you'd only need one derivation, just set projectFile to Enemizer/EnemizerCLI.Core/EnemizerCLI.Core.csproj, since it depends on the other csproj.

In reply to @pyrox:pyrox.dev
oh okay it's failing with a different error(its trying to hardcode dotnet compiler paths in the source code?)

I think what's happening here is it's using an old version of Microsoft.Net.Compilers which doesn't seem to work on platforms where a .net executable can't be executed directly.

If I remove <PackageReference Include="Microsoft.Net.Compilers" Version="2.3.2" /> from both projects, and also remove this:

    <Content Include="enemizerBasePatch.json">
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </Content>
    <Content Include="exported_symbols.txt">
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </Content>

it builds.

In reply to @corngood:corngood.com
Here's the PR for the latest round of dotnet upgrades (with 9.0 final), including some infrastructure changes: https://github.com/NixOS/nixpkgs/pull/355753

There are some breaking changes, so if anyone maintains dotnet derivations outside of nixpkgs, I'm interested in test cases or feedback.

In reply to @emma:rory.gay
i wonder if we'll see a dotnet-sdk_9 alias as with prior versions?

I'm open to this. I originally had a big plan to rearrange the package names, but this seems like it might still be the most intuitive way. 9.0 final seems like a logical time to do it.

I'd also like to default things to the source-built sdks whenever possible, but they aren't building reliably on Darwin at the moment.