I can pretty much garantee that you want the AnyCPU configuration. It's all meta data. When you compile, you end up with MSIL, which is later compiled on demand when executed, as most appropriate for the executing environment. There is rarely a reason to target bitness. Until we upgraded out dev box, it was 32-bit, while test/prod were 64-bit. The same binaries are used in all.
________________________________ From: "Venkatasamy, Vanitha" <vanitha.venkatas...@xpandcorp.com> To: Log4NET User <log4net-user@logging.apache.org> Sent: Thursday, March 22, 2012 1:09 PM Subject: RE: Log4Net for Windows 2008 64bit machine Martin , Thank you for the reply . The reason for this questions is because of our servers. Our Development, QA machine and User testing servers are all in 32 bit and only the production server is 64 bit. I didn’t quite understand “By staying with 32bit you can deploy to both 32 and 64bit environments“ .If I am not wrong ,can I use the dll’s currently I am using 32 bit machine just like that in 64 bit machine ?. Carol , Thank you for the reply. I will check on that “AnyCPU” mode. Thanks, From:Damien Carol [mailto:dca...@blitzbs.com] Sent: Thursday, March 22, 2012 12:17 PM To: log4net-user@logging.apache.org Subject: Re: Log4Net for Windows 2008 64bit machine Dear Vanitha, There are another solution. Try to compile you code with the "AnyCPU" mode. after that you must control each dll with ILSpy that any of you assembly are in "AnyCPU" mode. If all you assemblies are in AnyCPU mode, you can use it with x86 or x86_64 OS. If you can't compile in AnyCPU mode. My advice is to compile in "x86" mode in order to force x86 execution mode. My 2 cents Le 22/03/2012 17:11, Martin Milan a écrit : Vanitha, I am not part of the log4net team, and the following are my own view, and not necessarily those of my employer. Basically, all of the DLLs in your application must be of the same architecture – either all 32bit, or all 64 bit. You can’t have so many in one and so many in the other. So long as you keep to that, you shouldn’t have too much difficulty. The reason you can use the 32bit Dlls on your 64 bit machine comes down to something known as Windows on Windows – basically it emulates a 32bit environment for your app and on you go. You don’t have to do anything – so long as all your dlls are 32 bit, it will just work. If you want to move to 64bit, you’ll need to compile all of your Dlls – that’s your app and anything it references (including log4net, excluding GAC) will need to be recompiled as 64 bit assemblies. I would question why you want to do this – by doing it you will prevent your application from being able to be deployed in 32 bit environments. By staying with 32bit you can deploy to both 32 and 64bit environments. By moving to 64 bit you will lose that, so I would want a reason to make that transition – and a better one than “it just sounds better…” Cheers, Martin. From:Venkatasamy, Vanitha [mailto:vanitha.venkatas...@xpandcorp.com] Sent: 22 March 2012 15:47 To: Log4NET User Subject: Log4Net for Windows 2008 64bit machine Hi All , We are planning to move the application having log4net code to a windows 2008 64bit machine. The application uses a dll ,which has the log4net error logging code with below dll’s referenced in there using log4net; using log4net.Config; and I am using EventLogAppender, RollingFileAppender and custom sendAlertAppender.MultiThresholdNotifyingAppender,sendAlertAppender . Please let me know ,whether it’s going to be any issue . Thanks, Vanitha ________________________________ This message contains Devin Group confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail in error and delete this e-mail from your system. E-mail transmissions cannot be guaranteed secure, error-free and information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or contain viruses. The sender therefore does not accept liability for errors or omissions in the contents of this message which may arise as result of transmission. If verification is required please request hard-copy version. EnServe Group Limited ("EnServe"), registered in England and Wales with registration number 3250709.EnServe's registered office is at Hertsmere House, Shenley Road, Borehamwood, Herts, WD6 1TE, United Kingdom and a list of EnServe's subsidiaries and their registered particulars is available for inspection at this location. This email and any attachments to it are confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of EnServe or its subsidiaries. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. This message has been scanned by Symantec Mail Security -- Damien CAROL · tél : +33 (0)4 74 96 88 14 · email : dca...@blitzbs.com BLITZ BUSINESS SERVICE ________________________________ This message contains Devin Group confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail in error and delete this e-mail from your system. E-mail transmissions cannot be guaranteed secure, error-free and information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or contain viruses. The sender therefore does not accept liability for errors or omissions in the contents of this message which may arise as result of transmission. If verification is required please request hard-copy version.
