fscheck / FsCheck

Random Testing for .NET
https://fscheck.github.io/FsCheck/
BSD 3-Clause "New" or "Revised" License
1.15k stars 154 forks source link

Fix SourceLink warning #671

Closed Smaug123 closed 4 months ago

Smaug123 commented 4 months ago

I don't think I can change the base repository for the merge while still having AppVeyor run; this is built on top of https://github.com/fscheck/FsCheck/pull/670 .

Let's have AppVeyor produce the nupkg, and then we can try and work out if NuGet Package Explorer still complains about non-embedded sources. This change is extremely speculative and I can't test its correctness; if you have access to a local Nuget Package Explorer of some kind, it would be good to load up the nupkg in it and see.

kurtschelfthout commented 4 months ago

No dice I'm afraid, same untracked sources warning. I did not expect this to be so annoying, but on the other hand I'm not surprised.

I think worth trying the EmbedUntrackedSources, otherwise not worth spending more time. The basic thing - viewing accurate sources - works. No one's going to want to "Go To Definition" into the assembly attributes.

Smaug123 commented 4 months ago

I wouldn't do that on a repo I owned (I'd like to know exactly what files from my computer I'm broadcasting to the world!), but I'm happy to do it here. I've pushed that to this branch.

Smaug123 commented 4 months ago

The base for comparison would now be https://github.com/fscheck/FsCheck/pull/672 except GitHub won't let me do that across forks.

kurtschelfthout commented 4 months ago

Same warning, shrug. Fine to ignore as far as I'm concerned.

Smaug123 commented 4 months ago

I'll try and build the checking tool locally at some point and work out what it's actually doing. Sadly necessary all too frequently :(

Smaug123 commented 4 months ago

Nope, dotnet validate is 100% cursed, the solution doesn't even come close to building.

Smaug123 commented 4 months ago

I now understand what the NuGet package explorer is doing. I've written a much slimmer tool that does the same checks re SourceLink and embedded obj files (https://github.com/Smaug123/nuget-metadata).

Smaug123 commented 4 months ago

I don't know why the embed command isn't working. My project now is to debug it. I can't build SourceLink so it's quite slow going, but the EmbeddedFiles property is unexpectedly empty after the embed untracked files target has run. The inputs to the task look correct to me.

Smaug123 commented 4 months ago

I think I have a smoking gun: during the dotnet pack command line, the CoreGenerateAssemblyInfo target is never built, according to dotnet pack -v:d. (It's overridden to the F# version, but never run.) That means when the F# compiler comes to emit the embedded file, it doesn't have access to the source so it decides not to embed.

Smaug123 commented 4 months ago

I think there are at least three compiler bugs here. Raised the first one as https://github.com/dotnet/fsharp/issues/16768

Smaug123 commented 4 months ago

Second bug (or rather bad interaction) and its fix raised at https://github.com/dotnet/sourcelink/pull/1209

Smaug123 commented 4 months ago

I believe once those two bugs are fixed, this should all Just Work without this extra EmbedUntrackedSources. (One of my three bugs was me failing to use ls correctly, and .NETStandard.blah.blah.dll beginning with a . is hidden from ls's output.)