<OutOfBrowserProjectToDebug>XXX</OutOfBrowserProjectToDebug>
to 
<OutOfBrowserProjectToDebug>YYY</OutOfBrowserProjectToDebug>

Now save it, and you’re good to go.

Usually *.csproj.user files should not be under source control.
So if you rename a silverlight project which a colleague of yours has set it to be ran out of browser on his computer, then he will get this error unless you share the same *.csproj.user on the source control (which is not a good idea).

I think a visual studio 2010 improvement is needed here, that describes the situation better. Something like: “Unable to determine the URL to the Xap file from web XXX. If the project was renamed, please rename it inside your *.csproj.user” file settings as well”

I had a colleague which was convinced he didn’t need pdbs to debug an .net app, because of the “Browse to find source” :) Anyone else want to take a bet with me on that?
In this post I want to clarify when to use this “Browse to find source” feature since the mdsn doc is missing, and sometimes is grayed out for no (apparent) reason.

If you experiment a little with process monitor, you’ll see that every time visual studio displays the “Browse to find source” page, it looks inside the pdb file corresponding to the top stacktrace instruction your are trying to step into.

For example in the image below, it looks into the pdb of the DateTime.Now (which is mscorlib.pdb), since I’m trying to step into DateTime.Now:

But what is it looking for there?
Well, if the pdb file is for a private build, then it includes information on where to find the source file from which it was built.
And that’s what visual studio is searching for inside the pdb.

For example I built the following simple library consisting of just one class:

    public class Class1
    {
        public static DateTime GetCurrentDateTime()
        {
            return DateTime.Now;
        }
    }

Class1.cs was located at: d:\ClassLibrary\Class1.cs

If you build this program and then look inside the pdb file that was generated for the build, using dia2dump, you’ll see, among other things, the Files section:

*** FILES

D:\ClassLibrary\Class1.cs

Suppose I reference the ClassLibrary1.dll which I built, in another simple console project called Console1 located at D:\Console1:

    class Program
    {
        static void Main(string[] args)
        {
            var currentDateTime = ClassLibrary1.Class1.GetCurrentDateTime();
        }
    }

If I build Console1I will have in D:\Console1\bin\debug a Console1.exe, Console1.pdb, and a ClassLibrary1.dll,
If I try to step into the ClassLibrary1.Class1.GetCurrentDateTime() above, the first thing visual studio will do, is look for the ClassLibrary1.pdb at: D:\Console1\bin\debug\ClassLibrary1.pdb, and then in a couple of other locations.

If it doesn’t find the pdb in any of those locations, then you’ll get a disabled (grayed out) “Browse to source”. Why? Because it’s impossible for the visual studio debugger to know which function goes into what class and at what line number having just an binary and the source code files from which it was built.
You’ll would never be able to do do source code level stepping inside the debugger if you have the source files but don’t have the pdb.
So the first step you do if you get “No source code available” is right click on the top call-stack instruction, choose “Symbol Load Information” and be sure you have a “Symbols loaded” message somewhere there. If you don’t see any “Symbols loaded”, then you should try placing the pdb at one of the locations which is listed there.

Now if visual studio finds the pdb file it might still be possible, using our above example, that the file ” D:\ClassLibrary\Class1.cs” which it finds in the pdb, is no longer there.
You either moved it at a another location, say C:\ClassLibrary, or it was built by someone else on another machine at D:\ClassLibrary\Class1.cs and you don’t even have that directory on your computer.
In those cases you get a nice browse to source file dialog:

If you cancel this accidentally (or intentionally) you will get a “Browse to source” enabled:

