I get the same result if I start form main using reflector and click until I reach QuickSort Have you any idea why I don't see the correct source code in Reflector
> I get the same result if I start form main using reflector and click until I > reach QuickSort > Have you any idea why I don't see the correct source code in Reflector
No, sorry I don't. At the very least, if you run Reflector on the exact same computer where you produced the stack trace showing the call to SwapIfGreaterWithItems(), it should produce a view of the assembly that is consistent with the stack trace. The only reason it would/should be different is if you are looking at a different assembly in Reflector than you are using in your program.
That _could_ happen if you have multiple versions of the .NET assemblies lying around on your computer. But _that_ shouldn't happen normally. A person would have to intentionally clutter their computer like that, and surely that's something you'd remember having done?
All that said, you can verify the exact file being used in both Reflector and in the debugger. In Reflector, just select the DLL itself, and the information pane will show you the file path.
In the debugger, it might be a little more tricky. You can easily see the source of each DLL loaded in the process by, while debugging, displaying the "Modules" debug window. But normally, a DLL like mscorlib.dll is executed from the GAC and this won't match directly with the path shown in Reflector.
Of course, if it turns out you're loading a version of mscorlib.dll that's not in the GAC, then that's probably your problem right there. :) But, if it's in the GAC, AFAIK the best you can do is look at the entry in the .NET Framework 2.0 Configuration MMC plug-in, but the only semi-unique identifier that goes with an assembly in the GAC is the public key token, and I don't recall whether that changes each version (for sure, it's not unique to the assembly, because lots of other assemblies share the same public key token...but it might be unique for the framework version).
Anyway, that's a long way of saying, no...I don't know why on your computer the stack trace doesn't match what you see in Reflector.
Now I get the same contents as you have in QuickSort. In the References in the solution Expolere I used this location C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ so I use this location in reflector now.
Earlier I used this location in reflector Location: %ProgramFiles%\Microsoft.NET\SDK\CompactFramework\v2.0\Debugger\BCL\
I just wonder how does the program Red Gate's Reflector decide which assembly to use when there exist several assembly for example System.dll and mscorlib.dll and these assembly have differerent contents.
>> I get the same result if I start form main using reflector and click >> until I >> reach QuickSort >> Have you any idea why I don't see the correct source code in Reflector
> No, sorry I don't. At the very least, if you run Reflector on the exact > same computer where you produced the stack trace showing the call to > SwapIfGreaterWithItems(), it should produce a view of the assembly that is > consistent with the stack trace. The only reason it would/should be > different is if you are looking at a different assembly in Reflector than > you are using in your program.
> That _could_ happen if you have multiple versions of the .NET assemblies > lying around on your computer. But _that_ shouldn't happen normally. A > person would have to intentionally clutter their computer like that, and > surely that's something you'd remember having done?
> All that said, you can verify the exact file being used in both Reflector > and in the debugger. In Reflector, just select the DLL itself, and the > information pane will show you the file path.
> In the debugger, it might be a little more tricky. You can easily see the > source of each DLL loaded in the process by, while debugging, displaying > the "Modules" debug window. But normally, a DLL like mscorlib.dll is > executed from the GAC and this won't match directly with the path shown in > Reflector.
> Of course, if it turns out you're loading a version of mscorlib.dll that's > not in the GAC, then that's probably your problem right there. :) But, if > it's in the GAC, AFAIK the best you can do is look at the entry in the > .NET Framework 2.0 Configuration MMC plug-in, but the only semi-unique > identifier that goes with an assembly in the GAC is the public key token, > and I don't recall whether that changes each version (for sure, it's not > unique to the assembly, because lots of other assemblies share the same > public key token...but it might be unique for the framework version).
> Anyway, that's a long way of saying, no...I don't know why on your > computer the stack trace doesn't match what you see in Reflector.
Now I get the same contents as you have in QuickSort. In the References in the solution Expolere I used this location C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ so I use this location in reflector now.
Earlier I used this location in reflector Location: %ProgramFiles%\Microsoft.NET\SDK\CompactFramework\v2.0\Debugger\BCL\
I just wonder how does the program Red Gate's Reflector decide which assembly to use when there exist several assembly for example System.dll and mscorlib.dll and these assembly have differerent contents.
>> I get the same result if I start form main using reflector and click >> until I >> reach QuickSort >> Have you any idea why I don't see the correct source code in Reflector
> No, sorry I don't. At the very least, if you run Reflector on the exact > same computer where you produced the stack trace showing the call to > SwapIfGreaterWithItems(), it should produce a view of the assembly that is > consistent with the stack trace. The only reason it would/should be > different is if you are looking at a different assembly in Reflector than > you are using in your program.
> That _could_ happen if you have multiple versions of the .NET assemblies > lying around on your computer. But _that_ shouldn't happen normally. A > person would have to intentionally clutter their computer like that, and > surely that's something you'd remember having done?
> All that said, you can verify the exact file being used in both Reflector > and in the debugger. In Reflector, just select the DLL itself, and the > information pane will show you the file path.
> In the debugger, it might be a little more tricky. You can easily see the > source of each DLL loaded in the process by, while debugging, displaying > the "Modules" debug window. But normally, a DLL like mscorlib.dll is > executed from the GAC and this won't match directly with the path shown in > Reflector.
> Of course, if it turns out you're loading a version of mscorlib.dll that's > not in the GAC, then that's probably your problem right there. :) But, if > it's in the GAC, AFAIK the best you can do is look at the entry in the > .NET Framework 2.0 Configuration MMC plug-in, but the only semi-unique > identifier that goes with an assembly in the GAC is the public key token, > and I don't recall whether that changes each version (for sure, it's not > unique to the assembly, because lots of other assemblies share the same > public key token...but it might be unique for the framework version).
> Anyway, that's a long way of saying, no...I don't know why on your > computer the stack trace doesn't match what you see in Reflector.
Now I get the same contents as you have in QuickSort. In the References in the solution Expolere I used this location C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ so I use this location in reflector now.
Earlier I used this location in reflector Location: %ProgramFiles%\Microsoft.NET\SDK\CompactFramework\v2.0\Debugger\BCL\
I just wonder how does the program Red Gate's Reflector decide which assembly to use when there exist several assembly for example System.dll and mscorlib.dll and these assembly have differerent contents.
>> I get the same result if I start form main using reflector and click >> until I >> reach QuickSort >> Have you any idea why I don't see the correct source code in Reflector
> No, sorry I don't. At the very least, if you run Reflector on the exact > same computer where you produced the stack trace showing the call to > SwapIfGreaterWithItems(), it should produce a view of the assembly that is > consistent with the stack trace. The only reason it would/should be > different is if you are looking at a different assembly in Reflector than > you are using in your program.
> That _could_ happen if you have multiple versions of the .NET assemblies > lying around on your computer. But _that_ shouldn't happen normally. A > person would have to intentionally clutter their computer like that, and > surely that's something you'd remember having done?
> All that said, you can verify the exact file being used in both Reflector > and in the debugger. In Reflector, just select the DLL itself, and the > information pane will show you the file path.
> In the debugger, it might be a little more tricky. You can easily see the > source of each DLL loaded in the process by, while debugging, displaying > the "Modules" debug window. But normally, a DLL like mscorlib.dll is > executed from the GAC and this won't match directly with the path shown in > Reflector.
> Of course, if it turns out you're loading a version of mscorlib.dll that's > not in the GAC, then that's probably your problem right there. :) But, if > it's in the GAC, AFAIK the best you can do is look at the entry in the > .NET Framework 2.0 Configuration MMC plug-in, but the only semi-unique > identifier that goes with an assembly in the GAC is the public key token, > and I don't recall whether that changes each version (for sure, it's not > unique to the assembly, because lots of other assemblies share the same > public key token...but it might be unique for the framework version).
> Anyway, that's a long way of saying, no...I don't know why on your > computer the stack trace doesn't match what you see in Reflector.
Now I get the same contents as you have in QuickSort. In the References in the solution Expolere I used this location C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ so I use this location in reflector now.
Earlier I used this location in reflector Location: %ProgramFiles%\Microsoft.NET\SDK\CompactFramework\v2.0\Debugger\BCL\
I just wonder how does the program Red Gate's Reflector decide which assembly to use when there exist several assembly for example System.dll and mscorlib.dll and these assembly have differerent contents.
>> I get the same result if I start form main using reflector and click >> until I >> reach QuickSort >> Have you any idea why I don't see the correct source code in Reflector
> No, sorry I don't. At the very least, if you run Reflector on the exact > same computer where you produced the stack trace showing the call to > SwapIfGreaterWithItems(), it should produce a view of the assembly that is > consistent with the stack trace. The only reason it would/should be > different is if you are looking at a different assembly in Reflector than > you are using in your program.
> That _could_ happen if you have multiple versions of the .NET assemblies > lying around on your computer. But _that_ shouldn't happen normally. A > person would have to intentionally clutter their computer like that, and > surely that's something you'd remember having done?
> All that said, you can verify the exact file being used in both Reflector > and in the debugger. In Reflector, just select the DLL itself, and the > information pane will show you the file path.
> In the debugger, it might be a little more tricky. You can easily see the > source of each DLL loaded in the process by, while debugging, displaying > the "Modules" debug window. But normally, a DLL like mscorlib.dll is > executed from the GAC and this won't match directly with the path shown in > Reflector.
> Of course, if it turns out you're loading a version of mscorlib.dll that's > not in the GAC, then that's probably your problem right there. :) But, if > it's in the GAC, AFAIK the best you can do is look at the entry in the > .NET Framework 2.0 Configuration MMC plug-in, but the only semi-unique > identifier that goes with an assembly in the GAC is the public key token, > and I don't recall whether that changes each version (for sure, it's not > unique to the assembly, because lots of other assemblies share the same > public key token...but it might be unique for the framework version).
> Anyway, that's a long way of saying, no...I don't know why on your > computer the stack trace doesn't match what you see in Reflector.
|
