Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent by (output started at /home3/intimida/public_html/index.php:7) in /home3/intimida/public_html/wp-content/plugins/si-captcha-for-wordpress/si-captcha.php on line 431

Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /home3/intimida/public_html/index.php:7) in /home3/intimida/public_html/wp-content/plugins/si-captcha-for-wordpress/si-captcha.php on line 431
March « 2006 « Intimidating MONKEY

Archive for March, 2006

Copy via XmlSerializer

For God’s sake, don’t ever write this (at least not again). Its such a trivial piece of code that I never bother librarifying it, and yet every time I write it I leave out the reset of the stream position. But, what do you expect… I’M A MONKEY!!!

public static Object XmlSerializationCopy(Object pvValue)
{
  if (pvValue == null) return null;
  XmlSerializer ser = new   XmlSerializer(pvValue.GetType());
  // most are probably small.
  MemoryStream serStream = new MemoryStream(512);
  using(serStream)
  {
    ser.Serialize(serStream, pvValue);
    serStream.Position = 0;
    return ser.Deserialize(serStream);
  }
}

File.GetLastWriteTime vs. File on Network (ding, ding, ding)

So, I was wondering why file size (FileInfo.Length) seemed to be more accurate indication of a file modification than File.GetLastWriteTime. I was aware of the fact that the time updated on closing of the stream doing the writing to the file in question, and was willing to accept that. The question was where the heck was this called out…

Here is where it is called out.

Specifically:


When writing to a file, the last write time is not fully updated until all handles used for writing have been closed. Therefore, to ensure an accurate last write time, close the file handle immediately after writing to the file.

The part that is extra sucky is that this update of the Last Write Time does seem to take place on local files (not accessed via a remote UNC path), that is the Last Write Time does seem to change on local files even while the stream changing it is still open.

Use StreamWriter with XmlSerializer

Or something similar lest you risk paying the price for not paying attention.

The XmlSerializer can serialize an object to a stream, any stream. If the stream you are searializing your object to already contains data, and the length of that data is longer than the length of the data you are currently writing (your about-to-be serialized object) you get artifacts.

This is to say that if you open a stream without clearing it in some manner, and then write less data than what was already there…. You get your new data at the begining, and leftovers from what was there before at the end.

So in the case of serializing to a file, the easiest thing to do is use a StreamWriter and provide the path of the file to which you wish to write. The StreamWriter overwrites any existing file for you by default.

As per msdn documentation:
StreamWriter Constructor (String)
The path parameter can be a file name, including a file on a Universal Naming Convention (UNC) share. If the file exists, it is overwritten; otherwise, a new file is created.

Log4Net (Log4x?) File Locking

While I have yet to delve deeply into it, the default locking of log files by log4net hinders concurrent reads. The ExclusiveLock locking model (default) seems to keep the change determination based on last write, or file size to fail (or at least not work in a timely manner). I know there is a whole bunch of detail around this that I haven’t looked into, however setting the locking model to MinimalLock addressed the problem as I was seeing it (allowed concurrent reads to detect changes).

Sweet Mother of Bacon

Now that’s a sandwich.  If you’re gonna do it, you might as well do it right.

For God’s Sake, don’t Forget the Bacon

In today’s hectic world, it’s easy to forget about or just plain give up on tradition.

Enhance VS 2005 Refactoring Performance

Refactoring performance in Visual Studio 2005 (out of the box [w/ a web project in your solution]) is poor. This seems to be primarily due to the inclusion of web project related files in refactoring. This (for me) has rendered refactoring support unusable in many instances.

Luckily you can change this behavior.

Output Caching Web Service Data

Using the output cache is super fast, so it’s nice to use when performance is a concern. And performance is often a concern around Web Service interfaces, so it’d be nice to use it there.

The easiest way to do it globaly is to hook the PostRequestHandlerExecute event in the request processing pipeline and set your cache policy values there (conditionally if necessary). However there seems to be some requirement to set the CacheDuration property on the WebMethod attribute of the method being exported via the service. I’m not sure why this is, but presumably it’s doing something to provide appropriate ‘varyby’ handling for the request body based SOAP message.

IIS Max Connections (403.9)

So it looks as if IIS 6.0 (or IIS 6.0 on 64 bit) on Windows XP has a different value for /w3svc/MaxConnections than does IIS 5.1 (or at least IIS 5.1 on 32 bit).
IIS 6.0 Windows XP 64 bit /w3svc/MaxConnections = 40
IIS 5.1 Windows XP 32 bit /w3svc/MaxConnections = 10