Why? Well because the pdb is OK, and contains source line information, just that the source files path inside pdb, are not at the right location and since you canceled “browse to source file”, visual studio has no idea where to look for the source files.
One more thing to look out for is that not all pdbs have source line number information: see for example this. Those are pdb’s which you cannot use for stepping into source code, since they don’t contain the necessary information.
In those cases, you’ll also get a grayed out “Browse to source”.
In that case, we’re out of luck my friend and the only available solution is to use Reflector Pro’s ability to debug and step into those assemblies from visual studio at runtime :(

Msdn documentation for IsolatedStorageFile.IncreaseQuotaTo states that:
To increase the quota, you must call this method from a user-initiated event, such as in an event handler for a button-click event. When you call the IncreaseQuotaTo method, the common language runtime in Silverlight presents a dialog box for the user to approve the request. If the user declines the request, this method returns false and the quota remains the same size.

Now that seems like half-baked documentation to me since it doesn’t accurately describe what a user-initiated event is, it only gives one example.
After much digging, I did find out what a user initiated event is. Seems that the msdn documentation specifies what a user initiated event in the section related to “events overview“, but there’s no link between documentation of IsolatedStorageFile.IncreaseQuotaTo and Events Overview.
So here goes the definition:

Silverlight user-initiated events include the mouse events (such as MouseLeftButtonDown), and the keyboard events (such as KeyDown). Events of controls that are based on such events (such as Click) are also considered user-initiated.

When Silverlight is in full-screen mode, some input events are deliberately limited for security reasons, although this can be mitigated for out-of-browser applications using elevated trust. For more information, see Full-Screen Support.

At first these limitations seemed draconian to me.
Thinking it more about it, I guess Microsoft didn’t want a user to have many tabs open in a browser and then poof: I call automatically IncreaseQuotaTo.
Since the IncreaseQuotaTo is a modal dialog, meaning you can’t navigate to other tabs from it, if the user is now on page google.com, and I show automatically IncreaseQuotaTo, the user might think that google.com is asking for more storage :)). This would be a security breach indeed.

Had they implemented this with a page level dialog, then that would have probably been more easily hacked (worked around). I can already start imagining drawing some evil forged “Silverlight needs to be updated” image over the IncreaseQuotaTo text, hence tricking the user in pressing Yes . Or maybe some other evil scenario.

I was curios though how exactly does silverlight know what a user initiated event is, but after digging through .net framework source code I’ve got to a dead end:

if ((browserService == null) || !browserService.InPrivateMode())
{
    //..
}
return false; //means that IncreaseQuota will fail
where browser.IsInPrivateMode is:

[SecuritySafeCritical]
public bool InPrivateMode()
{
    bool privateMode = false;
    return (NativeMethods.SUCCEEDED(UnsafeNativeMethods.DOM_InPrivateMode(this._browserServiceHandle, out privateMode)) && privateMode);
}

