Visual Studio 2017でReport Viewerの表示、編集ができない

Visual Studioで久しぶりにReport Viewerを編集しようとしたのだが、右クリックしても何も表示されない。 右上に右向きの矢印が表示されるはずなのだが、それもない… 新しいフォームを作ってReportViewerをドロップしたところ、何も表示されない。 https://stackoverflow.com/questions/28179780/reportviewer-not-shown-on-form-designer-c-winform を参考にInitializeComponentにコードを追加すると表示はされるが、やはり一切編集できない。 編集したい理由は、rdlcファイルを指定がエラーとなっていて編集し直したかったため。this.reportViewer1.LocalReport.ReportEmbeddedResource にrdlcファイルを直接指定する方法を試してみたが、GUIで指定したほうが有効になっているためか全く効かない。 最近.Net Coreのプロジェクトを作った際、Visual Studio CodeとIntellisenseがらみで干渉したため、いったんアンインストールしたことがあった。その際に設定がおかしくなったのかもしれない。 Visual StudioをいったんアンインストールしてOS再起動後にインストール。 Visual Studio 2017(Pro)をインストール後、拡張機能「Microsoft RDLC Report Designer」をインストール。 Microsoft.ReportingServices.ReportViewerControl.Winformsライブラリを、Visual Studio内のNuget管理画面にて、下げられる最低のバージョン140.337.80まで下げると編集メニューが表示される!! ただ、既に作成済みのreportViewerはうまく動作しないため、いったん削除して同名で再作成して再配置。 その後、最新バージョンまで上げたが、正常に動作している。 一旦バージョンを下げることでキャッシュか何かがクリアされたのか? 原因不明。

<span title='2019-10-04 00:00:00 +0900 +0900'>October 4, 2019</span>&nbsp;·&nbsp;1 min&nbsp;·&nbsp;tack41

MySqlBulkLoaderでの取込結果が合わない

C#でMariaDBに接続する際にMySqlConnectorを利用している。 大量のデータを取り込む必要があったため、MySqlBulkLoaderで取り込んだところ、なんかゴミデータみたいのが入るうえに数字も合わない。 よくよく調べたところ、前段のCSV出力個所と、取込時の設定にミスがあった。 CSV出力時の改行の削除 CSV出力にはCSVHelper.CsvWriterを使用しているのだが、Fieldに改行があるとそのままCSVに出力される。CSVファイルは1行1データを前提としているので、ゴミデータが発生する原因になる。 csv.WriteField(col.ToString().Replace("\r", "").Replace("\n", "")) のように除去することで回避できた FieldQuatationCharacterの設定 FieldTerminator, LineTerminator は普通に設定したのだが、FieldQuatationCharacter を設定しないと、CSVHelperがせっかく括弧で囲んでくれた中にカンマが含まれていると、そこで区切られてしまう。 mySqlBulkLoader.FieldQuotationCharacter = '"'; と指定することで回避できた。 MySqlConnector の MySqlBulkLoader は上記のような不具合で項目数など合わなくてもエラーなしで無理やり取り込むのが困ったところ…

<span title='2019-08-23 00:00:00 +0900 +0900'>August 23, 2019</span>&nbsp;·&nbsp;1 min&nbsp;·&nbsp;tack41

IEnumerableで受けてIReadOnlyListで返すなら

http://tack41tu.hatenablog.com/entry/2019/02/28/092329 で記載した方針を受けて、最近はCollectionに関してはIEnumerableで受けて、IReadOnlyListで返す基本方針としている。 一方で、プロパティの変更による予期せぬ誤動作を防ぐために、POCOについてはコンストラクタで初期とを設定し、setterを提供しないことでImmutableな形としている。 ただ、そうなるとCollectionもコンストラクタで渡す必要があるが、アルゴリズムの関係などでCollectionのメンバーは後で追加したいことがある。例えばDBからデータを取得して、鑑データの属性として明細データのCollectionを持たせる場合に、鑑データのclassをいったん生成した後、明細データを都度追加したいことが多い。要は短期間だけメンバーを追加したい。 POCOに渡すCollectionの参照を呼び出し側で保持し、鑑データのコンストラクタに渡した後で呼び出し側で持っているCollectionの参照をもとにメンバーを追加したのだが、なぜか反映されない。 結論としては、POCO内ではCollectionをListとして保持しており、コンストラクタでIEnumerableで受けた際に直ちにtoListで変換していた。これだとその時点でオブジェクトがコピーされてしまい、呼び出し側で持っている参照とは別物になってしまう。 そこで、IEnumerableで受けたオブジェクトは内部的にもIEnumerableで保持し、getterで参照された際にtoListしてIReadOnlyList型として返すことで解決した。こうすれば呼び出し側で持っている参照とPOCOで持っているクラスは全く同じとなり、呼び出し側でメンバーを追加、削除すればPOCOにも反映される。getterで参照する場合はそもそもIReadOnlyList型としてわたるのでメンバーの編集はできない。castすればできなくもないかもしれないが、少なくともそれは保証対象外という意図を明示できる。

<span title='2019-08-09 00:00:00 +0900 +0900'>August 9, 2019</span>&nbsp;·&nbsp;1 min&nbsp;·&nbsp;tack41

