Re: [aus-dotnet] Whidbey Beta2 and the "Go Live"

[mcasiou]

I'm using the Logging App Block and the EIF for the logging
functionality....
I'm not sure where Log4Net is heading. Having gone open source is a little
unsettling for me. I like the freedom of being able to change the app
blocks to do exactly what I want.

I wander what performance overhead there is using this ContextBoundObject
etc.
First drawback I see is that seeing as you don't get Multiple Inheritance
with these languages, you can't use it on many classes - aspx, asmx, ascx
for example...
I will only be able to use it on my standard classes - the ones that
usually inherit from System.Object.  :(
Just concerned about execution time...seems to be a whole lot of stuff in
there happening on the call of a method. Can't be too performance friendly,
sinks chains here & there...

Ooh well. May just have to do it to get some stats...



Cheers
Minas Casiou
Information Systems Architect, Senior Consultant
CSC Australia – Financial Services - Enterprise Business Solutions
26 Talavera Road
Macquarie Park NSW
2113 Australia
Ph: (02) 9034 3338
Mob: 0412 343 069
email: mcasiou@xxxxxxxxxx
----------------------------------------------------------------------------------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
----------------------------------------------------------------------------------------




|---------+--------------------------->
|         |           Alex Hoffman    |
|         |           <alexh@xxxxxxxxx|
|         |           om>             |
|         |           Sent by:        |
|         |           dotnet-owner@sta|
|         |           nski.com        |
|         |                           |
|         |                           |
|         |           03/12/2004 02:29|
|         |           PM              |
|         |           Please respond  |
|         |           to dotnet       |
|         |                           |
|---------+--------------------------->
  >-------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                               |
  |        To:      dotnet@xxxxxxxxxxx                                                                                            |
  |        cc:                                                                                                                    |
  |        Subject: Re: [aus-dotnet] Whidbey Beta2 and the "Go Live"                                                              |
  >-------------------------------------------------------------------------------------------------------------------------------|




 > method call interception ... logging ...

http://msdn.microsoft.com/msdnmag/issues/03/03/ContextsinNET/default.aspx

However, I recommend log4net - rather than trying to implement your own
AOP solution for logging :)

Alex Hoffman