where DOM_InPrivateMode is in a DllImport["agcore"], which according to microsoft is confidential :(
So it looks like I won’t find out soon how they’re detecting user initiated events, although I’m guessing they have some centralized private method that detects clicks for example, and then probably sets a flag that this was indeed “a user initiated event”, and since you can’t forge clicks or keypresses using javascript and since you can’t call those private methods using reflection, it’s “safe”.

You are not alone :(
The most likely cause is that Microsoft has released some patches to the .net framework, and didn’t publish pdbs that you could use for stepping into .net framework source code.
So supposing that you are trying to debug DateTime.Now.
First look on where the pdb-file downloaded from Microsoft Symbol Server is located on your computer, by right clicking in the Call-Stack -> Symbol Load Information:

Now we’ll look inside this pdb file using dia2dump which is a tool that comes with visual studio at: c:\Program Files (x86)\Microsoft Visual Studio 10.0\DIA SDK\Samples\DIA2Dump\

It’s not compiled by default, so you’ll have to open it’s sln and compile it. Fortunately it’s just a small C++ proj, and compiles easily. (Just press compile).
After compiling you should see it at c:\Program Files (x86)\Microsoft Visual Studio 10.0\DIA SDK\Samples\DIA2Dump\Debug\.
To look inside a pdb file you just open a command prompt and write: dia2dump.exe xxx.pdb >xxx.txt . This will write the contents of the pdb inside a xxx.txt.

So if we run dia2dump on the mscorlib.pdb file which was downloaded we can see that it doesn’t contain any source files information or start /end addresses like the mscorlib.pdb you get from: http://referencesource.microsoft.com/netframework.aspx and it’s ~300 KB vs 10 MB.
Now I’m no pdb file contents expert, since the format of the pdb keeps changing and there’s no public specification according to microsoft (you can read more about it here: http://msdn.microsoft.com/en-us/library/x93ctkx8%28v=VS.80%29.aspx)
But the fact that there’s no addresses and source code mappings does ring a bell to me that the pdb is not one that we could use for .net framework source code stepping purposes.

So how do we make it work?
My first idea was of using that “Browse to source” option in visual studio 2010, and browse to .net framework source code you have downloaded manually from referencesource.microsoft.com. But after looking at the information inside the pdb, or rather the lack of it, it’s now clear why it’s always grayed out.

So one solution is to use Reflector Pro, which is commercial, and use it’s runtime debugging feature to step into microsoft .net framework source code.
This is not an ideal solution (especially because of the optimized code), and I just don’t understand why Microsoft doesn’t publish automatically source code according to their latest hotfixes/patches of the .net framework :(
I mean, I need to step into .net framework because I’m having problems today, not in two months when they decide to actually publish it. What am I supposed to do? Disable windows update so I don’t install any hotfixes? :(
This might be a second solution: Just have a virtual machine with visual studio installed, and a .net framework version which has .net framework source stepping support. Then disable any updates on that virtual machine and do your debugging there. (Really painfull, I know)

-If the property is a reference type, then go inside it and compare that too, property by property. (Basically deep object property comparison).
-If the property is IEnumerable, then compare properties of each element inside the IEnumerable.
-If the elements inside the IEnumerable are themselves IEnumerable then this could go on many levels deep, but this was not on my requirements.
-I also want the possibility to ignore certain properties in the comparison, such as property which is a delegate (like the Filter property of the PagedCollectionView framework class).
And of course I would need to know which properties were not equal, so I could show into my assertions.

Obviously this involves some heavy reflection code which I’m sure it would be fun to write if you had the time.
An alternative is to use a free library, with just one class, that does exactly this: http://comparenetobjects.codeplex.com/
Usage is very simple, and supports all kind of useful features which you can see below:

var compareObjects = new CompareObjects()
            {
                CompareChildren = true, //this turns deep compare one, otherwise it's shallow
                CompareFields = false,
                CompareReadOnly = true,
                ComparePrivateFields = false,
                ComparePrivateProperties = false,
                CompareProperties = true,
                MaxDifferences = 1,
                ElementsToIgnore = new List<string>() { "Filter" }
            };
                                                                            
            bool areEqual = compareObjects.Compare(objectA, objectB);
            Assert.IsTrue(areEqual, compareObjects.DifferencesString); //DifferencesString contains exactly what property and what value(s) was different

For Silverlight you do have to remove a couple of line of codes from it, related to DataTable comparison, which don’t exist in silverlight, but it’s easy and only takes a couple of minutes.

Happy Deep Object Comparisons :)

So what will you do when your client calls you and says he received an error message like the one below?
NullReferenceException
at ChaptersView.ChaptersTree_OnMouseMove
at ChaptersView.GetPreviousCommandButton

After I had a look today at the answer to this question, it became obvious:

Step 1)
In the place you now log or show exceptions to the user, you stop writing a normal stack trace using exception.ToString() or exception.StackTrace.
You should write a stacktrace that includes IL offsets using the code below:

...
catch (Exception exception)
{
            string errorDescription = string.Empty;
            try
            {
                StackTrace st = new System.Diagnostics.StackTrace(ex);
                string stackTrace = "";

                if (st != null)
                {
                    foreach (StackFrame frame in st.GetFrames())
                    {
                        stackTrace = "at " + frame.GetMethod().Module.Name + "." + frame.GetMethod().ReflectedType.Name +
                                     "." + frame.GetMethod().Name + "  (IL offset: 0x" +
                                     frame.GetILOffset().ToString("x") + ")\n" + stackTrace;
                    }
                }
                errorDescription = stackTrace;
            } catch //sometimes there are no stackframes, just use ex.ToString() in those cases
            {
                errorDescription = ex.ToString();
            }
            //do something with error description, like show it to the user or send it to your log server  
}

If we pass the exception that generated the stacktrace in our first example, it will look like:

NullReferenceException
at ChaptersView.ChaptersTree_OnMouseMove (IL offset: 0×44)
at ChaptersView.GetPreviousCommandButton (IL offset: 0×28)

Step 2: Client sends you an exception/log that includes IL offsets
You can use Reflector or IL Disassembler (which comes with visual studio) to find out the piece of code that generated the exception.
I prefer IL Disassembler because Reflector will only show you IL code from those IL offsets, and there’s a large chance you don’t read IL as well as you read C#.

So you have to perform the following steps:
1) Go to start menu and start IL Disassembler
2) Inside IL Disassembler go to File->Open and load the dll (not the XAP) where the exception was thrown. (e.g. …\Release\Client.dll)
3) Go to View->Show source lines
4) Now navigate to the last method that appears in the stacktrace and we look after the IL offset from the stacktrace.
In our example above this is ChaptersView.GetPreviousCommandButton and has offset 0×28

