Open ajj7060 opened 9 years ago
This is from the NuGet symbol server? I know we have some issues with some of the assemblies where the symbol server rejects the symbol package - that might be one of them.
Debugging/troubleshooting the symbol server uploads is quite difficult unfortunately :(
With luck this will be fixed in the 4.6 release as part of the overall resolution of some broader (new) issues with uploading symbols: https://github.com/MarimerLLC/csla/issues/373
We're pulling Csla from Nuget, which works fine, but the pdb from symbolsource.org doesn't work. Is that the NuGet one?
Yes, the 'push all' script in the NuGet folder pushes packages to NuGet and also pushes the symbol packages to symbolsource.
Right now in 4.6 about half the symbolsource pushes are failing (something to do with my switch to shared projects for everything). In 4.5 most of them worked, but I believe the MVC5 and Android ones were consistently failing and we don't know why.
Since you seem to have a bug issue for this already, I'll close this discussion. Thanks!
Well, the 'bug' is to move to a different symbol source, which I might not do.
SymbolServer seems to have updated their service, I would guess in response to GitHub providing competition? :smiling_imp:
Have you read this: http://www.symbolsource.org/Public/Home/VisualStudio
And then this: http://tripleemcoder.com/2015/10/04/moving-to-the-new-symbolsource-engine/
In particular the bit that they changed their endpoint to: https://nuget.smbsrc.net
Fwiw, since symbolsource updated their service I am no longer getting the timeouts when pushing the CSLA code.
The issue/bug in question is https://github.com/MarimerLLC/csla/issues/460
@ajj3085: I am curious to hear if any of the symbolsource suggestions help you. If not I might still switch to the new scheme.
@rockfordlhotka I've read through the links, and ensured my settings matched. I did add https://nuget.smbsrc.net to my list as well, but it seems that Csla.Web.Mvc5 still isn't loading for me. And while Csla-Core's PDB was loading on .600, it looks like for me at least the 4.5.700 isn't loading. I think it was at one point, but now its not. After a long delay I eventually get an Open dialog asking me to locate the PDB on my local machine. This is the Symbol Load Information:
C:\Sandbox\HttpProxyPoc\HttpProxyPoc.WinForms-NET40\bin\Debug\Csla.pdb: Cannot find or open the PDB file.
d:\Users\Rockford\Documents\GitHub\csla-marimer\Source\Csla.Net4\obj\Release\Csla.pdb: Cannot find or open the PDB file.
C:\WINDOWS\Csla.pdb: Cannot find or open the PDB file.
C:\WINDOWS\symbols\dll\Csla.pdb: Cannot find or open the PDB file.
C:\WINDOWS\dll\Csla.pdb: Cannot find or open the PDB file.
C:\Users\Andy\AppData\Local\Temp\SymbolCache\Csla.pdb\466aa6241b5b4c5ea1aee77e583f59d42\Csla.pdb: Cannot find or open the PDB file.
C:\Users\Andy\AppData\Local\Temp\SymbolCache\MicrosoftPublicSymbols\Csla.pdb\466aa6241b5b4c5ea1aee77e583f59d42\Csla.pdb: Cannot find or open the PDB file.
C:\Sandbox\HttpProxyPoc\Csla.pdb: Cannot find or open the PDB file.
SYMSRV: Csla.pdb from http://srv.symbolsource.org/pdb/Public: 0 bytes
SYMSRV: Can't create Csla.pdb\466AA6241B5B4C5EA1AEE77E583F59D42\Csla.pdb
Access is denied.
http://srv.symbolsource.org/pdb/Public: Symbols not found on symbol server.
SYMSRV: C:\Users\Andy\AppData\Local\Temp\SymbolCache\Csla.pdb\466AA6241B5B4C5EA1AEE77E583F59D42\Csla.pdb not found
SYMSRV: http://srv.symbolsource.org/pdb/MyGet/Csla.pdb/466AA6241B5B4C5EA1AEE77E583F59D42/Csla.pdb not found
http://srv.symbolsource.org/pdb/MyGet: Symbols not found on symbol server.
SYMSRV: C:\Users\Andy\AppData\Local\Temp\SymbolCache\Csla.pdb\466AA6241B5B4C5EA1AEE77E583F59D42\Csla.pdb not found
SYMSRV: https://nuget.smbsrc.net/Csla.pdb/466AA6241B5B4C5EA1AEE77E583F59D42/Csla.pdb not found
https://nuget.smbsrc.net: Symbols not found on symbol server.
However, Csla.Web and Csla.Windows PDBs do load, so I'm at a loss.
Trying to step through the HttpPortalController controller from Csla.Web.Mvc5 (.Net 4.5.1), the loading of symbols fails with a Not Found. Other symbols load fine.