In .Net framework 2.0, AppDomain.AppendPrivatePath is marked as obsolete.
The deprecation is explained in Gotdotnet.com's break change web site
If you have read my blog about Domain Neutral Assemblies and Caching Binding Failures, you will see that we are toward more on a deterministic binding behavior where we can make sane sharing decision without fearing that our assumption will be broken. Deprecating AppDomain.AppendPrivatePath is a step toward that goal.
The deprecation actually causes quite some confusion. People asks if there is a replacement.
There is no replacement in .Net framework 2.0. There will be no future replacement, as far as I can see.
The only reason I see why AppDomain.AppendPrivatePath can be any useful, is that your application will download some random bits, put them in a sub folder under your application, then use AppDomain.AppendPrivatePath to make them available to the application.
The approach has at least two problems.
First, it makes assembly binding undeterministic. Depending on the assembly binding happens before the download or after, you may see a failure sometimes, or a success the other times. This is exactly the reason why we deprecate AppDomain.AppendPrivatePath in the first place --- WE WANT A DETERMINISTIC BINDING BEHAVIOR.
Second, on a typical Windows machine, applications are installed to C:\Program Files, which by default, only administrators can update. If you start download random bits into the application's sub directory, it practically means your application can only run under administrator account. This is exactly the reason why Windows is so vulnerable, because EVERY APPLICATION REQUIRES ADMINISTRATOR ACCOUNT TO RUN. If you are doing this, please stop, and use your creativity to find alternatives.
Of course, I can't really know all the cases how people use AppDomain.AppendPrivatePath. If you are using it, post your reason here. We can discuss the alternatives.
In any case, if you subscribe AssemblyResolve event, you can probably have your problem solved easily.