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

Distribute as a NuGet package #1541

Closed
pellared opened this issue Nov 3, 2022 · 7 comments · Fixed by #2286
Closed

Distribute as a NuGet package #1541

pellared opened this issue Nov 3, 2022 · 7 comments · Fixed by #2286
Assignees
Milestone

Comments

@pellared
Copy link
Member

pellared commented Nov 3, 2022

We got information that there are developers who would prefer to deploy using a NuGet package similarly to https://github.com/DataDog/dd-trace-dotnet/blob/master/docs/Datadog.Trace.Bundle/README.md

@pellared pellared added this to the 0.6.0-beta milestone Nov 9, 2022
@pellared
Copy link
Member Author

pellared commented Nov 9, 2022

This issue is about "packaging the distribution" for the end user to use it instead of the "zip" files.

@pjanotti
Copy link
Contributor

pjanotti commented Nov 9, 2022

The package that we currently produce doesn't have the content elements as required to use it as a deployment method.

@pellared pellared modified the milestones: 0.6.0-beta, 0.7.1, 0.7.0 Nov 16, 2022
@pjanotti
Copy link
Contributor

pjanotti commented Dec 6, 2022

@rajkumar-rangaraj the current package adds the native files, but, they are not marked as content files. The end result is that adding a PackageReference doesn't automatically adds the native bits to the application.

There are a few ways that we can do this. If using the nuspec file NuGet provides an example. Upstream uses a csproj.

The current package has the all the instrumentation and SDK dependencies so a direct approach of simply packing the bin/tracer-home ends up with some redundant content. Anyway, this can be considered an optimization.

@pellared
Copy link
Member Author

pellared commented Dec 7, 2022

Based on the SIG meeting I think we need two NuGet packages:

  • first for "distributing" the binaries (native, store, additional deps...). I think it should be via content files as it is more usable (it could be named OpenTelemetry.AutoInstrumentation.Binaries)
  • second for "dependencies" so that it can be used for plugin development as well as for solving package version conflicts (it could be named OpenTelemetry.AutoInstrumentation.Dependencies)

@pjanotti
Copy link
Contributor

Having NuGet packages also affects redirection on the .NET Fx. It doesn't remove the need for something like #1646, but, it greats reduces the possibility of runtime conflicts.

@pjanotti
Copy link
Contributor

Obs.:

first for "distributing" the binaries (native, store, additional deps...)

If the application can add packages at build time there is no reason for the additional deps or store.

@Kielek
Copy link
Contributor

Kielek commented Jan 23, 2023

Based on conversation with @rajkumar-rangaraj and @pjanotti we have two scenarios to cover.

  1. @rajkumar-rangaraj requirement
    Possibility to sync all our dependencies to be able to build plugins executed by extenstion points without manually syncing package dependencies.
  2. @pjanotti requirement:
    Distribute all files as nuget package. When you add it to the project output should be extended by tracer-home and after adding few env. vars published folder should be instrumented.

Guys, could you please check if I do not missed anything?

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

Successfully merging a pull request may close this issue.

3 participants