In my last post I was talking about some issues I found while trying to automate the process of launching a web browser, navigating to a specific page and grabbing some results.
I do have a bunch of stickers with sayings: "Works on My Machine (tm)" but this time I could not even use one of them since even in my machine it refused to work :(. So, the goal of this post is to explain the reasons I got so much pain...
Since an image speak for 1000 words, here it is:
In my case (remember, my first approach was to use a JScript script to automate IE) I was trying to start it from Windows console application (cmd.exe) that happens to be a 64 bit application. That's explain why IE insisted to offer me to install Silverlight; on IE 64 bit version I had not installed it (actually, unfortunately, as of today, Silverlight has support for this platform).
The next step was to figure out why my C# application (the one that hosts the WebBrowser control) was failing with the same symptoms. To be sincere, since I had already faced similar issues when using COM components on .Net applications in x64 machines, this one was a lot easier: Again, as explained here, by default VS sets your application to run on whichever processor architecture (regarding to bitness) you throw at it, i.e, it sets the "target platform" to "Any CPU":
That's mean that in a 64 bit machine (like mine) this application will run in 64 bit CLR, hence IE x64 being launched! Peace of cake :). All I had to do was to set this configuration to "x86". Finally my day would be a little less frustrating than I anticipated it to be.
Really fun, don't you agree?
For the next post I am planing to continue on this subject: 32 x 64 bits developer's pitfalls.
Have fun!
Adriano


0 comments:
Post a Comment
Post a Comment