サードパーティがバグを修正しない場合の対処
広く使用されている製品の非常に深刻なパフォーマンスのバグについて、私が考えていることを第三者に報告しました。古いバージョンは問題なく動作しました。新しいバージョンは、私が取るに足らない状況を除いて、実際には使用できません。古いバージョンのパフォーマンスと新しいバージョンのパフォーマンスを比較するテストケースを提供しました。
応答なしで数週間待った後、私は最終的にこれを言われました：
この問題をご報告いただきありがとうございます。現在、幅広いお客様に影響を与えている問題を優先しているため、この問題をすぐに調査できない場合があります。この問題はお客様にとって重要であるため、監視を続けます。
開発環境への最近のアップグレードのため、このライブラリの古いバージョンを引き続き使用することは非常に困難です。このライブラリは多くの場所で使用されているため、完全に取り除いて置き換えるのは困難です。さらに、他の製品には多くのオプションがありません。
私の懸念は次のとおりです。
新しいライブラリを正しく使用する方法を理解していますか？私の再現可能なテストケースは実際に正しいですか、それとも何か不足していますか？
このベンダーに問題をさらに検討するように説得するにはどうすればよいですか？
解決策が得られない場合、どのような選択肢がありますか？製品の（本当に古い）以前のバージョンに戻しますか？このライブラリを別の製品に置き換えて、大量の戦いで強化されたコードを書き換えてしまいますか？
したがって、＃1に対する私の考えは、テストケースのコードレビューを取得することです。私は現在、職場の上級ソフトウェアエンジニアです。私は他の2人のエンジニアを監督していますが、実際にレビューできるのは1人だけです。彼は私のテストケースを実行し、それに関する問題を報告していないと思います。両者は異なる結論に達しましたが、パフォーマンスの問題の原因を理解しようと努めてきました。ここにテストハーネスを投稿してコードレビューを依頼することを考えましたが、それが適切なことかどうかはわかりません。
また、このベンダーに関する他の2つのバグレポートがあることにも注意してください。また、再現可能なテストケースを使用します。彼らは同様の不十分な扱いを受けているようですが、優先事項ではないと明確に述べたのはこれだけでした。
だから私はガイダンスを探しています。良いオプションはそのままです。
これをより具体的にするように要請されたので、問題自体を説明しようと思います...
最近まで、Visual Studio 2008とReportViewer 2008を使用していました。しばらくの間、環境のアップグレードが計画されていました。 ReportViewerに関連のない（まだ修正されていない）バグの結果として、バグが修正されることを期待して、アップグレードを続行することを決定しました。それはしませんでした。
ReportViewer 2008を維持しました。そこではすべて正常に動作します。ただし、新しいバージョンのVisual Studioでは、2008のレポートを設計できません。アップグレードするか、未加工のxmlでレポートを開発する必要があります。
したがって、ReportViewerとすべてのRDLCファイルをアップグレードするだけで、すべてが機能するはずです。ただし、最も単純なレポートでさえ、実行に2倍の時間がかかりました。その他の比較的短いレポートでは、10倍の時間がかかりました。より大きなレポート（ただし、私が妥当と考えるものはまだ）は、ReportViewer 2008の30秒から、試したすべての新しいバージョンで「終了しない」までになりました。 2012、2015、2017で試してみましたが、2010でも同じ問題があると思います。十分な大きさのレポートが終わらないので、それは単なるパフォーマンスのバグではないと思います。また、エラーも発生しないようです。
他の人々も同様の問題を抱えており、レポートの実行に10倍の時間がかかります。提案には、CASセキュリティ設定の変更または動的グループ化の静的への変更が含まれます。問題を修正するCAS設定が見つかりませんでした。グループ化に関しては、私のテストケースはRowNumberをグループとして使用していました。グループ名を取るため、動的と見なされるかどうかはわかりません。私のレポートの実際のデータに関しては、他のすべては静的でした。
問題を特定するために、私はプロファイラーを実行し、新しいReportViewerバージョンが大量のバイナリシリアル化を行うことを確認しました。私の他のプログラマーは、vb式が問題を引き起こしていると考えているようですが、彼がこれを考える理由を説明していません。そうではないことは言うまでもありませんが、その理由を知る必要があります。
私のテストハーネスは、ReportViewer 2008、2012、2015、2017のすべての組み合わせを、3.5、4.0、4.5、4.5.1、4.5.2、4.6、4.6.1のすべての.NETバージョンに対して実行するように開発されました。 ReportViewer 2008は、2008バージョンのRDLCを使用しました。それ以外はすべて新しいバージョンを使用しました。
テストハーネスは、問題が.NETバージョンではなくReportViewerバージョンに接続されていることを示しました。ただし、他のプログラマーは、問題は.NETだと考え続けています。
私が見ているように、計量のオプションは次のとおりです。
ベンダーが最終的にこれを見て、問題があることを確認し、修正することを願っています。短所は、XMLでレポートを直接編集するか、VS2008でレポートを操作してから、現在のVSバージョン（2017）にプルアップする必要がある間です。
ReportViewerから別のものに切り替えます。明白なのはクリスタルです。その製品の経験はありません。これは私たちのアプリで大量の書き換えを必要とするでしょうが、私はそれが好きではありません。
VS2008/ReportViewer 2008に戻します。これで問題ありませんが、最近のコードの一部を.NET 3.5での作業に戻すことを意味します。このルートについて私が気になるのは、MSからの将来のサポートです。 ReportViewer 2008は、新しいバージョンのWindowsでも引き続き機能しますか？ .NET 3.5は引き続き機能しますか？
何よりもまず、私が間違いを犯さないようにすることです。新しいReportViewerバージョンについて理解できないことがあるかもしれません。多分私が見つけた回避策の私の理解は正しくありません。マイクロソフトへのバグレポートまたはMSDNフォーラムからフィードバックを得ることは、実りのないものでした。これは非常に広く使用されている製品であるため、かなり前に対処する必要があったため、何かを見逃しているように感じます。
興味がある人のために：
IMO、新しいバージョンがプロジェクトのパフォーマンスに大きく影響する場合は、開発フレームワークをアップグレードするべきではありません。
まず、この新しい開発環境で新しいコードを実装する前に、フレームワークの新しいバージョンをテストしておく必要があります。プロセスに関しては、これが正しい方法だと思います。
ただし、すでにアップグレードしており、新しいフレームワークを使用してコードを記述しているため、以下のオプションのoneをお勧めします（必要に応じて、各オプションに必要な詳細/労力を提供して、評価に役立てることができますどちらがより実現可能か）：
- 現時点では、クライアントが優れたパフォーマンスで機能を使用できるように、レポート機能のみを別のプロジェクトにダウングレードし、個別に展開します。
- 以前に機能していた開発環境に完全にダウングレードし、古いバージョンの.NET Frameworkで動作するように新しいコードを書き換えます。
- いくつかの変換ツールを使用して、レポートを別のレポートエンジンに変換してみてください。
- レポートを別のエンジン（別のエンジン）に変換する変換ツールを作成します。
- この新しいバージョンでは、レポートのパフォーマンスが低下している理由をより詳しく調査してください。
- フォールバックレポートを作成します。これにより、メインのレポート機能がメンテナンス中である間、クライアントはまだ何かを使用できます。
オプションを組み合わせることができます。レポートを別のエンジンに移行する予定がある場合は、最初のオプションを使用します。
これは、サードパーティのライブラリを使用することの欠点の1つです。ライブラリへの依存度が高まるにつれ、それらのライブラリを開発する会社のなすがままになります。彼らは好きなように優先順位を設定できるだけでなく、このライブラリのメンテナンスを中止するか、単に破産して、選択肢があまりないままにすることさえできます。
別の会社が行った選択はtheirです。非常に重要な顧客であったり、顧客が重要なことに取り組むために多額の費用を払うことを提案したりするなど、いくつかの要因to yoが交渉に役立つ場合があります。ただし、これは特定のケースに固有であり、このサイトの範囲外です。
技術的な側面に戻ると、これらのリスクを軽減するために取り組むことができることがたくさんあります。
インターフェース
最も重要な側面はサードパーティのライブラリとビジネスロジックの間のインターフェースを配置するで構成されます。これは、競合他社がたまたまライブラリを開発した場合（または独自に開発できる場合は独自の実装に）、別のライブラリに切り替えるのに役立ちます。
時々、これは非常に簡単です。通常、非常に具体的で狭いタスクを実行するために使用される小さなライブラリは、まさにそのようなものです。それらを抽象化することは非常に簡単であり、ほぼゼロの労力でライブラリを別のものに交換できます。例：URIからQRコード画像を生成するライブラリ。
他の場合では、それは非常に複雑です。実際にallコードが依存するフレームワークまたはライブラリは、コードと非常にインターリーブされる傾向があります。抽象化が使用されている場合でも、1つのライブラリ/フレームワークを別のライブラリ/フレームワークと交換するのはそれほど簡単ではない場合があります。例：SharePoint。
コードとサードパーティの間の結合を減らすことが重要であるだけでなく、将来必要になった場合にライブラリを交換することがどれほど難しいかを測定できるようにすることも不可欠です。ビジネスコードとインターフェイスコードをいくつかのパッケージに分離すると、ビジネスロジックに属するコードの量、およびサードパーティライブラリとのインターフェイスを提供する量を示すことで、そのヒントが得られます。インターフェイスパッケージで取得するコードが多いほど、問題が多くなります。
自動展開
ライブラリの新しいバージョンが以前に機能していたものを破壊するという特定の問題は、ソフトウェアの展開に関連する一連のプラクティスに従うことで回避できます。
手入れの行き届いていない環境での大きなリスクの1つは、ライブラリを手動で新しいバージョンにアップグレードすると、以前のバージョンに戻すのが困難な状況に陥る可能性があることです。問題は、ダウングレード操作中のダウンタイムから、小売業者が古いバージョンのライブラリを配布しなくなった場合や、バイナリのバックアップを保持しなかった場合など、さまざまです。あるいは、サーバーで実行された古いバージョンを最初にインストールするために実行されたすべての手順を再現することは単に不可能である可能性があります。
自動デプロイメント、依存関係の適切なバージョン管理、およびアーティファクトリポジトリを使用して、十分に管理された環境で、新しくデプロイされたバージョンから古いバージョンに切り替えるのは、「デプロイ」をクリックするだけの簡単なものです。以前のリビジョンのyour app、サードパーティのライブラリの古いバージョンを使用したもの。
マイグレーション
最後に、重要な側面は、ライブラリの別のバージョンに（またはライブラリから競合他社のバージョンに）移行する前に、それが（1）正しく機能し、（2）ニーズに適合していることを確認する必要があることです。
正しく機能することを確認する場合、ライブラリを操作して動作を確認する必要がありますが、ストレステストや負荷テストなどのテストも実行する必要があります。 your productのテストについてはここでは触れていません（ただし、実行できるのはafter移行するだけなので）サードパーティライブラリが使用する主なシナリオをどのように実行するかを確認する唯一の目的。
例1：QRコードを生成する別のライブラリに移行する場合、1万枚の画像を生成するテストを作成して、新しいライブラリが古いものよりも優れている（または少なくともそれほど遅くない）かどうかを確認できます。
例2：サイトを新しいバージョンのSharePointに移行する場合、サイトの主な用途がWordドキュメントの格納である場合、2つのバージョンのSharePointがパフォーマンスとディスク容量に関してどのように処理するかを比較するテストを作成できます。この特定のストレージを使用して（たとえば、Officeドキュメントのチャンクの導入がディスク領域の節約にどのように役立つか、およびCPU使用率と全体的なパフォーマンスにどのような影響があるかを調べることを試みます）。
あなたの質問を読んで、いくつかのストレステストがあると、すべてのアセットをライブラリの新しいバージョンにアップグレードできず、only thenパフォーマンスの問題を見つけることができなかったようです。