Inside IL Disassembler we will see a mix of C# code and corresponding IL code:

  IL_001c:  brtrue.s   IL_0029
//000193:             {
//000194:                 throw new NullReferenceException(“Test Exception”);
  IL_001e:  ldstr      "Test Exception"
  IL_0023:  newobj     instance void [mscorlib]System.Exception::.ctor(string)
  IL_0028:  throw
//000195:             }
//000196:
//000197:             var previousCommandButton =
 

As you can see, at IL_0028 there’s the instruction that caused the exception.
This is IL code, but because we’ve checked “View->Show source lines” we also get the corresponding C# code just a few lines above.

//000193: {
//000194: throw new NullReferenceException();

So, in this case the exception was thrown because I’ve thrown it explicitly in order to show how IL offsets and IL Disassembler can be used to get an alternative to stack trace line numbers in silverlight.

Also please don’t just put that piece of code in every catch block. Create a method like “string GetStackTraceFromException(Exception ex)”
Another good idea would be to have some centralized error service, on the server side. You would then send those exception descriptions automatically along with method parameter values logged with PostSharp, whenever an error happens.
So by the time the client calls you, you have fixed the problem and he’s impressed ;)

Happy Debugging.

I wouldn’t recommend the first option but for the simplest scenarios like: zip one file to one one compressed file.
If you need to create a zip archive that can contain multiple files & folders which are taken from the file-system or from in-memory content then I recommend the second option.
The only problem I had using option 2 is that documentation for sharpziplib is scarce, but persistent google searching does help.

So let’s take an example scenario and see how it’s done using SharpZipLib in Silverlight.
Suppose you have an in-memory xml, stored as a string, and the end result you want to achieve is an archive called test.zip which contains a single folder called Test.
Inside the folder you want to have the in-memory xml stored into an xml file called test.xml.
To see the end result easily we’ll write the archive to isolated storage.

