{"id":11,"date":"2013-03-22T23:19:44","date_gmt":"2013-03-22T23:19:44","guid":{"rendered":"http:\/\/putridparrot.com\/blog\/?p=11"},"modified":"2013-03-22T23:29:29","modified_gmt":"2013-03-22T23:29:29","slug":"32-bit64-bit-incompatibility-fun","status":"publish","type":"post","link":"https:\/\/putridparrot.com\/blog\/32-bit64-bit-incompatibility-fun\/","title":{"rendered":"32-bit\/64-bit incompatibility fun"},"content":{"rendered":"<p>So, I&#8217;m working on a C#\/.NET application which currently uses a 32-bit version of TIBCO RV. The company I&#8217;m working for is (slowly) moving from Windows XP over to Windows 7 (and the brave new world of 64-bit computing). However they&#8217;re obviously wanting to test their suite of in-house application and ensure they&#8217;re all run correctly on the 64-bit machines.<\/p>\n<p>I&#8217;ve been tasked with ensuring our application works. Ofcourse immediately we hit a problem which was the use of the 32-bit TIBCO RV. The application, by default, was built with the &#8220;Any CPU&#8221; configuration. The way the JIT works is that it will JIT compile &#8220;Any CPU&#8221; code to the architecture of the CPU, so on a 32-bit OS it&#8217;s 32-bit and on a 64-bit OS it&#8217;s run as a 64-bit application &#8211; which is how it obviously should be.<\/p>\n<p>But with the inclusion of the 32-bit DLL and the JIT switching the application to 64-bit obviously caused a bit of a problem and we were seeing the &#8220;System.BadImageFormatException&#8221; exception when the application attempted to load the 32-bit DLL. Ofcourse this is to be expected as you can&#8217;t mix 64-bit and 32-bit in the same application.<\/p>\n<p>Apart from the obvious solution of getting a 64-bit version of TIBCO RV installed (which is ultimately where we&#8217;d hope to end up). How do we solve this problem now?<\/p>\n<p>So the key to solving this is the &#8220;Any CPU&#8221; configuration. If we create an x86 configuration we can force the JIT to build for a 32-bit architecture and x64 will force the code to 64-bit.<\/p>\n<p>Now here I made a subtle mistake which I&#8217;m going to share with you. I created a new configuration whereby all projects were switched to &#8220;x86&#8221; I compiled the application without a hitch and deployed it, only to find it still failing. Part of the problem was I didn&#8217;t have a 64-bit machine to run on, so this was a rather slow process of building, deploying and testing :)<\/p>\n<p>To cut a long story short (too late I know). I eventually got some time on a 64-bit machine. I rebuilt the client on this machine in &#8220;x86&#8221; mode and strangely (unlike building it on the 32-bit machine) I got loads of errors. Seemingly incompatible assemblies all pointing to a bunch of third party UI assemblies (which I assume are built as Any CPU)  &#8211; now I&#8217;ve not confirmed this yet but I wondered at this point whether the problem is to do with some of my assemblies configured as x86 and others as Any CPU. That&#8217;s something I need to look into.<\/p>\n<p>Anyway further investigation brought to my attention the following application<\/p>\n<p><a title=\"corflags\" href=\"http:\/\/msdn.microsoft.com\/en-us\/library\/ms164699(v=vs.80).aspx\" target=\"_blank\">corflags<\/a> \/32bit+<\/p>\n<p>I used this on the EXE only and ran the application an it worked perfectly.<\/p>\n<p>Switching back to Visual Studio I changed only the EXE&#8217;s project to build x86 code. I recompiled the solution and had no incompatibilities during the build. Then I ran the application and all worked perfectly.<\/p>\n<p>So it appears just setting the entry point (in this case the EXE) to x86 solved the problem, seemingly forcing the application into 32-bit mode.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>So, I&#8217;m working on a C#\/.NET application which currently uses a 32-bit version of TIBCO RV. The company I&#8217;m working for is (slowly) moving from Windows XP over to Windows 7 (and the brave new world of 64-bit computing). However they&#8217;re obviously wanting to test their suite of in-house application and ensure they&#8217;re all run [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[3,2],"tags":[],"class_list":["post-11","post","type-post","status-publish","format-standard","hentry","category-c","category-programming"],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/posts\/11","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/comments?post=11"}],"version-history":[{"count":3,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/posts\/11\/revisions"}],"predecessor-version":[{"id":38,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/posts\/11\/revisions\/38"}],"wp:attachment":[{"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/media?parent=11"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/categories?post=11"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/tags?post=11"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}