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

Change FileName to be relative to project root #1739

Merged
merged 18 commits into from
Jul 14, 2022
Merged

Conversation

SimonCropp
Copy link
Contributor

hopefully helps with #327

@SimonCropp
Copy link
Contributor Author

@bruno-garcia this embeds the project and solution dir into the assembly that consumes Sentry.

so where would i wire this in to help with #327

Copy link
Member

@bruno-garcia bruno-garcia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! yeah, I think we need to figure out where that goes into the payload next.
@untitaker do you know about this? (see: #327)

@untitaker
Copy link
Member

What is the question?

@bruno-garcia
Copy link
Member

bruno-garcia commented Jun 22, 2022

What is the question?

We have abs_path

abs_path
The absolute path to the source file.

We currently have the rooted path there D:\bla\something\else\app\file.cs.
This PR allows us to know where app.

Do we add the 'project root path' somewhere to the payload? Or do we just truncate the D:\bla\something\else out of the abs_path and just send the relevant 'project path'? More details on: #327 (comment)

Should we have abs_path as is (FQP) and an additional, 'relative to root' path in another field? We want to allow codeowners, suspect commits, stack trace linking, etc.

@bruno-garcia
Copy link
Member

I think I found the answer:

filename
The path to the source file relative to the project root directory.

https://develop.sentry.dev/sdk/event-payloads/stacktrace/#frame-attributes

I believe today we only have the file in there. Without path.

@untitaker
Copy link
Member

You're correct, you want to put the relative path into filename. That's what the python sdk does at least

sorry for the slow response, i definetly replied via email but for some reason it didn't show up here

@SimonCropp SimonCropp changed the title add AttributeReader Send project root path with events Jun 30, 2022
@SimonCropp SimonCropp changed the title Send project root path with events Change FileName to be relative to project root Jun 30, 2022
src/Sentry/AttributeReader.cs Outdated Show resolved Hide resolved
{
public static bool TryGetProjectDirectory(Assembly assembly, out string? projectDirectory)
{
projectDirectory = assembly.GetCustomAttributes<AssemblyMetadataAttribute>()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this safe, and/or does this work with AOT? Like IL2CPP and net6.0-ios for example?
Just curious if it'll at least return null or it'll throw

<WriteCodeFragment AssemblyAttributes="@(SentryAttributes)"
Language="$(Language)"
OutputFile="$(SentryAttributesFilePath)">
<Output TaskParameter="OutputFile" ItemName="Compile" Condition="$(Language) != 'F#'" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Condition="$(Language) != 'F#'" does this mean we want this for VB or a possible IronRuby or something if that's a thing?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for some reason the item name for F# is CompileBefore but for VB and c# it is Compile.

for other languages (like IronRuby) i have not tested. do you want me to include any other languages? Currently they will be a no-op


public class AttributeReaderTests
{
[Fact]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, this should run on iOS AOT'ed so we would see how it behaves there. Assuming the tests are running there following #1703

mattjohnsonpint and others added 2 commits July 12, 2022 18:00
Co-authored-by: Bruno Garcia <bruno@brunogarcia.com>
@mattjohnsonpint
Copy link
Contributor

Thats odd. It seems to be coming up blank on Mono in CI:

Error: Assert.Equal() Failure
          ↓ (pos 0)
Expected: Internals/SentryStackTraceFactoryTests.cs
Actual:   
          ↑ (pos 0)

But it works on my local machine, even on Mono. hmmm

@SimonCropp
Copy link
Contributor Author

@mattjohnsonpint r u running in release mode locally?

@mattjohnsonpint
Copy link
Contributor

Testing further, it doesn't matter if debug vs release mode. It passes on all targets when run from Rider's test runner. It fails on NET461 (Mono) when run from dotnet test on the command line.

I've seen before where I get filenames and line numbers in Rider, but that was when a debugger was attached. This is in the test runner. Whatever they are doing special, they're doing it for tests as well.

@mattjohnsonpint
Copy link
Contributor

FYI - even if I build and test (passing) in Rider, and then test without building so it's using the exact same code (dotnet test test/Sentry.Tests --filter FileNameShouldBeRelative -f net461 --no-build), it still fails. So I don't believe it's a compiler flag, but something being done at runtime.

@mattjohnsonpint
Copy link
Contributor

I figured it out.

  • Mono needs a --debug command line argument passed at runtime to emit filenames in stack traces.
  • Mono has a feature where the MONO_ENV_OPTIONS environment variable can be used to set any arguments that would normally be passed on the command line.
  • Rider is likely setting (at least) MONO_ENV_OPTIONS="--debug"
  • I can get the test to pass on the command line like this:
    MONO_ENV_OPTIONS="--debug" dotnet test test/Sentry.Tests --filter FileNameShouldBeRelative -f net461

The question is, do we want to rely on this in our tests? It won't happen at runtime for a user application.

@SimonCropp
Copy link
Contributor Author

my vote is we exclude that test for mono

@untitaker
Copy link
Member

untitaker commented Oct 11, 2022 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

Successfully merging this pull request may close these issues.

4 participants