Set Trace to Ignore Errors in Trace.WriteLine?

  • Thread starter Thread starter Stewart Berman
  • Start date Start date
S

Stewart Berman

I am working my way through various parts of the VB.NET diagnostics and error handling and ran
across a small problem. It concerns a program that sits in the tray and runs continuously.

A runtime error was thrown at the first Trace.WriteLine statement -- see details below -- because
the ApplicationName_Trace.log file was locked (although I cannot find anything that might have
locked it at the time the error was thrown).

In the VB6 world I would have written my own logging class and it would always contain an "On Error
Resume Next" statement as Tracing/Error logging should never throw an error that stops the program.

Is there a setting or another way to do the equivalent in the TraceListener class -- preferably via
the app.config files? I really don't want to have to wrap every Trace block in a Try configuration.

Details:

The TraceListener is defined as:
<trace useGlobalLock="false" autoflush="true" indentsize="3">
<listeners>
<add name="traceListener" type="System.Diagnostics.TextWriterTraceListener"
initializeData="SABBackgroundSlideShow_Trace.log" />
<!-- <remove name="Default" /> -->
</listeners>
</trace>

The trace file ended at the CBackgroundWorker_ProgressChanged Tracing Ended statement below before I
hit the Continue button. The first line to be added after that was the Picturebox loading started
line. There is one line missing in the trace because of the error.
20090713 14:12:07.453: CBackgroundWorker_ProgressChanged Tracing Started
20090713 14:12:07.453: OnSlideShowProgressChanged Tracing Started
20090713 14:12:07.453: OnSlideShowProgressChanged Tracing Started
20090713 14:12:07.453: Percent of display time left: 10
20090713 14:12:07.453: OnSlideShowProgressChanged Tracing Ended
20090713 14:12:07.453: OnSlideShowProgressChanged Tracing Ended
20090713 14:12:07.453: CBackgroundWorker_ProgressChanged Tracing Ended
< *** Missing trace line **>
20090713 14:12:13.453: Picturebox loading started: C:\Common\SlideShow\IMG_2496.JPG
20090713 14:12:13.750: Picturebox loading completed: C:\Common\SlideShow\IMG_2496.JPG


If (cvarTraceSwitch.TraceInfo) Then
Trace.WriteLine(Format$(Now(), "yyyyMMdd HH:mm:ss.fff: ") &
System.Reflection.MethodBase.GetCurrentMethod.Name & " Tracing Started")
Trace.Indent()
End If

