logging-log4net-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd <todd_beaul...@yahoo.com>
Subject Re: Log4Net for Windows 2008 64bit machine
Date Thu, 22 Mar 2012 17:36:19 GMT
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.Venkatasamy@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:dcarol@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.Venkatasamy@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 : dcarol@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.
Mime
View raw message