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

Nlog.Loki.dll is not copied to bin directory when used as a sub project #114

Open
KevCenturion opened this issue Feb 13, 2024 · 2 comments

Comments

@KevCenturion
Copy link

Hi, Thanks for creating this. We have created a shared logging library in .NET Framework 4.8 which references Nlog.Loki.dll 2.1.1

We have setup a parent solution and sub projects.

Solution

  • Project A -> Logging Library (Reference to Loki)
  • Project B-> ASP.NET Project (Reference to Project A)

Everything works fine if we have a reference to Loki in Project B and the Nlog.Loki.dll is copied to the bin directory of project B.

If the Loki reference is removed from Project B, then the Nlog.Loki.dll is not copied to the bin directory. It is marked as CopyLocal in the ProjectA project. NLog 5 works as expected and is copied to Project B bin directory although there is not reference to it in Project B.

It appears to be something to do with the Loki dll being .netstandard 2.0, I've tried various stackoverflow suggestions like

https://stackoverflow.com/questions/70082582/net-standard-dependency-not-copied-to-output-directory

However the loki dll will not be copied unless it's added as a reference (Verbose build output) show's nothing helpful.

Anyone encountered this?

@corentinaltepe
Copy link
Owner

Hi,
I'm not very familiar with .NET Framework NuGet dependencies configurations, and how transitive dependencies are configured. Would explicitly defining a dependency to NLog.Targets.Loki solve the issue? But then, users of your library would need to include both your library and NLog.Targets.Loki.

Would publishing the NuGet package explicitly targetting .NET Framework 4.8 solve the issue? We could try that out. Would you like to give it a try to see if it solves your issue? If so, I can update the build and publish scripts accordingly.

corentinaltepe added a commit that referenced this issue Mar 9, 2024
This is only an idea of adding support for .NET Framework 4.8, following issue #114. This proof of concept is not ready to be merged.

* The added dependencies must be conditioned to only .NET Framework 4.8.
* The Json serliazing logic must be conditioned to .NET Framework 4.8 to avoid performance degradation for .NET 6+ users.
* Documentation and build, test, publish pipelines must be updated accordingly
@KevCenturion
Copy link
Author

KevCenturion commented Mar 10, 2024 via email

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

No branches or pull requests

2 participants