Closed Smaug123 closed 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.
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.
The base for comparison would now be https://github.com/fscheck/FsCheck/pull/672 except GitHub won't let me do that across forks.
Same warning, shrug. Fine to ignore as far as I'm concerned.
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 :(
Nope, dotnet validate
is 100% cursed, the solution doesn't even come close to building.
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).
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.
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.
I think there are at least three compiler bugs here. Raised the first one as https://github.com/dotnet/fsharp/issues/16768
Second bug (or rather bad interaction) and its fix raised at https://github.com/dotnet/sourcelink/pull/1209
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.)
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.