Earlier I posted on the fact that getting the SalesLogix web client working on vista not quite possible at this time. I am really happy to say that after some poking, a little log browsing an a google search I now have it working correctly.
To figure out what was going wrong for me I turned on assembly binding logs (fuslogvw.exe) , choosing to only log failures. I set the log path to a simple c:\log directory. Since I really only cared about the failure at this time I turned on ‘Only log bind failures to disk’.
Running this utility will add some settings into the registry under HKLM\Software\Microsoft\Fusion
DWORD LogFailures – will store a value of 1 meaning to log bindings (you can change this to 0 to disable logging)
SZ LogPath – Location to log the binding failures
I then tried to open the web site where an error was reported. I went into the log folder that I designated and noticed a file for dtSearchNetApi2 and opened it discovering that the assembly was found but a HRESULT was being returned with the value of 0x800700b. This is where google came in and I discovered that the issue I was having was with regards to 64 bit app pool and 32 bit interop.
More so I was able to easily find an answer to my problem and got it working.
So, to get it working on a 64 bit machine there are 2 things you have to do;
1. Ensure that the site AppPool is setup with Classic Asp.net
2. On 64 bit machines since there is some COM Interop interacting with 32 bit dll’s you will need to enable 32 bit application pools.
Type the following at a command line prompt
cscript %SystemDrive%\inetpub\AdminScripts\adsutil.vbs set w3svc/AppPools/Enable32bitAppOnWin64 1
To turn off the 32 bit application pool change the last value to a 0
cscript %SystemDrive%\inetpub\AdminScripts\adsutil.vbs set w3svc/AppPools/Enable32bitAppOnWin64 0
Thanks to Ryan Hoffman for information about this setting.
– Mark
This is awesome news, and sounds like the final piece I needed to upgrade my workstation to Win2008 (I use the server OS). Thanks so much for putting this together.
Mark, you are a genius – this worked like a charm. The only additional thing I had to do was change the identity on the application pool – for some reason the default of “Network Service” would crash the web server process when trying to log in.
Mark,
This is a great article. I hit the wall trying to run it under XP 64. Your article applied the same.
I however had another issue going against me, I had installed and was running the 64 Bit Framework.
I installed the 32 bit v2 Framework on IIS and that together with your changes got me going.
Raul, Glad the information helped. The problem with 64 bit and the web and lan client is there there are still unmanaged 32 bit only components. If the application process begins its lifecycle as a 64 bit application things break. This is why things like .Net extension manager would not start on a 64 bit machine as well. The compile settings within VS must be explicity set to target x86 and things **should** work as expected.