Mina Casiou said the following:
>
>
>
> Finula,
>
> I'd like to submit a feature request if allowed! Not sure of the exact
> place to ask for this, but hopefully you'll let us know.
> It's probably too late to ask for this, and it'll probably require a
change
> to the CLR (read as - so it'll probably never happen!)...
> Anyway, here goes...
>
> Problem: Logging/Instrumentation etc...
> When attempting to write performance conscious logging code, for example,
> using the Logging App. Block and the EIF, the 1 liner's etc.
>
> If (eventPublishLogLevel > applicationLogLevel) And
> EventSource.Application.IsEnabledForType(GetType(TraceMessageEvent)) Then
:
> TraceMessageEvent.Raise(myEventSource, eventPublishLogLevel, "Trace
Message
> Event to be published.") : End If
>
> or
>
> If (eventPublishLogLevel > applicationLogLevel) And
> EventSource.Application.IsEnabledForType(GetType(TraceMessageEvent)) Then
:
> TraceMessageEvent.Raise(myEventSource, eventPublishLogLevel,
> obj.SerialiseToXML()) : End If
>  or ...
>
> 3 liner...
> If (eventPublishLogLevel > applicationLogLevel) And
> EventSource.Application.IsEnabledForType(GetType(TraceMessageEvent)) Then
>  TraceMessageEvent.Raise(myEventSource, eventPublishLogLevel,
> obj.SerialiseToXML())
>  End If
>
> are common bits of code that we write in order to avoid the function call
&
> parameter setup overhead etc. for a log message that will never happen
> because of the current loglevel.
>
> The 'if' statement makes the code look horrible. I try to fit it all on
one
> line in order to not obscure the rest of the codebase with
instrumentation
> code.
> Ideally, I'd be able to make the following call without the performance
hit
> if the Raise event was configured to not log this message. I've found
about
> a 30% performance gain/hit by the use of the 'if' statement. This is a
big
> hit if not done. Unfortunately, the code now looks a little more ordinary
> that I'd like. I don't exactly have the best coding style myself!
>  TraceMessageEvent.Raise(myEventSource, eventPublishLogLevel,
> obj.SerialiseToXML())
>
> Anyway, now to the feature request...
> It would have been nice to be able to do something like the following:
>  TraceMessageEvent.Raise(myEventSource, eventPublishLogLevel,
> obj.SerialiseToXML())
>
> public function Raise (myEventSource as EventSource, eventPublishLogLevel
> as Integer, [delayEvalParam] sMsgToLog as String)
>         If (eventPublishLogLevel > applicationLogLevel) And
>           EventSource.Application.IsEnabledForType(GetType
> (TraceMessageEvent)) Then
>             EvalDelayEvalParams() 'now call the code to get this
> parameter...
>
>             'do the actual logging work...
>             actualLog(myEventSource, eventPublishLogLevel, sMsgToLog)
>
>       'else do nothing...
>
>         End If
> end function
>
> ...which you obviously can do...but the sMsgToLog variable has already
been
> evaluated...i.e. obj.SerialiseToXML() has already been called to
Serialize
> the Object to XML (a costly operation).
>
> but if you could do something like add an attribute to some of the input
> parameters...:
> [delayEvalParam]
> EvalDelayEvalParams()...
> then the ugly code could be removed from the calling code.
> Note that I could currently setup a function callback that the 'Raise'
> function could call, but this would still leave my calling code littered
> with crap (probably much worse than what it currently is...). Remember
that
> a particular function can make numerous calls for instrumentation, and
> almost all of my functions do some sort of instrumentation.
> In the above scenario, the calling code would not be littered with 'if'
> statements etc.
>
> Which leads me onto another topic - method call interception... I had
seen
> some code once, but forgot about it & lost it. I wanted to automatically
> log some stuff on method start and end. Anyone know where this sample
code
> or framework is?
>
>
> Cheers
> Minas Casiou
> Information Systems Architect, Senior Consultant
> CSC Australia – Financial Services - Enterprise Business Solutions
> 26 Talavera Road
> Macquarie Park NSW
> 2113 Australia
> Ph: (02) 9034 3338
> Mob: 0412 343 069
> email: mcasiou@xxxxxxxxxx
>
----------------------------------------------------------------------------------------

>
> This is a PRIVATE message. If you are not the intended recipient, please
> delete without copying and kindly advise us by e-mail of the mistake in
> delivery. NOTE: Regardless of content, this e-mail shall not operate to
> bind CSC to any order or other contract unless pursuant to explicit
written
> agreement or government initiative expressly permitting the use of e-mail
> for such purpose.
>
----------------------------------------------------------------------------------------

>
>
>
>
>

>                       "Finula Crowe"

>                       <finulac@microso         To:
<dotnet@xxxxxxxxxxx>
>                       ft.com>                  cc:

>                       Sent by:                 Subject: RE: [aus-dotnet]
Whidbey Beta2 and the "Go Live"
>                       dotnet-owner@sta

>                       nski.com

>

>
>                       01/12/2004 04:36

>                       PM

>                       Please respond

>                       to dotnet

>

>

>
>
>
>
> The BETA 2 of both the Visual Studio 2005 and Team System and the
> Express line is currently scheduled for Q1 of the calendar year (i.e.
> Feb/March time frame).  The RTM date for VS 2005, Team System and
> Express is scheduled for 2nd half of 2005 so, Stephen has a pretty good
> "buddy" there ;-)
>
> Cheers
> Fin
>
> Finula Crowe
> Product Manager - Developer Tools
> Developer & Platform Evangelism Team
> 02 9870 2399
> 0414 899 301
>
> To find out more about your local Microsoft Developer Tools community
> activities, go to:
> http://www.microsoft.com/australia/msdn
>
>
>
> -----Original Message-----
> From: dotnet-owner@xxxxxxxxxxx [mailto:dotnet-owner@xxxxxxxxxxx] On
> Behalf Of Stephen
> Sent: Tuesday, 30 November 2004 4:07 PM
> To: dotnet@xxxxxxxxxxx
> Subject: Re: [aus-dotnet] Whidbey Beta2 and the "Go Live"
>
> last I had confirmed, my microsoft buddy suggested a go live licence
> in March 2005 and final release in , well, 2005. Basicaly, it was
> suggested that if they have given the 2005 name then it will be
> released in 2005.
>
> S.
>
>
> On Tue, 30 Nov 2004 15:53:55 +1100, Clarke Scott <info@xxxxxxxxxxxxxxx>
> wrote:
>
>>
>>
>>I've heard some rumors that Whidbey Beta 2 release has slipped again.
>>
>>Can someone confirm or deny this?
>>
>>If so, what is the likely release date, now?
>>
>>
>>
>>Thanks
>>
>>Clarke
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
> --
>
> Mercantile Systems
> http://www.mspl.com
> _________________
> You are a part of the Australian "dotnet" mailing list.
> To unsubscribe send "unsubscribe dotnet" or to re-subscribe send
> "subscribe dotnet Your Name" in the body of the email to:
> imailsrv@xxxxxxxxxxx
> List managed by: http://www.stanski.com
> _________________
> You are a part of the Australian "dotnet" mailing list.
> To unsubscribe send "unsubscribe dotnet" or to re-subscribe send
"subscribe
> dotnet Your Name" in the body of the email to: imailsrv@xxxxxxxxxxx
> List managed by: http://www.stanski.com
>
> b����j�h~�^�-��bjwh�w�����x%��S��칻�&ޱ�ݺ{.n�+�����޶������&ޱ�ݲ��r��y�
-��X���jg���^n�r��ay隊[h�f����֧�H��b�ٚ��u�����0�֧�H�om==
_________________
You are a part of the Australian "dotnet" mailing list.
To unsubscribe send "unsubscribe dotnet" or to re-subscribe send "subscribe
dotnet Your Name" in the body of the email to: imailsrv@xxxxxxxxxxx
List managed by: http://www.stanski.com