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
CLASSN
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
-Original Message-
From: "Greg Keogh"
Sent: 3/0
Procmon is showing me that the apps that work correctly are reading the COM
registration from this key:
HKCR\Wow6432Node\CLSID\{8760F575-2E30-4F35-80C8-44D9D77E0D92}
Whereas the failure running in VS2013 shows it reading this key and failing
NOT FOUND:
HKCR\CLSID\{8760F575-2E30-4F35-80C8-44D9D77
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
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 wrote:
> Mark, you'll see in my other post that I f
