I just dl'ed 716 version to check out VS integration. For some reason, every managed release mode dll or exe I try to returns "<assembly name here> has not been regenerated due to the following exception occuring: Unable to find sn.exe". Same DLLs are openeded successfully in the standalone reflector.

The only way to get reflector add-in past the error is to start VS command prompt and launch devenv.exe from there.

HEre's the specs of the machine:

Server 2008 R2 64-bit
VS2008(no 2005 or 2010 versions installed) ran in admin and regular modes.
Windows 7SDK
No changes made to environment variable


I hope this helps making the product better. The concept of inegrated reflector is absolutely genious!
syampolsky
0

Comments

7 comments

  • Alex D
    Thanks for the report, and those details of your setup are really useful. We'll try to reproduce it, I'll let you know if we can.

    Thanks,
    Alex D
    0
  • Alex D
    Could you check whether you have a copy of sn.exe anywhere on your hard drive, and let me know exactly where if you do?

    I expect there's one in a folder something like:
    C:\Program Files\Microsoft SDKs\Windows\v6.0A\BinThanks,
    Alex D
    0
  • Alex D
    There are a few exception reports coming in about this, but I really need to know where sn.exe is located on machines with this problem. Please let me know if you get this issue.

    Thanks,
    Alex D
    0
  • xul8tr
    I have the same issue with VS2008.

    I am running Windows 7 x64. I fixed the issue by doing the following"

    1) Close Visual Studio and .NET Reflector

    2) Rename the folder C:\Program Files (x86)\Microsoft SDKs\Windows\v6.0A\ to C:\Program Files (x86)\Microsoft SDKs\Windows\v6.0A-TEMP\

    3) Copy the folder C:\Program Files\Microsoft SDKs\Windows\v6.0A\ to C:\Program Files (x86)\Microsoft SDKs\Windows\v6.0A\

    4) Copy everything in C:\Program Files (x86)\Microsoft SDKs\Windows\v6.0A-TEMP\ to C:\Program Files (x86)\Microsoft SDKs\Windows\v6.0A\ and replace any conflicts.

    5) Delete the empty folder C:\Program Files (x86)\Microsoft SDKs\Windows\v6.0A-TEMP\

    I did it this way to make sure I didn't overwrite any potential x86 files to help preserve compatibility as best as possible. Hope this helps!
    xul8tr
    0
  • Alex D
    Ah, thanks a lot for that, that's really helpful. I'm not looking in C:\Program Files\Microsoft SDKs\Windows\v6.0A\ on x64 machines.

    Thanks for letting people know that workaround. I'll have a fixed build out later this morning.

    Cheers,
    Alex D
    0
  • syampolsky
    I ran "Windows SDK Configuraion Tool" and changed registered SDK version from 6.0A to 7.0 and everything started working!!! I'm a happy camper!
    syampolsky
    0
  • Alex D
    Yes, there are a couple of exception reports still coming in about this, if you know which location that sn.exe can be located I've missed, I'd really appreciate you letting me know.
    Alex D
    0

Add comment

Please sign in to leave a comment.