Closed Smaug123 closed 2 years ago
@Smaug123 Thanks for the PR 🚀
I suppose there is no easy way to add tests for this?
Thanks
Well, quite :P I couldn't find one, but I'm not at all familiar with the FAKE codebase.
@Smaug123 The integration tests for SdkAssemblyResolver
are in FAKE/src/test/Fake.Core.IntegrationTests/Fake.DotNet.sdkAssemblyResolver.fs
Please let me know if you need more information
Thanks
I don't suppose you'd be interested if I refactored so that this could be unit tested instead?
I'm shaving yaks here; FAKE doesn't work on my Nix+Apple Silicon setup, which means I can't dotnet fake build
, so it's extremely frictionful to write tests of any kind. This PR is intended to fix one of the reasons why my setup doesn't work, but the unrelated https://github.com/fsprojects/FAKE/issues/2626 is showstopping and I'm not willing to switch to x64 emulation or a non-Nix installation, so my development workflow here and in Fantomas tends to boil down to "stop using FAKE/Paket, add package references to all .fsproj
files in the transitive footprint of the file I'm working on, and build using dotnet
instead".
boy scout rule: "leave the code behind in a better state than you found it" (fix warnings, obsolete members or code-style in the places you worked in)
This point is one of the hints/requirements for sending a PR to FAKE. So, yes absolutely, if you can find room for improvement please go ahead. Every help/improvement counts.
We are currently working on the next major version of FAKE, v6. We are concerned mainly in two points:
dotnet fsi
out of the box feature(s) to resolve dependencies instead of using Paket and trying to resolve reference assemblies for a Dotnet SDK installation in the FAKE runner.You are welcome to help in that regard also. We are using release/v6
branch for this work.
Thanks
@yazeedobaid I'm not at all happy with this test - the whole thing seems to be hanging together by a thread - but there's a chance you'd consider this good enough to go in?
@Smaug123 Yes thanks a lot and sorry for the late response
Description
Resolve the path to
dotnet
fully (traversing symlinks) when trying to find the .NET reference assemblies.This is necessary when, for example, you've installed
dotnet
using Nix. On my machine, for example:Only this final
dotnet
has apacks
directory above it.[ ] New (API-)documentation for new features exist (Note: API-docs are enough, additional docs are in
help/markdown
)[ ] unit or integration test exists (or short reasoning why it doesn't make sense)
[ ] boy scout rule: "leave the code behind in a better state than you found it" (fix warnings, obsolete members or code-style in the places you worked in)
[ ] (if new module) the module has been linked from the "Modules" menu, edit
help/templates/template.cshtml
, linking to the API-reference is fine.[ ] (if new module) the module is in the correct namespace
[ ] (if new module) the module is added to Fake.sln (
dotnet sln Fake.sln add src/app/Fake.*/Fake.*.fsproj
)[ ] Fake 5 API guideline is honored