Add symbol files(.pdb/source) to NuGet packages #3
Comments
|
I agree it would be nice if we hooked into the source and symbol information into our packages. @agocke do we have an issue tracking this yet? |
|
Is this not the issue? ☺ From: Jared Parsons [mailto:[email protected]] I agree it would be nice if we hooked into the source and symbol information into our packages. @agockehttps://github.com/agocke do we have an issue tracking this yet? — |
|
@agocke i didn't know if we had an existing internal one tracking it :) |
|
Nope, I asked David to file it here |
|
@jasonmalinowski mentioned that it would be nice to have those PDBs stamped for source server info from github as well. |
|
We should make sure that both corefx and Roslyn use the same mechanism here. |
|
It would be also nice if you could make git tag for NuGet releases. |
|
Yep, we haven't migrated our historical branches from CodePlex yet. I think @jaredpar is working on that. |
this performance improvement is particularly for devdiv bug # 1089540 this makes the file in the bug to be formatted in several seconds compared to several minutes on my machine. there were several issues. each one fixed by #1, use concurrency on gathering operations. #2, don't use too much time to split work to chunks if that requires more work than actually formatting. #3, don't blindly set beginning of a file as inseparable start point for certain formatting options. ... but these don't actually address the most impactful root cause of this perf issues. which is perf issue of GetPrevious/GetNextToken API in compiler. (dotnet#3244) formatter internally uses GetDescendantTokens to get all tokens at once and cache them which takes less than 1 second for the entire file (2M bytes size) in the bug. and use the cache internally. but certain part of formatter (Rule Provider) can't use that internal cache, so it has to use the GetPrevious/GetNextToken to move around tokens, which in this particular bug, takes more than 40 seconds on my machine. and that is not even for entire file. (less than 1/12 of tokens) I opened a bug to compiler team, hopely so that we can get better perf on those APIs. in this PR, I mitigated the issue either by making more things to run concurrently or by changing logic which requires those APIs.
make formatting performance better ... this performance improvement is particularly for devdiv bug # 1089540 this makes the file in the bug to be formatted in several seconds compared to several minutes on my machine. there were several issues. each one fixed by #1, use concurrency on gathering operations. #2, don't use too much time to split work to chunks if that requires more work than actually formatting. #3, don't blindly set beginning of a file as inseparable start point for certain formatting options. ... but these don't actually address the most impactful root cause of this perf issues. which is perf issue of GetPrevious/GetNextToken API in compiler. (#3244) formatter internally uses GetDescendantTokens to get all tokens at once and cache them which takes less than 1 second for the entire file (2M bytes size) in the bug. and use the cache internally. but certain part of formatter (Rule Provider) can't use that internal cache, so it has to use the GetPrevious/GetNextToken to move around tokens, which in this particular bug, takes more than 40 seconds on my machine. and that is not even for entire file. (less than 1/12 of tokens) I opened a bug to compiler team, hopely so that we can get better perf on those APIs. in this PR, I mitigated the issue either by making more things to run concurrently or by changing logic which requires those APIs.
|
Is there any update on this? I am seeing a crash and would like to step into Microsoft.CodeAnalysis.Workspaces to see what is causing it. |
|
@johnkoerner this is something we are still looking into actively. It fell off the radar while we were pushing for 2015 RTM but started picking it up again last week. |
|
Are we still planning to do this for 1.1? |
|
yes we should do this for 1.1. |
|
Actually, after internal discussion I don't think we should do this at all. We upload our symbols to the Microsoft symbol servers, so the symbols should be available via the public servers. |
|
The symbols we publish point exactly to what source that external users have access to? |
|
Usually symbols have a command to pull it from source control, say SD, TFS, or even GIT from VSO. But I've yet to see a symbol that MS has published that has pulled from Github, which would be needed for non-Microsoft employees. |
|
We'd basically need to use something like: https://github.com/GitTools/GitLink |
|
@agocke do our pdbs have source server information? Maybe we should use GitLinks |
add expression body as one of fix to offer
…iltering Allow a IDynamicFileInfoProvider to be able to provide LSP diagnostics
Fix crash bug when entering name before type and clicking OK
Forward integration from dotnet/roslyn
Update protocol to v3 for MauiLaunchCustomizer brokered service
It would be nice to be able to step inside Roslyn code when using NuGet packages.
This is nice guide on how to do this:
http://blog.davidebbo.com/2011/04/easy-way-to-publish-nuget-packages-with.html
The text was updated successfully, but these errors were encountered: