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 <[email protected]> > Sent: 3/01/2014 1:00 PM > To: ozDotNet <[email protected]> > 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 >
