The source files available through debugger files (pdb) via VS2008 SP1 atuomatic download, or manually downloaded from this website are not compatible with
.NET Framework 3.5SP1 with some updates (2.0.50727.4016).
It looks like the available PDB files are for 2.0.50727.3053 but they are not compatible with 2.0.50727.4016!
How many years will take for the 2.0.50727.4016 PDB files to be published?
M$ guys, anyone?
I'm having the same problem with 2.0.50727.4016. I tried uninstalling the .Net Framework 3.5 and reinstalling it, but it's still the same version. Everything works fine with my other machine with mscorlib at 3074. Is the 4016 build part of Vista SP2 ? The only reference to build 4016 that I could find on MSDN is a hotfix for some foreign language -- but perhaps the hotfix is included with Vista SP2. (I just installed Vista SP2 on this PC, but my other machine still has Vista SP1 on it.)
Does anyone know of a way to uninstall 4016 and forcibly install 3053 / 3074?
It's definetly Vista SP2 that's breaking it. I installed it on my other computer last night, and now it's using the 4016 build and VS won't step into the source.Nope. I have same problem on XP SP3
Here is also the same case, Anybody can answer it? It's very long now.
50727.4016 is the Vista SP2 version as noted in a few other threads. If you are having trouble source stepping into a DLL of that same version, try clearing your cache.
One thing I've found helpful in debugging what is going on is using Fiddler to verify that an attempt is being made to pull down the correct pdb and source.
If we do have a widespread problem with pulling down 50727.4016, then I'll follow-up with our operations folks. However, I just did a test and was able to pull that version down.
Standard expectation setting we've been doing in various threads:
Reference source is currently only released for RTM and SP releases of .NET. Hotfixes and security sources are not published. While security patches are generally widespread in their deployment, the source has sensitivity for publication until all machines are patched or on the later major service pack release. A work around for that scenario of course is to use a VM with an RTM or SP release on it, or use Reflector. Reflector has less sensitivity due to reduced raw fidelity and missing comments.
- Proposed as answer by ChrisDnet Tuesday, December 14, 2010 10:17 PM
I've been able to successfully debug .NET 4.0 Framework code ... only by installing the .NET 4.0 source code install at (http://referencesource.microsoft.com/netframework.aspx) ... that is by specifically avoiding the integrated VS 2010 functionality where it downloads .pdbs and source code from the Microsoft Symbol Servers.
If you use the integrated VS 2010 functionality ... it does seem to download the .pdb (for the stack frames in the Call Stack window turn black from gray) ... but if you double click on a stack frame ... it says that there is no source available for that location (and I've tried every location on the stack). So, it doesn't seem like it is downloading the source code ...
Now, as to .NET 3.5 SP1 ... I have not been able to get this to work ... in any fashion whatsoever. Neither with the integrated download functionality ... nor with installing source code and .pdbs from http://referencesource.microsoft.com/netframework.aspx.
When using the integrated functionality in VS 2008 ... the behavior is the same as VS 2010 above. When trying to use the VistaSP2 source code at (http://referencesource.microsoft.com/netframework.aspx, I am unable even to load the .pdb files.
I do not think it is working as you think it is. At least, I am having issues.
I should mention that I am not trying to debug System.Web.dll ... rather I am trying to debug PresentationFramework.dll.
My PresentationFramework.dll version is 3.0.6920.5001 ... and is located at C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0.
Hi, an update from here:
Windows 7, x86 with system.web.dll version 2.0.50727.4955 (win7RTMGDR.050727-4900) Visual Studio 2008 is also not loading the correct source and debug symbols from Symbol Servers. I tried downloading the sources manually, but visual studio 2008 still downloads new files, so they manually downloaded files are not used ....
An update is needed...
For .NET 3.5 sp1, it is likely that there is no source available because you are working with MSRC security patched version of the framework (i.e. post-RTM).
The system.web.dll version above for instance corresponds with this MSRC release.
The MSRC source code for this isn't published due to the risks for an unpatched machine. We do have plans for another reference source refresh with the next OS service pack.
.NET 3.5 sp1 binaries which have not been security patched since release should still be source step-able. That includes Vista SP2 and Win7 releases which have had their RTM versions published. We do have plans for another reference source refresh with the next OS service pack.
As for .NET 4, nothing has changed there recently for the RTM released sources (other than a few security updates); so, that likely means there was a local cache issue or temporary connectivity issue.
If you have a need to do source stepping, please do have an environment setup with one of the major RTM or SP releases for your baseline.
- Proposed as answer by ChrisDnet Monday, January 24, 2011 9:12 PM
"Reference source is currently only released for RTM and SP releases of .NET. Hotfixes and security sources are not published. While security patches are generally widespread in their deployment, the source has sensitivity for publication until all machines are patched or on the later major service pack release. A work around for that scenario of course is to use a VM with an RTM or SP release on it, or use Reflector. Reflector has less sensitivity due to reduced raw fidelity and missing comments."
I've spent days Googling and trying to solve why Step Into doesn't work from me (3.5 SP1 + all Windows Updates) and finally found this thread. In my case it does bring down PDBs, but are they the wrong PDBs?? Can you please add a fix to Visual Studio to show some warning to the user when it detects an unsupported .NET framework for source debugging, rather than just quietly not working? Or at least post the above quoted statement (or a link) on the VS2010 home page so developers know about this.