Fsharp: ship FSharp.Core.pdb files

[ctaggart]

Please include FSharp.Core.pdb files in the FSharp.Bundle.exe distributions.

[KevinRansom]

This is a great question:

Publishing debug symbols with the project is probably not a great idea, since most people won't be debugging the project, however, I believe they should be published to the Microsoft public symbol server. At least for the VS2013, VS 2012. I think we may have forgotten to do that for the two Out of band releases. If they are not then we should figure out how to do so.

Details: https://msdn.microsoft.com/en-us/library/b8ttk8zy(v=vs.90).aspx

Thanks

Kevin

[ctaggart]

They should be included with all the builds. Symbol servers are not a good idea, especially the Microsoft public symbol servers that tend to strip information from the pdb files. If the pdb files get source indexed, then users will be able to debug into FSharp.Core and see the exact source. If Power Tools adds support https://github.com/fsprojects/VisualFSharpPowerTools/issues/201 then it will be possible to F12 into the source at design time.

Take an additional step in making F# more open source. Provide users the ability to see the source on demand. Including the pdb files with the builds is an easy first step.

[enricosada]

:+1: for @ctaggart source index, is great

[KevinRansom]

I don't think the symbol servers strip the information. I think we just build and post stripped symbols for some products. Shipping symbols.with product just bloats the size of the deployment and they are rarely used by anyone. Symbol and source servers are the right solution for that.

[ctaggart]

GitHub can be the _source_ server. Source indexed .pdb files would get more eyes on the F# source code and make it much easier to contribute back. Every build can include its own symbols. The symbols never get lost. Including the .pdb files will make the distribution bigger. You have options:

1. include the .pdb in FSharp_Bundle.exe
2. create a separate distribution for includes the .pdb files, something FSharp_Bundle_with_Symbols.exe
3. create a separate distribution for just the .pdb files, something like FSharp_Bundle_Symbols.zip.

Option 1 is my favorite. Would it make the 27.8 MB download twice as big? It is totally worth it.

[KevinRansom]

We are currently struggling with the need to reduce the size of installers not increase them. The preview builds we post are intended to be the exact installers that we use for Oob and Visual Studio Releases. It is not our plan to increase their size without a corresponding increase in functionality. We do not expect the majority of F# developers to have the need to debug our libraries or tools.

To debug Visual F# with debugging symbols you will need to rebuild the open source codebase and either patch the VS or debug using the enableopensource project in deployment.sln.

[baronfel]

It would be killer to have this feature. The biggest stumbling block I get when introducing C# devs to F# is that they lose the simple f12 to view source workflow that they are used to. They view this as a symbol of immature tooling, and then tune out the rest of the benefits of the language. Showing tooling on par with the other .Net languages is a critical aspect of evangelizing F#.

[ctaggart]

Are there .pdb files available for the RC that I can test?

[latkin]

@ctaggart - no AFAIK symbols aren't available anywhere public. Maybe we can find them on an internal build share and distribute them, will need to check.

[ctaggart]

I'd really love to be able to include source indexed .pdb files with the FSharp.Core published on NuGet. Users would like to try out the RC or another preview build on NuGet https://github.com/fsharp/fsharp/issues/429, so now would be a good time. In order for the pdb files to be source indexed, I just need to know the git commit for the build and it must have been compiled with the .fs line endings set as lf since you have a .gitattributes http://ctaggart.github.io/SourceLink/how-it-works.html#Line-Endings.

[latkin]

@ctaggart I don't think there is a particular reason for us not to redist the PDBs. The Roslyn people are also trying to figure out a practical way to do this, too.

In internal TFS source control that produces official builds, everything has CR/LF. We can't change that now, though for future we could look into it.

[ctaggart]

I released a new version of SourceLink.exe yesterday that allows you to automates switching those files to LF before the build if you can't adjust the Git core.autocrlf setting before the clone. It can be used to change the line endings before the compile and also do the source indexing after the compile. I tried it out on this project and it works great.

SourceLink.exe can be installed/copied however you want and is available on Chocolatey and NuGet galleries. Here I unset the core.autocrlf settings as part of the test. It sadly defaults to behaving like 'true'.

choco install SourceLink --version 0.6.1 -y --force
git config --global --unset core.autocrlf
git config --system --unset core.autocrlf
git clone https://github.com/Microsoft/visualfsharp.git --depth 1

cd .\visualfsharp
SourceLink.exe linefeed -pr .\src\fsharp\FSharp.Core\FSharp.Core.fsproj
.\appveyor-build.cmd
SourceLink.exe index -pr .\src\fsharp\FSharp.Core\FSharp.Core.fsproj -pp Configuration Release -u 'https://raw.githubusercontent.com/Microsoft/visualfsharp/{0}/%var2%'

After it is source indexed, you can have it download and check all of the file checksums against what is in the pdb.

Any/all of the pdb files can be indexed this way. It will allow developers to get the exact code on demand while debugging and sometimes when hitting F12 during design time if they have the Visual F# Power Tools installed.

[dsyme]

closing old discussion

[ctaggart]

@dsyme Why was this closed? Was it decided not to ship FSharp.Core.pdb files or did you find a way to actually ship them?

[dsyme]

Only because it was marked discussion and stale. I'll reopen it as a feature suggestion.