So here goes the source code for the method that will do the creation of the archive:

        public byte[] GetCompressedByteArray(string content)
        {
            byte[] compressedResult;
            using (MemoryStream zippedMemoryStream = new MemoryStream())
            {
                using (ZipOutputStream zipOutputStream = new ZipOutputStream(zippedMemoryStream))
                {
                    // Highest compression rating
                    zipOutputStream.SetLevel(9);

                    byte[] buffer;

                    // The string to use as file content
                    using (MemoryStream file = new MemoryStream(Encoding.UTF8.GetBytes(content)))
                    {
                        buffer = new byte[file.Length];
                        file.Read(buffer, 0, buffer.Length);
                    }

                    // Write the data to the ZIP file            
                    ZipEntry entry = new ZipEntry("test/test.xml");
                    zipOutputStream.PutNextEntry(entry);
                    zipOutputStream.Write(buffer, 0, buffer.Length);

                    zipOutputStream.Finish();
                }

                compressedResult = zippedMemoryStream.ToArray();
            }

In the code above you can see how easily it is to create a virtual folder with a file in in a zip archive: ZipEntry entry = new ZipEntry(“test/test.xml”);.
Don’t be mislead though, although winrar and winzip will show you folders inside your zip archive, if you copy the archive to a mac/linux/android device you’ll still see only a file called “test/test.xml” since there the “/” doesn’t mean anything.
I haven’t had time to investigate this further but there’s some class ZipEntryFactory zef = new ZipEntryFactory().MakeDirectoryEntry(); which I think should be used for making directory entries.

So this GetCompressedByteArray method will return us a compressed byte array.
All we need to do now is to write it to isolated storage:

        public void WriteToIsolatedStorage(byte[] compressedBytes)
        {
            IsolatedStorageFile isoStore = IsolatedStorageFile.GetUserStoreForApplication();
            using (IsolatedStorageFileStream zipTemplateStream = new IsolatedStorageFileStream("test.zip", FileMode.OpenOrCreate, isoStore))
            using (BinaryWriter streamWriter = new BinaryWriter(zipTemplateStream))
            {
                streamWriter.Write(compressedBytes);
            }

        }

And write some test code:

          var xmlString =
@"<?xml version=""1.0"" encoding=""utf-8"" standalone=""no""?>
<book>
	<version>1</version>
	<language>english</language> 	
	<chapters>
       <chapter name=""chapter1"" />
       <chapter name=""chapter2"" >
    </chapters>
</book>";
            byte[] compressedXmlStringBytes = GetCompressedByteArray(xmlString);
            WriteToIsolatedStorage(compressedXmlStringBytes);

After running it, you should get a “test.zip” inside the isolated storage.
On Windows 7 the isolated storage is located at: c:\Users\username\AppData\LocalLow\Microsoft\Silverlight\.
Just search for a file named “test.zip”, inside the folders and subfolders at that location.

If you want to see the full actual, without searching for it, the only way is to use the visual studio debugger:
Put a breakpoint on using (BinaryWriter streamWriter = new BinaryWriter(zipTemplateStream)), then move the mouse over zipTemplateStream, non-public members, and look at m_FullPath, like in the image below:
See Image

Also see here the attached VS2010 solution.

For the unzipping part you can take a look at the Unpack a zip with full control over the operation

Happy zipping :)

Using it for quite some time, I don’t really read it’s help anymore, but accidentally I’ve looked into it recently and was pleasantly surprised to see  that it now supports injecting debug messages into it’s event stream using an API and there’s even a managed wrapper for this (read diagnostic tracing process monitor)
A few of my colleagues asked me for scenarios in which to use it, so I’ll describe a few from my personal experience.

I mainly used it for debugging bugs that involve the file system or registry in some way.

Example 1:

I was maintaining a real-time legacy system that was doing a series of processing on xml files. Each processing involved creating  a temporary file in a certain directory. The problem was that sometimes certain files were lost.

Code looked similar to this:

string filename = string.Format(“{0}-{1}.xml”,
DateTime.Now.ToString(“yyyy-MM-dd-HH-mm”), Environment.TickCount);
filename = Path.Combine(dir, filename);
// synchronize access to file
lock (m_cs.MainAppDomain)
{
	using (StreamWriter sw = File.CreateText(filename))
	{
		sw.Write(content);
		sw.Close();
	}
}

Can you spot the problem? I stepped through the code many times, and I wasn’t able to reproduce the bug.

After using Process Monitor I was able to spot it: the unique filename made from the number of miliseconds since the system has started is not really unique. In some cases more than 1 file/milisecond can be created, in which case the second file overwrites the first one.

Example 2:

I had to do production debugging on a system accessible via Remote Desktop (via a special Remote Desktop infrastructure), but located behind an inaccessible subnet. So remote debugging was out of the question. It wouldn’t have helped anyway for this particular bug.

