Shall we add fuse.dll to repo

[texone]

Shall we add fuse.dll to repo so that people can directly work with the repo without compiling? Should we use lfs to add it? Please add opinions.

[joreg]

considerations:

• it would mean that anyone who ever makes a commit changing the c# code would have to remember doing this
• you'd have to decide whether to push a debug or release (and for consistency: again remeber to always do the same). you'd probably want to do a release, if you're targeting this to benefit "users". but locally you'd typically work with a debug, which adds an extra step for the committer of switching solution configuration and doing another build before being able to commit
• it is a rather unusual thing to do. binaries are typically supposed to be in a repo

instead:

• release preview nugets more regularly. it should be less work for the committer to trigger a release than committing a release .dll (if it is not yet less work, then improve that workflow)
• working with the repo should be meant for developers, not for users. if opening VS and running a build is too much for a developer i wonder if you could have a buildscript in the repo that one could just run locally without having to start VS

[LarsEck]

Hey all,
@sebescudie and I talked about this issue. I'd personally argue in favor of adding the fuse.dll to the repository, but in an automated fashion using GitHub actions. More precisely, a GitHub actions workflow could be triggered on push, that builds the solution server-side in case it detects changes in the src folder and checks the resulting binaries into the repository.

it would mean that anyone who ever makes a commit changing the c# code would have to remember doing this

This approach would free the developers from having to remember checking in the .dll manually after the C# part has been altered.

you'd have to decide whether to push a debug or release (and for consistency: again remeber to always do the same). you'd probably want to do a release, if you're targeting this to benefit "users". but locally you'd typically work with a debug, which adds an extra step for the committer of switching solution configuration and doing another build before being able to commit

To tackle this, we could build either debug or release depending on the branch we're working on. As an example, a push to the develop branch would trigger a debug build, while a push to main would trigger a release build. As we've adjusted the branching strategy to "version"-branches, this would need some more thought on how to adjust the branching strategy to make this distinction possible in our scenario.

it is a rather unusual thing to do. binaries are typically supposed to be in a repo

From my current perspective, the benefits of adding the binaries could outweigh the drawbacks, as this has repeatedly been a point of failure in the past while developing. A developer that needs to work with the latest state of the Fuse repository would no longer have to manually check if files in the src folder have been changed or even build the solution as a precaution after every pull. You'll always have a fully working Fuse when checking out a commit, right off the bat. Also the size of the binaries seem negligible, imho, when using Git LFS for everything binary.

It's been discussed in another place that there could be the possibility of using the post-checkout git-hook to build the solution client-side after checkout, which also sounds very reasonable. The benefit of letting GitHub actions take care of this would be that the approach is system agnostic, as we wouldn't have to care about having the right build tools in place on client machines.

[LarsEck]

Having had a look at the discussed git-hooks approach; it does not seem possible to share hooks automatically within the repository itself and would make it necessary for every developer to set up that build hook (semi-)manually, as the .git/hooks folder is local only. You could of course provide a script that automates adding a hook to the local hooks folder (by creating a hook file or using symlinks to add files from a potential hooks folder included in the repository), but every developer would need to execute that script manually once.

Not being able to automatically share the hooks with the repository does make sense from a security perspective, as sharing a hooks folder would make it possible to silently execute code on the developers machine just with a checkout of the repository, as the hook files are just shell scripts.

[azeno]

Keep in mind that for each commit you'll get a second commit from the github action. Not sure that's desirable.

I'd also argue for the simple build.cmd in the repo root. The necessary build tools (dotnet sdk) should be installed on the machine anyways because of vvvv, which installs them by default. The script only needs to contain dotnet build.

A future option would be to reference the Fuse.csproj from within vvvv - that way vvvv would take care of compiling it. However there's still an open issue on our end to fully support this for libraries / VL packages. Currently it would prevent the library from getting pre-compiled and would therefor cause a longer startup.