Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow defining the assemblies where the problems are located #181

Merged
merged 2 commits into from
Nov 29, 2023

Conversation

codemonkey85
Copy link
Contributor

This is my attempt to solve #180.

@codemonkey85
Copy link
Contributor Author

Just realized the obvious problem of the input files not being where they need to be in an outside assembly.

@eduherminio
Copy link
Owner

Just realized the obvious problem of the input files not being where they need to be in an outside assembly.

Yeah, I'm afraid it's not as simple.
But I really like your proposal, this is definitely the right path (no pun intended).

I'll think about this in the following days and see if I can come up with a nice solution to the input files problem.

@eduherminio eduherminio self-requested a review November 27, 2023 23:13
@eduherminio
Copy link
Owner

Just to be clear about what the problem to solve is:

  • It's not about the location of the input files relative to the executable.
    AoCHelper always relied on the problems being copied to the output folder, and with this change the one in charge to do so would be the library where the problem classes are contained.
    Providing this is configured correctly, running the binaries just work and VS execution just works as well
  • However, input files aren't expected to be located next to the project file of the entry assembly, and that's why dotnet run CLI executions fail to find the input files even if they're correctly copied to the bin\... dir

@eduherminio
Copy link
Owner

eduherminio commented Nov 28, 2023

@codemonkey85 Could you verify that if you replicate this pattern, everything works smoothly?

Scenarios to test:

  • IDE run (VS, Code, Rider, whatever you're using, if any)
  • dotnet run
  • dotnet build + .dll/binary invocation
  • dotnet publish + binary invocation

Pattern to replicate: (using v3.1.0-alpha.1 from NuGet)

@codemonkey85
Copy link
Contributor Author

@eduherminio The public abstract class BaseLibraryDay is not available from the NuGet, so I created it to match what you linked to. Using that as the base class, the scenarios all passed.

@eduherminio
Copy link
Owner

I didn't intend to ship it, because its presence might be just confusing, and just include the needed override as part of the documentation.

What's your opinion on that?

@codemonkey85
Copy link
Contributor Author

Yeah, I think that's fine. I suppose mine is more of a niche requirement anyway

@eduherminio eduherminio changed the title Allow searching additional assemblies for problems Allow defining the assemblies where the problems are located Nov 29, 2023
@eduherminio eduherminio merged commit f91dd1b into eduherminio:main Nov 29, 2023
@eduherminio
Copy link
Owner

Thanks again for raising the issue and for your contribution @codemonkey85, I'll add some documentation and examples and release 3.1.0 in the next 24h.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants