No, no simple way, no. Remember that your code can have a dependency on a external dll, that *itself* has a dependency on a library that you *happen* only to have 32 bit version of installed (as mentioned elsewhere, db drivers are the most common). Not simple. ________________________________ From: [email protected] <[email protected]> on behalf of Tom P <[email protected]> Sent: Tuesday, February 19, 2019 11:34:32 AM To: ozDotNet Subject: Re: Legacy Asp.net application change from 32bit to 64bit
Just doing it would require full regression testing, would it not? I don’t suppose there is a simple way to check if any non compliant old DLLs are used? On Tue, 19 Feb 2019 at 14:23, Greg Keogh <[email protected]<mailto:[email protected]>> wrote: My question is what should I consider if I want to change to 64 bit? Can anything break? I'd just turn off the 32-bit flag in the pool, run it and see what happens. If it's calling some weird old native API then you should find out soon enough. Strangely enough, I'm in the reverse situation, trying to downgrade to 32-bit. I have a Web Api in Azure that's calling a 64-bit Borland DLL, so the minimum plan for 64-bit is ~$80/month, whereas for 32-bit it's ~$20/month. Lord knows why it's quadruple price for 64-bit. I tried to build and test in VS2017 with the 32-bit DLL and everything failed and crashed in every way possible. You think that would be easy, but I'm still trying to figure it out Greg K -- Thanks Tom
