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

[Mina Casiou]

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�����h~���bjwh�w�����x%������&ޱ�{.n�������������&ޱ����y����g���n�r���[h�f����֧�H��b����u�����0�֧�H��