CBackgroundWorker = CType(sender, BackgroundWorker)
lMemoryInUseStarting = MemoryInUse()
dataSet = LoadData(CType(e.Argument, DataSet))
CWallpaper = New Wallpaper()
Thread.CurrentThread.Priority = ThreadPriority.BelowNormal
Do While (Not CBackgroundWorker.CancellationPending)
nValid = 0
nRows = dataSet.Tables("Images").Rows.Count
If (0 < nRows) Then
For nRow = 1 To nRows
If ((CBackgroundWorker.CancellationPending) OrElse (0 <>
Interlocked.CompareExchange(cvarReload, -1, -1))) Then
Exit For
End If
dataRow = dataSet.Tables("Images").Rows(nRow - 1)
If (CType(dataRow.Item("Valid"), Boolean)) Then
sFilePathName = CType(dataRow("FileFolder"), String) & "\" &
CType(dataRow("FileName"), String)
pictureBox = New PictureBox()
Try
Trace.WriteLineIf(cvarTraceSwitch.TraceInfo, Format$(Now(), "yyyyMMdd
HH:mm:ss.fff: ") & "Picturebox loading started: " & sFilePathName)
pictureBox.Load(sFilePathName)
Trace.WriteLineIf(cvarTraceSwitch.TraceInfo, Format$(Now(), "yyyyMMdd
HH:mm:ss.fff: ") & "Picturebox loading completed: " & sFilePathName)
Catch ex As Exception
dataRow.Item("Valid") = False
Trace.WriteLineIf(cvarTraceSwitch.TraceWarning, Format$(Now(), "yyyyMMdd
HH:mm:ss.fff: ") & "Error in loading picturebox: " & ex.ToString())
Finally
pictureBox.Dispose()
pictureBox = Nothing
End Try
End If

The error thrown was:
System.IO.IOException: The process cannot access the file because another process has locked a
portion of the file.

at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.WriteCore(Byte[] buffer, Int32 offset, Int32 count)
at System.IO.FileStream.FlushWrite(Boolean calledFromFinalizer)
at System.IO.FileStream.Flush()
at System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder)
at System.IO.StreamWriter.Flush()
at System.Diagnostics.TextWriterTraceListener.Flush()
at System.Diagnostics.TraceInternal.WriteLine(String message)
at System.Diagnostics.Trace.WriteLine(String message)
at SABBackgroundSlideShow.SlideShow.CBackgroundWorker_ProgressChanged(Object sender,
ProgressChangedEventArgs e)
at System.ComponentModel.BackgroundWorker.OnProgressChanged(ProgressChangedEventArgs e)
at System.ComponentModel.BackgroundWorker.ProgressReporter(Object arg)
 
Hi Stewart,

I think the problem is not how to get around this error, but to find out
the root cause.

How often does this locking problem happen? Are there any patterns you can
find of when it happens?

Also, there is a very useful tool that we use almost everyday can help you
find out who exactly were locking on your log file. Please download the
Process Monitor from this URL:
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx.

It doesn't require installation. Just extract the files and run procmon.exe.

Then you add a filter to the ProcMon:

Path contains <your log filename> then Include.

Keep ProcMon running, and start your application, the ProcMon will log
every activity against your log file including which process did what.

Hope you can find the clue out of the ProcMon log.

If you need help analyzing the log, please let me know, and I can help you
take a look.

Thanks,

Jie Wang

Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business days is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
I don't know what caused the first lock-up but I had another one last night and I am pretty sure it
was caused by one of my nightly backup runs.

Given that the program runs continuously as long as the user is logged in and writes a bunch of
trace messages roughly every 60 seconds how does one avoid throwing an error when the trace file is
used by another process? Even copying it would put a read lock on the file stopping the trace
process from writing to it.

Short of filling up the application event log there appear to be two choices:

1. Put the trace log in an separate directory that is only used for it and is not backed up.
Problem: Do not know how to specify such a directory in the app.config file which cannot even
reference special folders like the user's temp directory.

2.Write a wrapper for the Trace class to handle this.
Problem: How to do this so (1) it is available to all code in the application immediately and (2)
does not need to be initialized in code.
 
Hi Stewart,

I just took a look at the Trace class and the TextWriterTraceListener class
implementation.

What I found is, after the first time writing to Trace, the log file is
opened (or created) and locked - other processes should not be able to lock
it for writing.

So I think it is better to lock on the file during the app initialization
phase by writing something into the log, this will ensure the log file is
opened & locked in an early stage.

If that still doesn't work, then realtime debugging is needed to find out
the root cause.

Best regards,

Jie Wang

Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business days is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
What I found is, after the first time writing to Trace, the log file is
opened (or created) and locked - other processes should not be able to lock
it for writing.
Click to expand...

The problem appears to be something reading the log file not writing to it. The error message was
very clear -- the Trace Writeline method was unable to access the file (I assume for writing)
because another process had a portion of it locked. It could be a backup process or a virus scan.

Anyway, I put a wrapper around all of my Trace method calls with fixed number of retires with a 100
millisecond sleep between retries (the application is not time critical) and the problem appears to
have gone away.

The wrappers are a bunch of subroutines in a module so they are static and, I assume, thread safe
although I do not know how to confirm this.
 
The problem appears to be something reading the log file not writing to
it.

Oh, what I mean is:

1. Something (like the backup app) opened the file for read, and locked the
file to prevent other processes writing to it.
2. Your application called Trace.WriteLine (or other Trace methods) trying
to write the file. Because of the lock in #1, it throws an exception.

So we need to lock the file before others do, as earlier as possible.

But wrap the Trace call is not a bad idea.

Regards,

Jie Wang

Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business days is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
The trace log is defined in the app.config and is written to when the program first starts. In fact
the foreground task and background worker task had been written to the log for many hours when the
problem occurred. There are not calls to Trace.Close() in the application. Since another task was
able to lock a portion of the log file it appears that whatever lock Trace.Writeline puts on the
file is released when it finishes writing to the file..
 
I have check the code of the Trace related functions, once the log was
written to the first time, the file stream is kept open and should prevent
other process from writing to it.

So what if you don't run the backup process? Will the problem still be
there or not?

I'll recheck the code again to make sure.

Regards,

Jie Wang

Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business days is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
I am able to open the trace log in Notepad while the application is running so there definitely is
not a lock on it which would prevent reading. I am not able to delete the trace log while the
application is running so it is locked against changes. It looks as if Trace puts a reader lock on
it which prevents writing or deleting but not a writer lock which would prevent reading. It
probably upgrades the lock to writer when it actually tries to write and then downgrades it to
reader.
 
I hit another problem with the Trace class.

I notice that some calls to Trace.Indent and Trace.Unindent did not seem to produce the expected
results

I had created a module with wrappers for all of the trace methods and I changed the ones for
Trace.Indent and Trace.Unindent to:

Public Sub TraceIndent()
Trace.Indent()
Trace.WriteLine("Indent")
End Sub


Public Sub TraceUnindent()
Trace.Unindent()
Trace.WriteLine("Unindent")
End Sub

I then ran the application with full tracing and saw formatting like <comments added afterwards>:

20090720 23:17:27.750: btnStop_Click Tracing Started
Indent
20090720 23:17:27.750: StopSlideShow Tracing Started
Indent
20090720 23:17:27.750: ShutDownBackgroundTask Tracing Started
Indent
20090720 23:17:27.765: Showing ballon tip
20090720 23:17:27.781: Dispose Tracing Started
Indent
20090720 23:17:28.906: MemoryInUse Tracing Started
Indent <****this indent went the wrong way****>
20090720 23:17:28.921: Memory in use: 181878784, Peak Memory in use: 227233792
Unindent
20090720 23:17:28.937: MemoryInUse Tracing Ended
20090720 23:17:28.937: Starting Memory: 181878784, Current Memory: 181878784, Maximum Memory:
181878784
Unindent
20090720 23:17:28.953: CBackgroundWorker_DoWork Tracing Ended
20090720 23:17:38.796: Disposing of BackgroundWorker class
20090720 23:17:38.796: Disposed of BackgroundWorker class
Unindent <****This unindent went the wrong way****>
20090720 23:17:38.796: Dispose Tracing Ended
20090720 23:17:38.812: Hiding ballon tip
Unindent
20090720 23:17:38.843: ShutDownBackgroundTask Tracing Ended
Unindent
20090720 23:17:38.843: StopSlideShow Tracing Ended
Unindent
20090720 23:17:38.859: btnStop_Click Tracing Ended

The above is from the Output window in VS 2005 using the default trace writer.

I then ran the release version with a trace listener defined in app.config:
<trace useGlobalLock="false" autoflush="true" indentsize="3">
<listeners>
<add name="traceListener" type="System.Diagnostics.TextWriterTraceListener"
initializeData="Application_Trace.log" />
<remove name="Default" />
</listeners>

The results included the same indent errors:
20090721 00:34:59.984: btnStop_Click Tracing Started
Indent
20090721 00:34:59.984: StopSlideShow Tracing Started
Indent
20090721 00:34:59.984: ShutDownBackgroundTask Tracing Started
Indent
20090721 00:34:59.984: Showing ballon tip
20090721 00:34:59.984: Dispose Tracing Started
Indent
20090721 00:35:00.906: MemoryInUse Tracing Started
Indent
20090721 00:35:00.906: Memory in use: 203644928, Peak Memory in use: 237846528
Unindent
20090721 00:35:00.906: MemoryInUse Tracing Ended
20090721 00:35:00.906: Starting Memory: 192491520, Current Memory: 203644928, Maximum Memory:
203644928
Unindent
20090721 00:35:00.906: CBackgroundWorker_DoWork Tracing Ended
20090721 00:35:10.984: Disposing of BackgroundWorker class
20090721 00:35:10.984: Disposed of BackgroundWorker class
Unindent
20090721 00:35:10.984: Dispose Tracing Ended
20090721 00:35:10.984: Hiding ballon tip
Unindent
20090721 00:35:11.015: ShutDownBackgroundTask Tracing Ended
Unindent
20090721 00:35:11.015: StopSlideShow Tracing Ended
Unindent
20090721 00:35:11.015: btnStop_Click Tracing Ended

What could be causing the Trace.Indent() and Trace.Unindent() to reverse direction?
 
so there definitely is not a lock on it which would prevent reading.

Yes, I agree. The lock only prevents other processes from writing to it.
It probably upgrades the lock to writer when it actually tries to write
and then downgrades it to reader.
Click to expand...

This is not true. The lock mode is defined on the creation/opening of the
file only.

If you take a look at how the TextWriterTraceListener creates/opens the log
file, you'll see it works like this:

1. Call the internal method EnsureWriter.
2. EnsureWriter will create a new StreamWriter
3. The StreamWriter will create a new FileStream with FileShare.Read
parameter. Which means subsequent opening of this file can only be used to
read the file, not write.

It seems to me that you are very interested in how everything works in
.NET. If that is true, I strongly recommend you get the free .NET Reflector
tool. This tool enables you to easily view, navigate, and search through,
the class hierarchies of .NET assemblies, even if you don't have the code
for them. With it, you can decompile and analyze .NET assemblies in C#,
Visual Basic, and IL. So you no longer need to guess how it works, instead,
you see how it works by exploring the code. :)

Thanks,

Jie Wang

Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business days is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi,

Since this is a separate topic from the original post in this thread, could
you please open a new post for this question?

Thank you for understanding the newsgroup rules. :)

Regards,

Jie Wang

Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business days is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
3. The StreamWriter will create a new FileStream with FileShare.Read
parameter. Which means subsequent opening of this file can only be used to
read the file, not write.
Click to expand...

Unfortunately, it appears that an unmanaged process can lock the trace file in a way that the trace
writer can't write to the file and throws an error.
It seems to me that you are very interested in how everything works in
NET. If that is true, I strongly recommend you get the free .NET Reflector
Click to expand...

I have that but it is only good for looking at code after the fact. What I really need is a debug
build of the .Net assembles -- with the no trace into code attribute removed -- and the associated
source so I can see the state of the process at the time a low level error was thrown the way I
could in C/C++. Is that available?
 
I noticed that some calls to Trace.Indent and Trace.Unindent did not seem to produce the expected
results

I had created a module with wrappers for all of the trace methods and I changed the ones for
Trace.Indent and Trace.Unindent to:

Public Sub TraceIndent()
Trace.Indent()
Trace.WriteLine("Indent")
End Sub


Public Sub TraceUnindent()
Trace.Unindent()
Trace.WriteLine("Unindent")
End Sub

I then ran the application with full tracing and saw formatting like <comments added afterwards>:

20090720 23:17:27.750: btnStop_Click Tracing Started
Indent
20090720 23:17:27.750: StopSlideShow Tracing Started
Indent
20090720 23:17:27.750: ShutDownBackgroundTask Tracing Started
Indent
20090720 23:17:27.765: Showing ballon tip
20090720 23:17:27.781: Dispose Tracing Started
Indent
20090720 23:17:28.906: MemoryInUse Tracing Started
Indent <****this indent went the wrong way****>
20090720 23:17:28.921: Memory in use: 181878784, Peak Memory in use: 227233792
Unindent
20090720 23:17:28.937: MemoryInUse Tracing Ended
20090720 23:17:28.937: Starting Memory: 181878784, Current Memory: 181878784, Maximum Memory:
181878784
Unindent
20090720 23:17:28.953: CBackgroundWorker_DoWork Tracing Ended
20090720 23:17:38.796: Disposing of BackgroundWorker class
20090720 23:17:38.796: Disposed of BackgroundWorker class
Unindent <****This unindent went the wrong way****>
20090720 23:17:38.796: Dispose Tracing Ended
20090720 23:17:38.812: Hiding ballon tip
Unindent
20090720 23:17:38.843: ShutDownBackgroundTask Tracing Ended
Unindent
20090720 23:17:38.843: StopSlideShow Tracing Ended
Unindent
20090720 23:17:38.859: btnStop_Click Tracing Ended

The above is from the Output window in VS 2005 using the default trace writer.

I then ran the release version with a trace listener defined in app.config:
<trace useGlobalLock="false" autoflush="true" indentsize="3">
<listeners>
<add name="traceListener" type="System.Diagnostics.TextWriterTraceListener"
initializeData="Application_Trace.log" />
<remove name="Default" />
</listeners>

The results included the same indent errors:
20090721 00:34:59.984: btnStop_Click Tracing Started
Indent
20090721 00:34:59.984: StopSlideShow Tracing Started
Indent
20090721 00:34:59.984: ShutDownBackgroundTask Tracing Started
Indent
20090721 00:34:59.984: Showing ballon tip
20090721 00:34:59.984: Dispose Tracing Started
Indent
20090721 00:35:00.906: MemoryInUse Tracing Started
Indent
20090721 00:35:00.906: Memory in use: 203644928, Peak Memory in use: 237846528
Unindent
20090721 00:35:00.906: MemoryInUse Tracing Ended
20090721 00:35:00.906: Starting Memory: 192491520, Current Memory: 203644928, Maximum Memory:
203644928
Unindent
20090721 00:35:00.906: CBackgroundWorker_DoWork Tracing Ended
20090721 00:35:10.984: Disposing of BackgroundWorker class
20090721 00:35:10.984: Disposed of BackgroundWorker class
Unindent
20090721 00:35:10.984: Dispose Tracing Ended
20090721 00:35:10.984: Hiding ballon tip
Unindent
20090721 00:35:11.015: ShutDownBackgroundTask Tracing Ended
Unindent
20090721 00:35:11.015: StopSlideShow Tracing Ended
Unindent
20090721 00:35:11.015: btnStop_Click Tracing Ended

What could be causing the Trace.Indent() and Trace.Unindent() to reverse direction?
 
Since this is a separate topic from the original post in this thread, could
you please open a new post for this question?

Thank you for understanding the newsgroup rules. :)
Click to expand...

No problem -- I thought the topic was close enough to the original to avoid a new thread.

I have started a new thread.
 
Is that available?

Well, not sure if this article is what you're looking for:
Configuring Visual Studio to Debug .NET Framework Source Code (by Shawn
Burke)
http://blogs.msdn.com/sburke/archive/2008/01/16/configuring-visual-studio-to
-debug-net-framework-source-code.aspx

It requires Visual Studio 2008 though. But since the Trace related code are
located in the .NET Framework 2.0 assemblies, it is the same debugging
these code from within VS 2008.

Regards,

Jie Wang

Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business days is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Thanks for the reference. I will have VS2008 available a little after I get Windows Server 2008 R2
RTM.
 
Back
Top