2017年8月27日日曜日

C# TIPS: IDE0017を回避する

■ Visual Studio がエラー窓に出すメッセージに、IDE0017というものがある。



たとえば次のようにWebClientを作るだけで、同メッセージが出てしまう。



何かコンストラクタ関係の助言らしいが、「オブジェクトの初期化を簡略化できます」だけじゃ意味がわからないんですよ。

■ ネットを見ると同様の疑問を持つ人が多数フォーラム等で質問しており、だいたいこんな回答をされている。
  • コードがバグってるんじゃね(いやバグってないし)
  • コンストラクタの用法が悪いと言われてるのだ(わかってるつーの)
  • 俺のコード参考にしてみ(お前のコードはWebClientじゃないだろ)
  • #pragma warning disable IDE0017」で消せるよ(いいのか?)

■ 自分でもコードをいじりつつ試行錯誤してみると、どうやら コンストラクタ呼び出しの直後にプロパティを代入する と、IDE0017が表示されることがわかった。

両者の間に空文1個でもはさめばメッセージは回避できる。たとえば次のコードならIDE0017は表示されない。



たぶんこれは、引数付きのコンストラクタを呼び出すことが推奨されているのだろう。でもWebClientには、Credentialsを指定できるコンストラクタなんかないし。いやあるのかもしれんが、このぐらい見逃してくださいよー。

■ というわけで、今後ネットでIDE0017に関する質問を見たら、「空文1個いれてみ」と答えることにしたい。

たぶん「そんな対症療法よくない」って反応が返ってくるだけだろうが(わかってるつーの)。

2017年8月24日木曜日

C# TIPS: Properties.Settingsの永続データ

小生の場合、プログラム開発時にはあれこれ調べ、さまざまなコーディング知識を得る。しかし数カ月後には、すべて忘れている。困ったものである。そこで今回は、覚えておきたい小ネタを、TIPSとして本ブログに書き残していくことにする。

まずはProperties.Settingsクラスの永続データの保存パスについて。

■ Properties.Settingsクラスはプログラムの状態を永続化する。――と言うとわかりにくいが、要するにプログラム終了時に特定の変数を記録し、次回に復元するためのライブラリだ。ウィンドウ位置の保存などにとても重宝する。

この永続データがどこにあるか調べたところ、次のパスに保存されていた。
C:\Users\ユーザー名\AppData\Local\会社名\プログラム識別記号\バージョン番号\user.config
フォルダ名に含まれる単語の意味は次の通り。

* ユーザー名
プログラム実行者のWindowsログイン名。これはつまり、ユーザーごとに別々の設定が保存可能ということだ。

* 会社名
開発会社名。プロジェクトのプロパティで設定可能である。趣味のプログラマなら適当な名前でもOKだ。自分の所有するドメイン名などにすると、他と重複せず良いんじゃなかろうか。

* プログラム識別記号
プログラムのEXEファイルの名前+何か記号。記号の意味は不明だが、デバッグビルドとリリースビルドで違うフォルダが作られることは確認した。

* バージョン番号
プログラムのアセンブリバージョン。プロジェクトのプロパティで設定可能。

■ 会社名やバージョン番号は、次の手順で設定する。
  1. メニューから、[プロジェクト]-[(プロジェクト名)のプロパティ]
  2. カテゴリは[アプリケーション]を選択
  3. [アセンブリ情報]ボタンをクリックする
  4. 会社名とバージョン番号を入力する


■ ところでVisual Studioには、アセンブリバージョンを「1.0.*」に設定しておくと、バージョン番号の末尾に自動的にビルド時刻を埋め込む便利な機能がある。

この機能を使うと毎ビルドごとにバージョン番号が更新され、設定保存パスも変わるため、「なんで設定が保存されないの?」と悩むはめになる。実体験である。

というわけで、Properties.Settingsクラスのデフォルトの保存パスを変える方法があればよいと思う。調べてみたい。

2017年8月22日火曜日

C#のWindowsフォームでマイリス更新チェック(3)

【前記事】の続き。完結編です。

■ ここまでの下準備で、データ読み込みと表示部分は完成した。また、こないだのC#コンソール版で、ネット接続とマイリスチェックの処理も作った。あとはガシガシ組み合わせていけばよい。

■ まずはusing宣言から。

開発中はいろいろなライブラリに手を出すので、あれこれusingが増えるが、結局おなじみの名前が残るんだな。

■ そして今回のメイン処理、ニコニコ動画マイリス更新チェックをコーディング。


■ このメイン処理を、開始ボタンのClickで呼び出す。


■ さらにプログラム終了時に、最新のデータをローカルPCのデータファイルに書き戻しておく。

