Anurag Gandhi wrote:
Take my kids to Amusement park at least 2 times this year.
How would taking your kids to Amusement park make my personal life better?? Sorry dude, there are some things you shouldn't try to delegate ;P
Anurag Gandhi wrote:
Take my kids to Amusement park at least 2 times this year.
How would taking your kids to Amusement park make my personal life better?? Sorry dude, there are some things you shouldn't try to delegate ;P
We decided to run our application as a 64-bit app. We had two options to accomplish this: Option 1: Compile all component projects targeting 64bit processor. Replace all 3rd party .dlls with their 64 bit versions. Host the application under 64 bit app pool in IIS. Option 2: Compile all component projects targeting 'Any CPU'. Set the 'LargeAddressAware' option as a post build task. Replace all 3rd party .dlls with their 64 bit versions. Host the application under 64 bit app pool in IIS. The application renders correctly when we try option 1. Whereas, in option 2, the application has rendering issues. Some of the label controls are not visible in the browser and few buttons appear empty with no text in them. Any idea what could cause this wierd problem?
Hi all, I have an ASP.Net application developed in .Net 4.0. The web app uses around 30 .Net libraries (all custom built within our org.). These were developed about 6 years ago. We have deployed this app recently for a client under a Win 2008 R2 server. The application and all associated .dlls are compiled under 32 bit settings and we have configured the App pool to run under 32 bit too. The client started complaining of frequent out-of-memory scenarios. The application uses Session extensively to store data. We suggested increasing the server RAM from 4 gigs to 8 gigs. Despite this upgrade, the issue continues to occur. While I was researching online, I came across the design constraint that w3wp is limited to use only 2GB of addressable memory when running in 32 bit mode. (Article link) I understand that I have to compile the application and all associated libraries to run under 64 bit. Meanwhile, I was wondering if increasing the worker process count will help me resolve this issue without modifying the code base. The server has a 8-core processor, hence I could increase the worker processes to 8. I could also enable processor affinity to ensure one request is handled by one wp alone, thereby taking care of session data availability. Has anyone done something similar? Any guidance is appreciated.