I had a piece of code that was installing an X.509 Certificate which was working under one Administrator user, but wasn’t working under another Administrator user.

The error I was receiving was “File not found exception” (the filename not being found was an empty string). Exception stacktrace was ending in an internal CAPICOM library (windows library).

At first I thought it was a security issue, so I enabled Windows security auditing but no security events were being logged, so this wasn’t a security issue.

So what I did was: take the output of process monitor when code was running fine and take the output of process monitor when the code was not working.

I compared these two and it revealed that, when it was not working, code didn’t found an AppData registry values in
HKEY_USERS\S-1-5-21-218976661-61539242-33973980-1010\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\

AppData normally points to the Application Data environment folder and should have been there. Seems somebody corrupted the registry, because lots of other shell folder values were missing too and is used by CAPICOM to locate the physical certificate store when installing a new certificate.

So I manually re-created the missing values by looking at a working system, and everything worked.

So registry corruption is another good scenario where you can use it.

The components performed their jobs in the isolated environment an AppDomain provides and, when their job finished, they were unloaded using AppDomain.Unload.

The problem was that memory didn’t seem to be recollected when I was doing AppDomain.Unload so I turned to read again sections from Jeffrey Richter’s, CLR via C# 3rd edition, since that was the book from which I’ve learned about Application Domains and Garbage Collection. It stated clearly “The CLR forces a garbage collection to occur, reclaiming the memory used by any objects that were created by the now unloaded AppDomain. The Finalize methods for these objects are called, giving the objects a chance to clean themselves up properly.”

After some mail exchange with Jeffrey, which you can read, along with an example here, he suggested:

A better test would be to look at some object addresses in the debugger and see if compaction actually occurs. If it does (and I suspect it does), then the collection count is just not being updated correctly.

To keep it short I had a small program that did this:

1) Create and application domain,

2) Create some object instances inside so It has some allocated memory.

2) Call AppDomain.Unload

3) Perform an explicit GC.Collect() call.

I took Visual Studio and loaded Son of Strike into it and it revealed this:

Before AppDomain.Unload:

!EEHeap -gc
Number of GC Heaps: 1
generation 0 starts at 0x0180b1f0
generation 1 starts at 0x017d100c
generation 2 starts at 0x017d1000
ephemeral segment allocation context: none
segment    begin allocated     size
017d0000 017d1000  01811ff4 0x00040ff4(266228)
Large object heap starts at 0x027d1000
segment    begin allocated     size
027d0000 027d1000  02f75470 0x007a4470(8012912)
Total Size  0x7e5464(8279140)
——————————
GC Heap Size  0x7e5464(8279140)

After AppDomain.Unload (same addresses, no heap compaction was done)

!EEHeap -gc
Number of GC Heaps: 1
generation 0 starts at 0x0180b1f0
generation 1 starts at 0x017d100c
generation 2 starts at 0x017d1000
ephemeral segment allocation context: none
segment    begin allocated     size
017d0000 017d1000  01811ff4 0x00040ff4(266228)
Large object heap starts at 0x027d1000
segment    begin allocated     size
027d0000 027d1000  02f75470 0x007a4470(8012912)
Total Size  0x7e5464(8279140)
——————————
GC Heap Size  0x7e5464(8279140)

After GC.Collect(), addresses differ indicating heap compaction was done.

!EEHeap -gc
Number of GC Heaps: 1
generation 0 starts at 0×01811234
generation 1 starts at 0x0180b1f0
generation 2 starts at 0x017d1000
ephemeral segment allocation context: none
segment    begin allocated     size
017d0000 017d1000  01811ff4 0x00040ff4(266228)
Large object heap starts at 0x027d1000
segment    begin allocated     size
027d0000 027d1000  027d3240 0×00002240(8768)
Total Size   0×43234(274996)
——————————
GC Heap Size   0×43234(274996)

