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

[Glavich, Paul C]

Mina,

As already mentioned, the "Ladybug" product feedback site is probably the
best way to go. For ASP.NET related matters, I can submit product feature
requests on your behalf direct to the product team for you, however feature
requests are probably a bit late now as they are in the stage where they are
more concerned with quality assurance and bug fixing. The "LadyBug" site
will at least give you a record of your feature request for later action
whereas I simply pass it on to the team directly.

Right now, the ASP.NET team is working feverishly away at ensuring that a
quality product gets out the door and are particularly interested in product
issues, especially when trying to migrate current web projects from older
versions to the newer versions. So new features are not really being looked
at right now.


- Paul Glavich

-----Original Message-----
From: dotnet-owner@xxxxxxxxxxx [mailto:dotnet-owner@xxxxxxxxxxx] On Behalf
Of Clarke Scott
Sent: Thursday, 2 December 2004 11:45 AM
To: dotnet@xxxxxxxxxxx
Subject: RE: [aus-dotnet] Whidbey Beta2 and the "Go Live"

I've entered a few at
http://lab.msdn.microsoft.com/productfeedback/default.aspx


-----Original Message-----
From: dotnet-owner@xxxxxxxxxxx [mailto:dotnet-owner@xxxxxxxxxxx] On Behalf
Of Mina Casiou
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

bj橻h~^ -bjwhwx%Sˢ &ޱ {.n+lj �&ޱ  ry-ڝX jg͢^n؇ray [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
_________________
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