Sounds like "enable 32bit apps" in application pool settings. Vs seems to be executing as 64bit process and does not use "wow" key which i believe has something to do with running 32 bit apps under 64bit os.
On Friday, 3 January 2014, Greg Keogh <[email protected]> wrote: > Mark, you'll see in my other post that I found the symptoms are actually caused by registry override behaviour, but I don't know who is to blame for the conflict in where they're looking. Everyone seems to be looking under Wow6432 except VS2013. Even the C++ COM component registered itself under Wow6432, which I have always done by going: > comfoobar.exe /regserver (or /unregserver) > I have a vague memory from a year or so ago that when I went looking for the Guids they were under HKCR\CLSID, not the Wow group. > By the way, I tried every trick I could think of to get my WCF project to look under Wow. I jiggled many pool and project attributes, but nothing changes. > Greg > > On 3 January 2014 14:39, Mark Hurd <[email protected]> wrote: >> >> I believe modern (meaning I don't know which version of Windows started this) Windows systems have a per-user HKCR override. So it is possible to have variations like this. >> >> Regards, >> Mark Hurd, B.Sc.(Ma.)(Hons.) >> >> Sent via Windows Phone 8 >> ________________________________ >> From: Greg Keogh >> Sent: 3/01/2014 1:00 PM >> To: ozDotNet >> Subject: COM class not found as admin >> >> Folks, my holiday machine rebuild broke a WCF service that calls a COM component. >> I know the COM class is registered as I can call it from NUnit tests, a command line app and I even browse to it from IE and I see it respond. >> Running or debugging the project in VS2013 as Administrator gives CLASSNOTREG (I run as admin because I was using Local IIS). As an experiment I changed to IIS Express and ran as a normal user and it works. >> Why on earth would a COM class not be found when running VS2013 as admin? >> Greg K >