So to conclusion is that heap compaction is not done and the only thing you can really be sure during an AppDomain unload is that objects will get to be marked as unreachable.

Memory for those objects will be reclaimed whenever the next garbage collection happens, so, in this case it’s not a good idea to call for GC.Collect() yourself.

You can imagine an Application Domain as a logical container in which you can load assemblies. An application domain lives inside a process and you can have many application domains living at the same time inside the same process (see figure below).

In the above image we have C# SampleConsoleApplication executable. When you start the executable a SampleConsoleApplication process is created, then the CLR creates a default AppDomain for your code.  In this case, the default domain is the SampleConsoleApplication domain and, as you can see, the CLR also loaded other assemblies referenced by SampleConsoleApplication into this default domain (like System.dll).

Next, let’s say you want your SampleConsoleApplication to use classes from another library, ClassLibrary1. Normally you would just reference ClassLibrary1. But there are scenarios where you don’t want to do that. A few scenarios I can think is:

1. You have an application that supports plug-ins (e.g. MMC, SAP, etc). Presume  ClassLibrary1 is a plug-in written by a 3rd Party. You have to isolate ClassLibrary1 from a security and reliability point of view. From a security point of view you don’t want ClassLibrary1 to access your directly code (MMC/SAP code in this case) because it might be malicious. From reliability point of view, even if ClassLibrary1 is not malicious it still might have bugs in implementation that you couldn’t just ignore using a try catch. For example it could have a memory leak and, if you were referencing it directly, it would cause your memory usage to keep growing and never be recollected even after you don’t use ClassLibrary1 classes anymore.
2. Other examples: You are writing a web-server like IIS. Unintentionally somebody could have bugs in his ASP.NET web-site that could crash your web server.  You want complete isolation here, but without creating one process for each web-site. Why? Processes are very expensive to create form both performance and initial memory footprint point of view. Your web-server would be slow and would accommodate a lower number of web-sites as opposed to if you were using an ApplicationDomain for each web-site.
3. You are writing a real-time system that processes data received from instruments (e.g. various blood analyzers). Some of the processing steps are done by various libraries written by various companies and could fail because a type of instrument is malfunctioning, a bug in the code, etc. You could use an application domain to isolate 3rd party processing failures, and simply unload problematic processings when they happen, leaving the core of the system to continue functioning and process data.

I guess, you see the pattern by now. Application Domains can help you isolate code from a security, resource usage, exceptions point of view without creating new processes. They can also be unloaded when you either finish using them or code inside them is causing problems.

To provide this level of isolation, you are not allowed to use types from an AppDomain in another AppDomain directly. Instead when you need to use a class from another AppDomain you can use either remoting or WCF. (See http://stackoverflow.com/questions/1294494/is-net-remoting-really-deprecated)

If you’re stuck with maintaining a legacy system that uses remoting keep on reading.

If you’re using remoting, there are two important ways by which you can send one object from one AppDomain to another.

1. Marshaling by Value: You have a class that is marked as serializable. When you create an instance of that class and pass it to another domain, as a parameter in a function call for example, you are actually serializing/deserializing it. This is Marshaling by Value.
2. Marshaling by Reference: In some cases it doesn’t make sense to serialize a class and send it to another AppDomain serialized, because the class contains members that are specific to a single application domain. For example: Suppose you have a class member that is a reference to socket, a filehandle, a db connection. Once serialized, those references would be invalid in the receiving AppDomain. In this case you have your class inheriting from MarshalByRefObject and when you instantiate it in another AppDomain a TransparentProxy is created for it. For example you have a DataAccess class that contains a method InsertPerson(string name) that opens a db connection and inserts a person in a database. When you instantiate it in another AppDomain a class identical to your class (having same name, same public methods, same public properties) is created instead. This is called a TransparentProxy. When you call InsertPerson on it, it will make a remote call to an instance of type DataAccess living in the first AppDomain, which will perform the operation and send the result back. (it’s enough if you imagine the remote call as web-service call).

I hope this abstraction suffices your needs.