csharp

TL;DR Windows 11 22H2より印刷設定ダイアログで「設定」ベースの「Win32アプリケーションから印刷しています」という画面が表示されるようになった。 レジストリの設定変更により旧ダイアログに戻せる 経緯 VisualStudio(C#)のプログラムでReportViewerを使っているところがあります。印刷時に以下の設定が必要で、プログラムからこれらを設定していました。 プリンター名 用紙設定 トレイ(手差しトレイを使用) 印刷設定画面を経由しますが、上記が設定済みのため何も変更せずに実行すれば正しく印刷されていました。 Windows 11にバージョンアップ後、印刷設定画面がWindowsの「設定」ベースのモダンな感じに変わってしまい、上記の設定が引き継がれなくなってしまいました。 色々調べたところ、レジストリを以下のように設定すればもとの印刷ダイアログに戻るということがわかり、実際確認できました。 ハイブ: HKEY_CURRENT_USER キーのパス: SOFTWARE\Microsoft\Print\UnifiedPrintDialog 値の名前: PreferLegacyPrintDialog 値の種類: REG_DWORD 値のデータ: 1 [参考] https://answers.microsoft.com/ja-jp/windows/forum/all/win-32/77e2e4de-9d07-4ee9-9967-3c3aa3d60ede AD環境ですべての端末に反映したかったので、グループポリシーの[ユーザーの構成]-[基本設定]-[Windowsの設定]-[レジストリ]にて上記の項目を「更新」で登録し、全ユーザーに配布したところ、症状が解消されました。 配布対象にはWindows10の利用者もいましたが、問題なく利用できています。

TL;DR .Net FrameworkからAccessの通貨型の列に値を設定する場合は、System.Decimal型を利用する。 経緯 伝票番号が11桁の数値となるシステムにて、値をSystem.Int64型に格納していた。最終的にAccessのテーブルに格納する必要があり、こちらは通貨型で整数部11桁で定義していた。 OleDb経由でParameterを利用して(SQLにべた書きせずにobject型の変数として渡す)INSERTしたところ、何のエラーも吐かずにこけた。 どうも、System.Int64(=long)が渡されるとAccess側ではLong型(-2,147,483,648 ～ 2,147,483,647)に変換しようとするらしい。ただ、該当の列に「1L」(System.Int64型)を与えるとこけるが、「1」(System.Int32)ではこけないので、値そのものではなく型の違いによるエラーなのだと思われる。DEBUG実行してもエラーをはかずにこけるので切り分けに時間がかかった… 相手が通貨型11桁なのでそれに合わせてよしなに変換してくれるものと思っていたが甘かった。が、前回同じコードを実行した際にはエラーは起きなかったはずなのだが… 仕様が変わったのか? まぁ、特にAccessのような(レガシーな?)システムとの接続の際には、自動変換には期待せずこちらで必要な型が分かる場合は指定したほうが無難だと理解した。

要約 テスト対象プロジェクトのコンテンツファイルが存在することが必要となるテストを行う場合は、テストクラスに[DeploymentItem(@"Files\contents.xlsx", "Files")]の記述が必要 内容 Targetプロジェクトにて、Files\contents.xlsxをコンテンツ指定しており、これを利用する機能をTargetTestプロジェクトから実行する場合、何も考えずに実行するとFiles\contents.xlsxが見つからない旨のエラー(File or Directory Not found)が出る。 で、そのあとにテスト単体を個別に実行するとうまくいく。[選択して実行]と[すべてを実行]では実行パスが違い、前者では何も指定しなくてもコンテンツもコピーされるが、後者ではされないためのようだ。 [http://blog.livedoor.jp/nanoris/archives/51825230.html:embed:cite] 対応としては、TestClassのアノテーションの下にDeploymentItemのアノテーションを追加するとうまくいった。 [TestClass] [DeploymentItem(@"Files\contents.xlsx", "Files")]` public class TestClass{ ... ディレクトリ「Files」も指定しないとDirectoryNotFoundExceptionとなった。コンテンツファイルをテストプロジェクトにコピーする必要はない。

要約 MSTestは、複数クラスのメソッドを交互に実行しうる。これが困る場合は1つのクラスにまとめるべきかもしれない 内容 テストクラスAで更新系のテストをまとめてクラス初期化時にデータ整備を行い、テストクラスBで参照系のテストをまとめてテスト実行時にデータ整備を行っていた。 MSTestでは標準で並列実行はしないので問題ないと思っていたが、タイミングによって参照系のテストがこけることがあった。よくよく調べてみると、参照系のテストの一部が終わった状態で更新系のテストに移り、そこでデータが更新されてしまった状態で残りの参照系のテストが行われ、データが合わない状態だった。 並列実行しないというのはメソッド単位の話で、クラス単位のメソッドの実行順位が入れ子になることはあるようだ。成功したり、失敗したりするヤなパターンとなる。 対応として参照系、更新系を同一クラスにまとめ、全メソッドに対してメソッド実行時にデータ整備を行うこととした。 参照系のテストのみであればデータ整備はクラス初期化時でよいのだが、更新系が混ざる場合は参照系を含む全メソッドでメソッド実行時にデータ整備を行わないといけないということか。

Windows FormのDataGridView .Net Framework 4.7.2 にて DataGridViewでDataSourceにDataTableを代入して利用する。 dataGridView1.DataSource = dt1; 1回目に列名2020/1,2020/2,2020/3,2020/4 の4つの列名を含むDataTableを設定。その後2019/10,2019/11,2019/12,2020/1 の4つを列名に含むDataTableを渡すと、重複する2020/1が 先頭に表示されてしまう。DataSource自体は全く別のオブジェクトなのだが、DataGridView側で前回のColumn情報を覚えていて、列名がマッチしたら使いまわしているのかもしれない。 対策としては、DataSourceに代入する前に dtaGridView1.Columns.Clear(); を実行すればよい。