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.

Sign up for GitHub

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

Jump to bottom

DOTNET_CLI_TELEMETRY_OPTOUT through csproj #38646

Closed
JensNordenbro opened this issue Feb 9, 2024 · 15 comments
Closed

DOTNET_CLI_TELEMETRY_OPTOUT through csproj #38646

JensNordenbro opened this issue Feb 9, 2024 · 15 comments
Assignees
@Forgind
Labels
Area-CLI config-system-candidate Issues that could be solved cleanly if the .NET CLI had a git-like configuration system Cost:M 4 to 10 person weeks of work per central guidance Priority:3 Work that is nice to have untriaged Request triage from a team member

Comments

@JensNordenbro
Copy link

JensNordenbro commented Feb 9, 2024 •
edited
Loading

It should be possible to disable telemetry inside a csproj.

Many developers are moving their projects through containers, VMs, cloud machines, local machines, stationaries and laptops and it is just too easy to forget setting up the environment.
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-CLI untriaged Request triage from a team member labels Feb 9, 2024
@nagilson nagilson added new-hire-issue Priority:3 Work that is nice to have Cost:M 4 to 10 person weeks of work per central guidance labels May 2, 2024
@baronfel
Copy link
Member

baronfel commented May 3, 2024

This is not feasible IMO - not all telemetry-triggering operations even interact with a project file. And in the cases where we are interacting with a project file the SDK would have to evaluate the project entirely separately from MSBuild, which would cause many perf implications.

We have talked off and on about a .NET CLI config system a-la git config, this is where opt-in should be defined IMO to be cross-cutting. With such a system users could run a single command like git config set telemetry.enabled false or something.

@baronfel baronfel added the config-system-candidate Issues that could be solved cleanly if the .NET CLI had a git-like configuration system label May 3, 2024
@Forgind
Copy link
Member

Forgind commented Jun 18, 2024

Per baronfel's comment, this isn't really possible. Since there was no action for the month since then, I'm closing this. Let us know if you want the git config option to opt out of telemetry 🙂

@Forgind Forgind closed this as not planned Won't fix, can't repro, duplicate, stale Jun 18, 2024
@JensNordenbro
Copy link
Author

JensNordenbro commented Jun 19, 2024 •
edited
Loading

@Forgind, Not sure dotnet config is what I am looking for since I do not want to change the system, just my session hence the request for csproj that is always the common ground. We already have the system option through the env variable.
The reason for session is that our app uses dotnet cli and we do not want to affect the clients whole system, neither should they need to care about the usage of dotnet cli...

@Forgind
Copy link
Member

Forgind commented Jun 19, 2024 •
edited
Loading

Part of baronfel's point is that we don't read the csproj early enough to properly suppress telemetry, and if we send back a bunch of telemetry then find out we shouldn't have done that, it's too late.

I'm a bit unclear on to what extent you want this to persist. Environment variables are system-wide, but they don't persist across sessions, so the next user won't know that you'd set the environment variable. csproj changes do persist across users as long as they use the same csproj. I don't believe dotnet config exists yet, so to some extent, how it works still needs design. I'm only speaking for myself here, not the team, but one option I could feasibly imagine would be to write arbitrary values into a global.json and read them as soon as the CLI starts up, so:
dotnet config --environment DOTNET_CLI_TELEMETRY_OPTOUT=1
would make a little section in the global.json for environment variables and set that very early on, disabling our telemetry. In other words, it would be the equivalent of setting that environment variable beforehand, except it is in a file that can be moved and committed, and it would probably unset itself afterwards.
dotnet config --property DebugSymbols=false
would make a different section in the global.json for MSBuild properties. If you then do dotnet build, it would effectively be like doing dotnet build -p:DebugSymbols=false.

I imagine that when you move your csproj file, you'd move everything else with it, including this modified global.json file, so it would obviate the need to separately set the environment before building, but it would also fit better with how the CLI currently does things.

What do you think?

@JensNordenbro
Copy link
Author

JensNordenbro commented Jun 20, 2024 •
edited
Loading

Global.json might work.
So I am invoking dotnet from Process.Start. Maybe I can inject the environment variable there? Meaning each operation will ovrrride what is on the user? @Forgind

@Forgind
Copy link
Member

Forgind commented Jun 20, 2024

@JensNordenbro, that might actually make things easier. If you're using Process.Start, I assume you have a ProcessStartInfo ahead of time? That should have an EnvironmentVariables property that you can use to modify its environment before you launch it. That would probably be the easiest solution for your case.

@JensNordenbro
Copy link
Author

@Forgind, I will try that.
What is the easiest say to detect telemetry is activated?

@Forgind
Copy link
Member

Forgind commented Jun 24, 2024

I roughly know how to access telemetry from our end, but I have no idea from your end. @baronfel, is there a way?

@baronfel
Copy link
Member

The CLI/SDK doesn't provide any external user-discoverable way to tell what the configuration is - the only externally-visible knob here is the DOTNET_CLI_TELEMETRY_OPTOUT environment variable's value (true/1/yes/false/0/no), but that may not always be set. If it is not set by a user, then if the SDK is an MS-authored SDK then telemetry is sent. If the SDK is an OSS-authored SDK then telemetry is not sent.

@JensNordenbro
Copy link
Author

JensNordenbro commented Jun 27, 2024 via email

@JensNordenbro
Copy link
Author

JensNordenbro commented Jun 27, 2024 via email

@baronfel
Copy link
Member

What of it is an sdk from the zip bundle?

Same behavior, depending on if the zip is an MS authored SDK zip or a Source-Build authored zip. Anything you download off of the MS .NET download page is going to have telemetry enabled by default.

@JensNordenbro
Copy link
Author

JensNordenbro commented Jul 7, 2024 •
edited
Loading

How about detecting telemetry requests @baronfel ?

@baronfel
Copy link
Member

I'm not quite sure what you mean, can you elaborate?

@JensNordenbro
Copy link
Author

Using what protocol and port is the telemetry sent on? Knowing this I can ensure my app has disable telemetry on all dotnet cli invocations

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Forgind Forgind

Labels
Area-CLI config-system-candidate Issues that could be solved cleanly if the .NET CLI had a git-like configuration system Cost:M 4 to 10 person weeks of work per central guidance Priority:3 Work that is nice to have untriaged Request triage from a team member
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@baronfel @JensNordenbro @Forgind @nagilson