.netで利用可能な帳票ツール

内製開発している.net(C#)で利用可能な帳票ツールについて調査した。結論としては、高いお金を出さないとまともなツールは手に入らないということ。 価格はすべて税抜き。 使えるが、高い Create!Form: 1帳票設計ライセンス200,000円、1WindowsServerランタイム400,000円。帳票ツールは使いやすそうで機能も十分そうだが、高い… Active Reports for .Net 12.0: 1開発ライセンス300,000円、サーバーライセンス(2core)120,000円。Create!Formと同様、機能は十分だが高い… iTextSharp: 保守されている最新のVer.7(iText)では、ライセンスがAGPLかCommercial License。Commercial Licenseの費用は見積もりを取らないとわからないっぽいが、このサイトによると、1920ポンド(26万程度).. JasperReport: Jaspersoft Studioという設計ツールで設計は簡単そう。.Netから利用しようとすると、Serverを立ててAPI経由での利用だがCommunity ServerのライセンスがAGPLか商用ライセンスの購入が必要。価格は見つけられなかったが、上記製品と同価格帯だろう。… LibraryはLGPLなのに… クライアントをJavaで開発するのは、今の自分の開発スキル的につらい、つらすぎる… 安いが、あまり使えない Reports.net: 1開発ライセンス60,000円、ランタイムは無料。ヘルプ等を見る限り、ヘッダ・フッタやグルーピングという概念がなく、すべての項目を項目名を指定して出力し、ページ送りも自分で行う感じに見える。Excelに自分で出力するのと大差ない。 VB-Report 8: 1開発ライセンス85,000円、ランタイムは無料。Reports.netよりもさらに原始的で、ひな形Excelのセル番号を指定して出力する感じ。ひな形ExcelにClosedXMLあたりで出力したほうが早いやん。 Access: 14,800円。ランタイムは無料。一部内製アプリで使用しているが、 VBAは見捨てられた言語だし、ソースコードはいったんExportする必要があり、かつ元のバイナリには戻せない。開発しづらい。 無料だが、つらい [Microsoft ReportViewer]: Visual Studio Proに添付。どっちにしろうちの開発用途ではCommunityは使えないので。ただ、社内帳票でよくある、1明細が複数行にわたる場合に対応できない。 ClosedXML.Report: 無料。よさそうだが、こちらも、1明細が複数行にわたる場合に対応できないっぽい。 帳票.NET: 無料。最終リリースが2016年。継続性に不安 Excel: 全利用者に配布済みなので追加費用不要。ClosedXML等を利用して普通にセル指定で出力。プログラムで頑張ってセルを指定して出力するか、ひな形にてデータの表示とは別にデータの入力個所をまとめておいてプログラム側の負荷を下げるか、どちらにしてもめんどい。帳票の種類が増えてくるとつらさが増してくる。 まともなツールは1開発者でも300,000円から400,000円程度は最低でも必要なのだろう。が、中小企業においてこの金額はおいそれとは出ない。今後も継続的にバージョンアップする必要があるだろうし。 ひとまず、帳票部分のみAccessで開発、そのAccessを.netプログラムに同梱して帳票部分で呼び出す形にできないか調査、ダメならExcelのひな型をなるべく工夫する。あまりにつらくて上記費用が安いと感じられるようであれば購入を申請する形か。

<span title='2019-06-28 00:00:00 +0900 +0900'>June 28, 2019</span>&nbsp;·&nbsp;1 min&nbsp;·&nbsp;tack41

Get-ChildItemからのLengthプロパティでのファイル容量取得ではまる

PowerShellで特定のフォルダ配下に存在する一定容量以上のファイルをリストアップするスクリプトを作成。 Get-ChildItem -Recurse . | Where-Object{$_.Length -ge 10*1024*1024 } よくあるお題であちこちにサンプルがあるのだが、なぜかLengthプロパティがないというエラーが出る。 色々調べた結果、Set-Strictのversionを2以上にすると発生することが分かった。1の場合には存在しないプロパティでも無視することで動作するようだ。 http://winscript.jp/powershell/131 や https://stackoverflow.com/questions/44035319/get-childitem-length-is-wrong によると、対象がdirectoryの場合に配下のFileInfoとDirectoryInfo配列のサイズを返すところ、配下が1つのみの場合だと存在するFileInfo,またはDirectoryInfoのLengthを返そうとするためで、無理やり配列にすればいけるとあるが、ダメ。Directoryに対しては配下にファイルが無くても、何個あってもLengthプロパティへの問い合わせはエラーとなる。PowerShell Ver.5.1.17763.503 on Win10 1809(64bit)で確認。 結論としては、Directoryの中の個数をカウントしてもしょうがないので、対象をファイルのみにすることだった。 Get-ChildItem -Recurse -File . | Where-Object{$_.Length -ge 10*1024*1024 } これであれば、Set-StrictのVersionがlatestでも通る。

<span title='2019-06-25 00:00:00 +0900 +0900'>June 25, 2019</span>&nbsp;·&nbsp;1 min&nbsp;·&nbsp;tack41