Distroying data ...

I got my laptop replaced with new one since old one died within warranty period.
I had to delete the data from old hard drive and was aware that just formatting hard drive is not enough.
So after short research I bumped into chiper
Here is another link

I hope that will be good enough.

installing services without installutil ...

Apparently you can install services using dos prompt with following lines:

sc start ServiceName 
sc query ServiceName
sc stopServiceName

Server Application Unavailable ...

Problem when IIS 6 handles more than .net framework within same pool:

Solution Link

there was an error deserializing the object of the type contains invalid utf8 bytes

All of suden error emerged.

Links to possible solutions:

• Encosia

Substituting Carriage Returns in text areas

  

 Here is a link

  .replace(/\r?\n/g, "-break tag-\n")
  

System.Array.IndexOf to check if item exists without looping

public static string someMethod(parameterList ....., string[] filter)
{

foreach (DataRow item in dt.Rows)
{
if (System.Array.IndexOf(filter, item["itemName"].ToString()) > -1)
collection.Add(item);
}

return collection;
}

Cloning objects in js

I want to note that the .clone() method in jQuery only clones DOM elements - in order to clone JavaScript objects you would do:

// Shallow copy
var newObject = jQuery.extend({}, oldObject);

// Deep copy
var newObject = jQuery.extend(true, {}, oldObject);

More information can be found in the jQuery documentation.

I also want to note that the deep copy is actually much smarter than what is shown above - it's able to avoid many traps (trying to deep extend a DOM element, for example). It's used frequently in jQuery core and in plugins to great effect.

Link

There are too many people accessing the web site at this time...

IIS server refuse to serve request complaining that there are too many users ??

Possible solution Link

Script Manager Timeout ....

Sys.WebForms.PageRequestManagerTimeoutException: The server request timed out.

Solution link

Referenced assembly 'filename' is a localized satellite assembly (why it's not wise to ignore warning al1056)

Couple of hours lost due to seemingly innocent assembly entry ....

Why not wise to ignore 1056 Warning

Thread aboration on asp.net 2 ??

I run into problem with thread being aborted while uploading big files.
It turned out that if you modify any file domain reload is triggered that shuts down all threads.

More about it at this link


Evan Hoff [14/May/08 03:49 PM]
I'm not sure if this is the cause for CC.NET, but I've seen this same behavior in other 2.0 ASP.NET apps.

Here's the skinny:

In 2.0, ASP.NET changed so that any file changes (above and beyond web.config, global.asax, and /bin) will trigger an AppDomain reload.

During the reload, any thread which does not cleanly shut down within a specified timeout period will get aborted.

Reading your description above, I would guess you have several ASP.NET threads working on sockets. A filesystem change is triggering an AppDomain refresh and those threads aren't restarting within the timeframe expected by ASP.NET. As a result, the threads get aborted (causing the logs you are seeing). When the threads are aborted, your socket code doesn't restart, and your client receives a message about the server being too busy.

Or at least that's a theory you can try exploring. You can google the behavior change to read about it, but there's not a way to turn the behavior off (unfortunately).

Evan
[ Show » ]
Evan Hoff [14/May/08 03:49 PM] I'm not sure if this is the cause for CC.NET, but I've seen this same behavior in other 2.0 ASP.NET apps. Here's the skinny: In 2.0, ASP.NET changed so that any file changes (above and beyond web.config, global.asax, and /bin) will trigger an AppDomain reload. During the reload, any thread which does not cleanly shut down within a specified timeout period will get aborted. Reading your description above, I would guess you have several ASP.NET threads working on sockets. A filesystem change is triggering an AppDomain refresh and those threads aren't restarting within the timeframe expected by ASP.NET. As a result, the threads get aborted (causing the logs you are seeing). When the threads are aborted, your socket code doesn't restart, and your client receives a message about the server being too busy. Or at least that's a theory you can try exploring. You can google the behavior change to read about it, but there's not a way to turn the behavior off (unfortunately). Evan