■ テスト実行してみる。
  1. メニューから、[デバッグ]-[デバッグの開始]
  2. 開始ボタンを押し、ニコニコ動画のマイリス更新チェックがおこなわれることを確認する
  3. マイリストを更新時刻順に並べたHTMLファイルが作られ、Webサイトにアップロードされたことを確認する

うまく動いているんじゃない?
Webページのほうは・・・→ https://pilikala.net/yuima/nico.html
ふむ無事アップロード出来ている。

これでプログラム完成!

■ プロジェクト一式のZIP圧縮ファイルを下記ページに置きました。

https://pilikala.net/yuima/e/004.html

ソースコードのみでEXEファイルなどのバイナリは入ってません。Visual Studio 2017 Community(無料版)で動作確認しました。

■ データの追加/削除/編集の機能は、プログラム自体にはありません。データファイルNicoCheckGuiData.xmlを手作業で書き換えてください。

2017年8月21日月曜日

C#のWindowsフォームでマイリス更新チェック(2)

【前記事】の続き。

■ こないだ作ったPerlスクリプトでは、必要なデータを全部コード内に書いた。インタープリタ言語のいいところだ。データを追加したければスクリプト本体を書き換えればいい。

しかしC#では、データとコードは分離させる。データ形式は次の候補を考えた。
  • CSV形式: カンマ区切リテキスト、エクセルで編集できる
  • XML形式: タグ付き構造化テキスト、ライブラリが充実
  • JSON形式: ジェイソン、便利そうだが使ったことがない
そして1分間の熟慮の結果、今回はXML形式を採用することに決めた。

