更新 (2012 年 6 月 20 日): 最善の解決策は、プロジェクトが拡張メソッドのサポートをロールバックすることです。ImageResizer 3.2.2 は拡張メソッドを提供しなくなりますが、新しいアルファ API に対して既にコーディングしているユーザーの破損を最小限に抑えるために、一部の機能が ResizeSettings および Instructions クラスで複製されます。
ImageResizer V4 は .NET 3.5 を必要とする可能性が高く、欠落している機能を再導入します。
更新:この catch-22 に対する解決策がある場合は、代わりにこの質問を参照してください。
問題についてお詫び申し上げます。私はまだデータを収集して長期的な解決策を見つけようとしていますが、これは私がこれまでに持っているものです:
回避策 A:
ソリューション エクスプローラーで、プロジェクトの References フォルダーを展開し、ImageResizer を選択して、[プロパティ] に移動します。Aliases フィールドを「global」から「ir」に変更します。
回避策 B:
.NET 2.0 を使用するようにプロジェクトを設定し、保存してから、.NET 3.5 または .NET 4 を使用するように戻します。
回避策 C:
System.Core 参照を手動で削除し、正しいものを追加し直します。(通常の原因は、3.5 プロジェクトで System.Core 3.0 参照を使用してアップグレードされたプロジェクトです)。ASP.NET では、これを web.config で行うことができます。
回避策 D:
3.2.0 に戻しますが、C# を使用している場合のみです。
なぜこれが起こっているのか
VisualStudio/MSBuild は、コンパイル中にプロジェクト内の の複数の定義を検出しますが、System.Core で定義されSystem.Runtime.CompilerServices.ExtensionAttribute
たコピーを選択する代わりに、コンパイラはImageResizer.dll で定義されたアセンブリ ローカル コピーを使用することを決定します。次に、他のアセンブリが到達できないため、不平を言います。イナン。public
internal
何が起こるべきか
Microsoftは過去にこの手法を問題なく数回使用しており、広く文書化されています。コンパイラは、プロジェクト全体で使用するためにパブリック インスタンスを選択することになっていますが、代わりに「内部」コピーを選択しています。そして、これは多くの開発者に影響を与えていません。そして、新しいプロジェクトでそれを再現できるのはごくわずかです。
パブリック vs. 内部
V2.3.0 では、ExtensionAttribute をpublic
ではなくとして定義しましたinternal
。これにより、VB プロジェクトではコンパイル タイマー エラーが発生しましたが、C# プロジェクトでは発生しませんでした。マークが付いた 2.3.1 をすぐにリリースしましたがinternal
、代わりに C# プロジェクトで問題が発生しています。ここでキャッチ22。
それは他の人のために働く...そしてマイクロソフト!なんでわたし?
http://www.danielmoth.com/Blog/Using-Extension-Methods-In-Fx-20-Projects.aspx
http://www.codethinked.com/using-extension-methods-in-net-20
http://kohari.org/2008/04/04/extension-methods-in-net-20/
.NET 2.0 で拡張メソッドを使用していますか?
「ハック」はMSDN マガジンでも取り上げられました。
どのようにお手伝いできるか
これを完全に理解するには、さらにデータが必要です。この問題が発生している場合は、プロジェクトの .zip ファイルを に電子メールで送信し、support@imageresizing.net
VisualStudio/.NET のバージョン番号を含めてください ([Visual Studio]、[ヘルプ]、[バージョン情報] に移動し、[] をクリックCopy Info
して、電子メールに貼り付けます)。郵便物)。
うまくいけば、問題を引き起こす正確な状況を見つけることができます.
更新-アセンブリの複数のバージョンを作成することが唯一の解決策であることを示唆するこの記事を見つけました。しかし、Microsoft はそうしませんでした。私は何が欠けていますか?また、NuGet は 2.0 と 3.5 のバージョン管理をサポートしていないため、単一アセンブリのソリューションが見つからない限り、2.0 のサポートを取りやめる必要があるかもしれません。