Resolved: Doesn't seem to work

Sep 5, 2012 at 10:57 AM

I downloaded the package, extracted the icons from VS2010, injected them into 2012 with no errors. I loaded up VS2012 and all the icons were still the same. Have they changed something between releases to stop this working?

Scott

Coordinator
Sep 6, 2012 at 7:50 AM

If you haven't gotten this to work here's a couple questions to help troubleshoot what might be wrong.

  1. What version of Visual Studio 2010 and 2012 are you using this on?
  2. What language is your install of Windows and Visual Studio?
  3. What type of projects are you opening?
  4. Have you tried running the injection process again?

Since the initial release I've found a number of spots where the new icons still exist in VS2012 after injecting the old icons so there's a chance, depending on the type of project you’re opening, that the new icons will show instead of the old icons.

If you want to verify your files the documentation section now contains a list of their checksums both before and after patching.

Sep 6, 2012 at 9:25 AM

Hi xt0rted, thank for the reply.

1. I am running VS2012 Premium and VS2010 Premium

2. Both are in English

3. I have several within one solution (mainly web), although i downloaded your source code and they didn't change with that either.

4. Yes, with reboots in between.

As for the check sums, i don't get the same as you. Here is one of them with the tool you linked to:

Orig:
//// File Checksum Integrity Verifier version 2.05.//               

MD5                             SHA-1

-------------------------------------------------------------------------

e2bb283eaacf3866695d8bce3c70d2b5 3737cfe82b0e1215e21c6c648212dcee39f7fb83

c:\program files (x86)\microsoft visual studio 11.0\common7\ide\msenv.dll.orig

 

Patched:

//// File Checksum Integrity Verifier version 2.05.//               

MD5                             SHA-1

-------------------------------------------------------------------------

a9195b5adcf9d4870cf125b1fa0fa3c8 414b9d73781b977d21e067f2fbf816045baeea4c

c:\program files (x86)\microsoft visual studio 11.0\common7\ide\msenv.dll

Thanks

Scott

Coordinator
Sep 7, 2012 at 4:52 AM

It looks like I put the wrong versions of the checksums up, did base64 instead of hex. That page is updated with the right values now. The original file matches mine so that's good.

When you re-ran the injection process did you restore the original files first? If not I added in a new command to restore your backed up files. Try doing that, or manually if you prefer, and rerunning the injection command again.

Are you on a 32bit or 64bit machine?

Sep 7, 2012 at 7:57 AM

I downloaded the new source, complied it and restored the DLLs. I checked the hashes against the documentation and they were the same. I then rebooted (no there were no locks etc). Ran the inject, and my hash is no longer the same : //// File Checksum Integrity Verifier version 2.05.//a9195b5adcf9d4870cf125b1fa0fa3c8 c:\program files (x86)\microsoft visual studio11.0\common7\ide\msenv.dll

I am on Windows 7x64 Enterprise

This is the hash for the VS2010 version, to make sure im extracting the right version (although the bmps work):

//// File Checksum Integrity Verifier version 2.05.//5c192d9c92f50b0cf578ed7b7e9b942b c:\program files (x86)\microsoft visual studio10.0\common7\ide\msenv.dll

Scott

Coordinator
Sep 10, 2012 at 8:38 AM
Edited Sep 10, 2012 at 8:39 AM

The problem stems from running Windows with a culture set to something other than US English. More info on this, and a fix, can be found here.

Sep 10, 2012 at 11:17 AM

I'm running a German Windows and an English VS2012. So What should I change to get this working?

Sep 10, 2012 at 1:02 PM

Hi Andre,

If you are running english version of VS you should be able to patch the code. You’ll need to update line 108 in InjectIcons.cs to Unmanaged.UpdateResource(destination, Unmanaged.RT_BITMAP, dll.ImageId, 1033, bytes, (uint)bytes.Length);

Make sure you do a restore if you have already tried to inject the new icons. If you haven't, do a backup first.

Thanks

Scott

Coordinator
Sep 10, 2012 at 8:19 PM

Hi Andre,

As Scott says the fix should be replacing Unmanaged.GetSystemDefaultLangID() with 1033. I need to do some more testing with non US English configurations but from what I've seen so far I think this change is the same no matter what language setup you're running. If changing this doesn't work contact me directly and I'll look into this more for your specific install.

If you've backed up your DLLs already using backup -v=2012 then you can restore them using restore -v=2012