[jdh30]

"We do not expect the majority of F# developers to have the need to debug our libraries or tools."
At least in VS2015, exceptions thrown during the computation of global constants makes the debugger look for FSharp.Core.pdb, i.e. ordinary developer errors can require the debugging of your libraries.

In this case I resorted to manual inspection of all code to find and fix the problem (which was an incorrect build flag on a file that was supposed to be an embedded resource).

[KevinRansom]

@jdh30
We will be embedding portable PDBs in dlls shipped via nuget. The windows pdbs for shipped FSharp dll are deployed to a symbol server.

[enricosada]

@KevinRansom afaik this is now done with FSharp.Core 4.2.x packages, so this can be closed?

[KevinRansom]

Can we leave it around for a while. I want to revisit everything we do about pdbs, including generating portables by default and converting them to windows pdb on windows builds.

[ctaggart]

The pdb files are still missing from the current FSharp.Core 4.2.3.

C:\Users\camer\.nuget\packages\fsharp.core> tree /f
└───4.2.3
    │   fsharp.core.4.2.3.nupkg
    │   fsharp.core.4.2.3.nupkg.sha512
    │   fsharp.core.nuspec
    │
    └───lib
        ├───net45
        │       FSharp.Core.dll
        │       FSharp.Core.optdata
        │       FSharp.Core.sigdata
        │       FSharp.Core.xml
        │
        └───netstandard1.6
                FSharp.Core.dll
                FSharp.Core.optdata
                FSharp.Core.sigdata
                FSharp.Core.xml

If you are using dotnet pack or msbuild /t:pack, you can enable the pdb files to be included with this msbuild property:

<PropertyGroup>
    <AllowedOutputExtensionsInPackageBuildOutputFolder>$(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb</AllowedOutputExtensionsInPackageBuildOutputFolder>
</PropertyGroup>

That is what I did for SourceLink 2.7
https://github.com/ctaggart/SourceLink/blob/master/SourceLink.Create.CommandLine/SourceLink.Create.CommandLine.props

[ctaggart]

Microsoft has decided to ship their source linked pdb files to their symbol server. Please do the same. https://github.com/aspnet/Universe/issues/850

Everyone else outside of Microsoft, it is recommended by Microsoft to put the source linked pdb files in the nuget packages.

[danyx23]

I just ran into this as well, would be great to have pdb files available for fsharp.core!

[7sharp9]

Same, its painful to debug FSharp.Core if you need to without anything like this.

[ctaggart]

Did the FSharp.Core 4.5.0 pdb files get published somewhere internally such as the prodcon symbol server?

[KevinRansom]

The desktop symbol files should have been published to the Microsoft Public Symbol server. We do not yet build and publish nuget, portable pdb packages. We should certainly do so.

Something else to look into … yay!!!!

From: Cameron Taggart [e-mail]
Sent: Wednesday, June 20, 2018 11:09 AM
To: Microsoft/visualfsharp [e-mail]
Cc: Kevin Ransom [e-mail]; Mention [e-mail]
Subject: Re: [Microsoft/visualfsharp] ship FSharp.Core.pdb files (#294)

Did the FSharp.Core 4.5.0https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.nuget.org%2Fpackages%2FFSharp.Core%2F4.5.0&data=02%7C01%7CKevin.Ransom%40microsoft.com%7Cfbf83988727140d4292308d5d6d8f08e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651149594419387&sdata=zk9OpTjk6LZUrdzZRQZekreL%2BBZ%2Bhv1GsAxExwpXR24%3D&reserved=0 pdb files get published somewhere internally such as the prodcon symbol serverhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Faspnet%2FUniverse%2Fissues%2F850&data=02%7C01%7CKevin.Ransom%40microsoft.com%7Cfbf83988727140d4292308d5d6d8f08e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651149594429391&sdata=DOM%2B1I%2BhxGUg0S2auM0IanyktnX3%2Bx2M5GB7EHqzckQ%3D&reserved=0?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fvisualfsharp%2Fissues%2F294%23issuecomment-398844734&data=02%7C01%7CKevin.Ransom%40microsoft.com%7Cfbf83988727140d4292308d5d6d8f08e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651149594429391&sdata=8xd3WvPJz43der9CtnCyVebgfMp2dJupXlH0K8aTjks%3D&reserved=0, or mute the threadhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAE76FvThjg1CXyaoNq9_6SX0AIcQ6Fk0ks5t-o_NgaJpZM4Do91D&data=02%7C01%7CKevin.Ransom%40microsoft.com%7Cfbf83988727140d4292308d5d6d8f08e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651149594441056&sdata=dzYrvTAg%2BjDUzeG8%2Bfxuchd0sviyNUHC4m7PpYWl38g%3D&reserved=0.

[ctaggart]

This is technically done. The pdb files that match the dll's in the 4.5.2 nupkg are on the Microsoft Symbol Servers.

For me, it download the symbol to:
C:UserstaggacAppDataLocalTempSymbolCacheFSharp.Core.pdb0A868D34CF4743D0B21CC9DF656936A71FSharp.Core.pdb

Now you just need to:

1. enable SourceLink so that the source can be loaded #5682
2. switch it over to portable pdb so that it can be used from non-Windows #5683

Progress! I'll open up separate issues.