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

[William Luu]

Minas,

You can add a suggestion to the Ladybug/Product Feedback Centre on MSDN:

http://labs.msdn.microsoft.com/productfeedback/

--
William Luu
Project Developer
The Grid Corporation 

-----Original Message-----
From: Mina Casiou [mailto:mcasiou@xxxxxxxxxx]
Sent: Thursday, 2 December 2004 11:40 AM
To: dotnet@xxxxxxxxxxx
Subject: RE: [aus-dotnet] Whidbey Beta2 and the "Go Live"






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

bjh~^-bjwhwx%S칻&ޱݺ{.n+޶�&ޱݲry-Xjg^nray隊[hf֧Hbٚu0֧H
_________________
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