Azulean's Note

.NET 4からCLRが新しくなったことで、基本的に.NET 3.5で作られたアプリのプラグイン、アドインを.NET 4で作ることはできません。
これを回避するためにはいくつかの方法が考えられます。

1. 対象アプリを.NET 4で動かす。
2. .NET 3.5でプラグイン、アドインを作り、.NET 4のアプリと通信する。
3. .NET 4で作ろうとしていた部分をネイティブ、COMで作って利用する。

まっとうな方法は２や３になるかと思いますが、.NET 4で無理矢理動かす方法を少し見てみましょう。

対象のアプリがhogehoge.exeだとすると、hogehoge.exe.configに以下のような記述を作ります。

<configuration>
   <startup useLegacyV2RuntimeActivationPolicy="true">
      <supportedRuntime version="v4.0"/>
   </startup>
</configuration>

参考URL：http://msdn.microsoft.com/ja-jp/library/jj152935(v=vs.110).aspx

これでたいていのアプリは.NET 4で動きます。
ただし、勝手に.NET 4で動かしているので無保証となる点にご留意いただき、利用者の自己責任で使うことを前提としてください。

なお、プラグイン・アドイン方式でセキュリティ問題をケアしている場合、CAS周りでNotSupportedExceptionが発生する可能性があります。
loadFromRemoteSourcesを使って脆弱にして動かすか、素直に２や３のアプローチを採るか、よく考えましょう。

わんくま同盟さんの質問掲示板の「C++.NetでWebClientのOpenReadについて」からのネタです。

今回の事例では、IE からは閲覧できて、WebClient では 503 エラーとなるものでした。
そこで、かんたんにコードを書いて実験することにします。

var wc = new WebClient();
using (var stream = wc.OpenRead(url))
{
}

※url はリクエストを投げる URL を示す文字列変数。

実際に質問に上がっていた URL で試すと、確かに 503 エラーを内包する Exception がスローされます。

ここで、Fiddler を使って差分を見ることにします。

まずは、上記のサンプルコードで試したときの通信内容です。

左側でセッションを選択すると右側に詳細が表示されますので上のビューの Headers を確認します。

非常にシンプルなリクエストになっていることがわかります。

次に IE で同じ URL にアクセスしてみて、多数のセッションが表示される中で、同じ URL に対するリクエストを選択して、同じように上のビューの Headers を確認します。

（掲載画像は関係ない部分をモザイクでつぶしています）

Accept, Accept-Encoding, Accept-Language, User-Agent などが増えていることがわかります。

1 つのヘッダーを追加するだけで足りるかもしれませんし、複数のヘッダーを追加しないとダメなケースもあるかもしれません。組み合わせを考えて試してみましょう。

今回の事例では User-Agent を何か指定すれば OK だったみたいですので、1 個ずつ試していけばそのうち解決しますね。

なお、この方法でわかるのは、その時点の相手のページがどのようなヘッダー、値を条件にしているかだけであり、将来的に変更される恐れがあります。これは相手の方針やメンテナンス・リニューアルなどの事情によるので不確か（リスク）です。

もしも、相手側がブラウザー以外の閲覧を好ましく思っていないのであれば、無理にやらない方がいいかと思います。