■ とりあえず動作確認用のXMLデータを手作業で作る。
  1. メニューから、[プロジェクト]-[コンポーネントの追加]-[ファイル]
  2. カテゴリは[Visual C# アイテム]-[データ]
  3. ファイルの種類は[XMLファイル]を選択
  4. ファイル名をNicoCheckGuiData.xmlとして、[追加]ボタン
  5. XMLエディタで、下記※のダミーデータを入力する
  6. ソリューション内のNicoCheckGuiData.xmlをクリックし、ファイルのプロパティを表示
  7. [ビルドアクション]を、"コンテンツ"にする(すでになっている)
  8. [出力ディレクトリにコピー]は、"新しい場合はコピーする" を選ぶ
※NicoCheckGuiData.xmlに入力するダミーデータがこちら


■ このXMLのitem要素を、C#コードではデータ保持用のNicoInfo型に変換して扱うことにする。

まずForm1.csのコードウィンドウにSystem.Xmlのusing宣言を追加する。


次のようなNicoInfo型の定義を追加する。


データを読み込むLoadData()と、表示用のUpdateListVewi()を記述する。


作成したメソッドは、FormのLoadイベントハンドラから呼ぶ。


■ この段階でまたテスト実行してみよう。
  1. メニューから、[デバッグ]-[デバッグの開始]
  2. データファイルの内容がListViewに反映されることをチェック


というわけで首尾よくダミーデータが表示された。めでたしめでたし。

■ 次はいよいよ実際のニコニコ動画チェックの処理である。いったんここで記事を切る。【次の記事】に続く。

2017年8月20日日曜日

C#のWindowsフォームでマイリス更新チェック(1)

本ブログでC#のGUIアプリを作るのも久しぶり。自分でもあやふやな手順が多々あるので、ちょっと細かくメモをとりながら進める。

(ブログを読んでる方は記述がうざいかもしれませんが、このへん自分への備忘メモを兼ねているのでご勘弁ください。)

■ プロジェクトは「Windowsフォームアプリ」形式で作成する。手順は次。
  • メニューから、[ファイル]-[新規作成]-[プロジェクト]
  • テンプレートは、[Visual C#]-[Windowsクラシックデスクトップ]
  • [Windows フォームアプリケーション (.Net Framework)] を選択
  • プロジェクト名をNicoCheckGuiとして、[OK]ボタン

■ フォームにコントロールを配置する。自作小物プログラムなんて、画面はたいてい単純だ。小生はよく下記構成でレイアウトする。



要するに、TabControlを1個、Buttonを1個、フォーム上に置くだけである。

■ 配置したコントロールの各種プロパティを設定する。
  • 右下プロパティウィンドウで「プロパティ」アイコンを選択、プロパティ設定モードにする。
  • コントロールを選択すると、そのプロパティ一覧が出る。
  • まずフォームのFontのサイズを変更する。デフォルトの9ptは小生には小さすぎるので12ptに変更。フォームのFontサイズはコントロールにも引き継がれるので便利だ。
  • 各コントロールのAnchorプロパティを設定し、フォームの拡大縮小に連動させる。
  • TabControlは、Anchorで上下左右の4辺を固定する。
  • Buttonは、Anchorで左辺と下辺のみ固定する。
  • 最後に、フォームのタイトル、タブページの見出し、ボタンのキャプションなどを、それぞれのTextプロパティで設定する。
  • あとはお好みで各コントロールのNameを設定するのもよろしかろう。
  • ちなみに小生は、コントロール名に必ずプリフィックス"My"を付ける。本ブログのサンプルコードもすべてその方針でいく。

■ イベントハンドラを追加する。手順は次の通り。
  • 右下プロパティウィンドウで「イベント」アイコンを選択、イベント追加モードにする。
  • コントロールを選択すると、そのイベントハンドラの一覧が出る。
  • 必要なイベントハンドラ名をダブルクリックすると、コードウィンドウにコードが追加される。最初は下記3つでよい。
  • フォームのLoadイベントを追加
  • フォームのFormClosedイベントを追加
  • 押しボタンのClickイベントを追加
  • 間違ってハンドラを追加してしまった場合は、プロパティウィンドウでハンドラ名を右クリックし、[リセット]を選ぶと削除できる。

■ 最後は個々のタブページ上にコントロールを配置する。
  • メインタブページに、ListViewを配置。
  • ログ表示タブページを開いて、RichTextBoxを配置。
  • これらのプロパティ設定は、やや煩雑なのでコードの方でおこなう。
  • もちろんコード記述ではなく、全部プロパティウィンドウで設定しても、まったく問題ない。

■ Form1.csのコードウィンドウで、次のコードを入力する。


■ アプリ終了時にフォームの位置等を保存するため、変数を登録する。
  • メニューから、[プロジェクト]-[NicoCheckGuiのプロパティ]
  • [設定]カテゴリを選択
  • 次の7個の変数を登録する


■ 設定の保存と復元のため、次のコードを入力する。


■ これでやっとGUIアプリの枠組みが完成である。デバッグ実行してみよう。
  • メニューから、[デバッグ]-[デバッグの開始]
  • タブをクリックすると、ページが切り替わることをチェック
  • プログラム終了時のウィンドウの位置やサイズが、次回に引き継がれることを確認


フォームの位置の保存とか、初めて使ってみたけど、すんごく便利だね。

■ 以上がGUIプロジェクト作成における「いつもの手順」である。どんなプロジェクトでも似たような作業なので、今後の記事では省略されるであろう。

残りは長くなるのでいったんここで記事を切る。【次の記事】に続く。

2017年8月17日木曜日

C#で書く、ニコ動マイリストの更新チェック

前回のPerlスクリプトにバグを発見し、そっちの記事を書き換えようとして、間違えてこっちを消してしまった。(2017/08/29)

もう元原稿が残ってないので、この記事はあとで書き直す。まあ、たしか3段落程度の短い記事で、たいしたこと書いてなかったし…(しくしく)

ていうかプログラムのソースも見つからないよこれ!どこいった?まあいいやプロジェクトごと作り直し。以下、記憶を頼りに書き直したもの。

■ この記事には、たしかこんなことが書いてありました。
  • PerlスクリプトをC#に焼き直したよ。
  • PerlからC#へのコンバートは思いのほか簡単だった。
  • 特にWebClientクラスが気に入った。WebのアクセスもFTPアップロードも、これ一発だ。
  • まあC#もコンソールアプリは楽なんだ。次はGUI版を作る予定なので大変かも。

■ プロジェクトの作成手順
  1. メニューから、[ファイル]-[新規作成]-[プロジェクト]
  2. テンプレートは、[Visual C#]-[Windowsクラシックデスクトップ]
  3. [コンソール アプリ (.Net Framework)] を選択
  4. プロジェクト名をNicoCheckとして、[OK]ボタン

■ Program.csにコードを入力


■ プロジェクト一式のZIP圧縮ファイルを下記ページに置きました。

https://pilikala.net/yuima/e/003.html

ソースコードのみでEXEファイルなどのバイナリは入ってません。Visual Studio 2017 Community(無料版)で動作確認しました。

2017年8月15日火曜日

ニコニコ動画のマイリストの更新チェック

■ ニコニコ動画で、よく見ている動画のシリーズがいくつかある。

その新作を追うため、最初はそれぞれのマイリストを普通にブックマークしていたのだが、お気に入りが増えてくると、ブックマークの管理も大変になってきた。

■ というわけで作ったのが、複数のニコ動マイリストをチェックし、動画の更新日を一覧表示するツールだ。

実際にツールで出力した結果がこれ。
https://pilikala.net/yuima/nico.html

更新日が新しい順にタイトルを並べただけの簡単なものだが、実用上これで十分である。

■ Perlスクリプトのソースを下記に掲載した。

※バグ発見につき3行追加(2017/08/29)

なお日本語データ処理の都合上、スクリプトは必ずUTF-8で保存すること。 とりあえずWindows 10のコマンドプロンプト+無料版ActivePerlで動作を確認した。

■ ところでこのブログの趣旨は「Visual C# のプログラミング」であった。

にもかかわらず、気が付けばブログに載せるのはPHPスクリプトとかPerlスクリプトだけ。これではいかーん。

そこで次回は、上記のPerlスクリプトをC#で書き直すことを目指す。そのつもり。まあ、あくまでも予定で。

2017年8月13日日曜日

PHPスクリプトでSSLの有無を判定

【前記事】からの流れで。

■ サーバがSSL経由でアクセスされているかどうかを調べるPHPスクリプト。

判定方法は次の通り。
  1. 環境変数HTTPSの値が"on"なら通常のSSLを使っている。
  2. プロキシss1.xrea.com:3128経由のアクセスなら共有SSLを使っている。
  3. どちらでもなければ非SSL接続である。
とりあえずXREAの自サーバで動作確認した。

■ 下記スクリプトを「chkssl.php」という名前で保存して完成。


■ 実際の使用例がこちらです。
SSLあり → https://pilikala.net/yuima/chkssl.php
共有SSL → https://ss1.xrea.com/pilikala.s269.xrea.com/yuima/chkssl.php
SSLなし → http://nossl.pilikala.net/yuima/chkssl.php

2017年8月12日土曜日

続・XREAレンサバの無料SSLについて

【前回の記事】に追補。

■ まだマニュアルを読んでる途中だが、XREAの無料SSLを利用するには、独自ドメインが必須のようである。

まあXREAのレンサバって、VALUE-DOMAINでドメイン買ったオマケ的なあれなので XREAユーザはみんな独自ドメイン持ってるんだろうな。

■ つづいて、SSLなしアクセスの動作を確認するため、「http://pilikala.net/~」を開いたら、 自動的にSSLページ「https://pilikala.net/~」に飛ばされてしまった。そういう仕様か。

ではSSLなしの動作を試したい時はどうするか。その場合は、XREAのサブドメインでアクセスすればよい。

独自ドメインとXREAサブドメイン、httpとhttps、の組み合わせをまとめるとこうなる。

独自ドメイン XREAサブドメイン
http://pilikala.net/~
 → SSLありにリダイレクト
http://pilikala.s269.xrea.com/~
 → SSLなし
https://pilikala.net/~
 → SSLあり
https://ss1.xrea.com/pilikala.s269.xrea.com/~
 → SSLあり

■ さらに考察。SSLなしアクセスの確認は、XREAのサブドメインじゃなくて、自分の持つドメインに適当なサブドメインを作って利用してもよいはずだ。

実際にやってみた。次の手順でいけました。
  1. 自ドメインを管理してるネームサーバの管理画面に接続する。
  2. 適当なサブドメイン、たとえばnossl.pilikala.netとかを登録。
  3. XREAレンタルサーバの管理画面に接続する。
  4. サブドメインnossl.pilikala.netの使用をサーバに登録。
  5. nossl.pilikala.netのWebアクセスを、メインWebと同じ場所に振る。
  6. nossl.pilikala.netのWebのSSL設定を「なし」にする。
結果こんな感じに。

 SSLあり →   https://pilikala.net/yuima/e/001.html 
 SSLなし →   http://nossl.pilikala.net/yuima/e/001.html 

XREAのレンタルサーバで無料SSLが使えるよ

■ 現在XREAで月200円だったかの格安サーバを借りていて、ちょっとしたスクリプトを動かすのに重宝している。
ちなみにサーバは自分のドメインと、xreaのサブドメイン、どちらでもアクセスできるように設定している。

自分のドメイン
http://pilikala.net/yuima/

xreaのサブドメイン
http://pilikala.s269.xrea.com/yuima/

■ さてこのサーバだが、今までSSLでアクセスするにはXREAの「共有SSL」機能を使うしかなかった。
これは次のように「https://ss1.xrea.com/」という別サーバを介して自分のWebページにアクセスするものだ。

たとえば目的のURLがこれだとする
http://pilikala.s269.xrea.com/yuima/

同じページを共有SSLでアクセスするにはこう書く
https://ss1.xrea.com/pilikala.s269.xrea.com/yuima/

いまいち美しくないが、まあ自分でSSLを契約すると結構お高いし、これでいいやー。と思ってたのだが。

■ 今月からXREAのレンタルサーバ全部で、無料のSSLが使えるようになった。
これは次のように「https://」指定で自分のドメインにアクセスするだけでよい。

たとえば目的のWebページがこれだとする
http://pilikala.net/yuima/

同じページを無料SSLでアクセスするにはこう書く
https://pilikala.net/yuima/

おー、有料のSSLみたい!かっこいい。
というわけで自サーバで簡単にSSLが使えるようになった件、忘れないようにここにメモしておく。

■参考:無料の独自SSL ご利用開始のお知らせ(VALUE-DOMAIN)
https://www.value-domain.com/info.php?action=press&no=20170808_01


【次回の記事】に続きました。