6月 252015
 

基本的にはこれで→AppVeyor で NuGet パッケージの作成とデプロイを自動化 | grabacr.nét

困ったこと

  • 最初、バージョン管理 その1 の方法でやってた
  • でも push する度 nuget.org にデプロイされるのはこまる
    • push した際、常に nuget.org にデプロイしたいわけじゃない
    • AppVeyor の deployment condition で master ブランチの時だけとかある程度コントロールできるようだけど足りない
  • デプロイしたい時だけできるようにしたい

解決策

ぐらばくせんせーに聞いたところ、以下の解決策が提示されました。

  • AssemblyInfo patching を止める
    • AppVeyor の Build version は使わない&気にしない
  • バージョン番号は AssemblyInfo.cs だけで管理
  • nuspec は変わらず <version>$version$</version> としておけば AssemblyInfo.cs のバージョン番号の NuGet パッケージになる
  • デプロイしたい時に AssemblyInfo.cs のバージョンを上げて push

AssemblyInfo.cs のバージョンを変更しないで push した場合、NuGet パッケージ自体は作成されますが、nguet.org に投げても「もうそのバージョンはあるぜ!」と言われてスキップされます。

ビルドも失敗するわけではない。いい感じですね。。

おまけ

Branches and Tags – Appveyor には APPVEYOR_REPO_TAG でタグが push されたかどうかわかるっぽく書いてあったので、タグで管理できるかと一瞬思ったけど、true になる場合を観測できなかったので諦め。

5月 272015
 

さて巷ではJVNVU#98282440: 「提督業も忙しい!」(KanColleViewer) がオープンプロキシとして動作する問題が話題ですが、FiddlerCore は何も考えないで実装すると恐らくこうしてしまうような仕様です。クソですね。。

そもそも何が問題なのか

とりあえず適当に FiddlerCore を使ったアプリケーションを立ち上げてみましょう。

[csharp]
FiddlerApplication.Startup(55555, FiddlerCoreStartupFlags.Default);
[/csharp]

するとあら不思議、0.0.0.0:55555でListningされてしまいます。

[raw]
C:\Windows\system32>netstat -a -b -n -o -p TCP

アクティブな接続

プロトコル ローカル アドレス 外部アドレス 状態 PID
…(中略)…
TCP 0.0.0.0:55555 0.0.0.0:0 LISTENING 6688
[FiddlerTest.vshost.exe]
[/raw]

これではアプリが立ち上がってる間は外部からHTTPプロキシとして利用できてしまいます。
知らず知らずのうちに他所様への攻撃の踏み台にされて、ある日突然警察がやってくるなんてこともあるかもしれません。怖いですね。

で、どうすればいいかというと、127.0.0.1:55555でLisningするようにできればローカルプロセスしかアクセスできなくなるので、そう変更したいですね?
これはごく簡単で、AllowRemoteClientsfalseにしてやればOKです。

[csharp]
FiddlerApplication.Startup(55555
, FiddlerCoreStartupFlags.RegisterAsSystemProxy
| FiddlerCoreStartupFlags.ChainToUpstreamGateway
| FiddlerCoreStartupFlags.MonitorAllConnections
| FiddlerCoreStartupFlags.CaptureLocalhostTraffic);
[/csharp]

Flagなので指定しなければOK。

[raw]
C:\Windows\system32>netstat -a -b -n -o -p TCP

アクティブな接続

プロトコル ローカル アドレス 外部アドレス 状態 PID
…(中略)…
TCP 127.0.0.1:55555 0.0.0.0:0 LISTENING 7128
[FiddlerTest.vshost.exe]
[/raw]

つまりFiddlerCoreStartupFlags.Defaultがイカンわけです。
でも FiddlerCore は Fiddler.exe のUI以外の部分を抜き出したものなわけですから、Fiddler.exe 自体がそういうもんだという可能性もあります。


参照: FiddlerCore – Fiddler Proxy Engine for your .NET Applications

ここで Fiddler.exe および FiddlerCore のデフォルト値を見てみましょう。

Continue reading »

5月 142015
 

結論

グループ化したい時はControlTemplateItemsPresenterを使わないとダメっぽい

やりたかったこととか

また、ItemsPanel を指定せず、前述の ControlTemplate でコレクション項目の並べ方を指定する方法もあります。ControlTemplate 内に ItemsPresenter を配置する代わりに、Panel の派生クラスを指定し、IsItemsHost プロパティに True を設定します。

のだけども、グループ化して表示したい場合うまく表示されない。

  • こうしたかった
  • が、こうなる

※実際やりたかったこととは違うけど例なので……

Continue reading »

12月 012014
 

問題

  1. .NET 4 アプリケーションを作る
  2. Microsoft.Net.Http や Microsoft.Bcl.Async を参照する
  3. MsBuild /t:Publish する
  4. 配置した ClickOnce アプリを起動する
  5. アプリは死ぬ

解決策

  1. 参照してるアセンブリファイルをプロジェクトにコピー (公式手順的にはリンクとしてコピーだが物理コピーでも可っぽい)
  2. 「出力ディレクトリにコピー」を「常にコピーする」に変更
  3. 発行!

NuGet で更新する度にコピーし直さないといけないけど……

Microsoft.Net.Http

Issue 8

Symptom

ClickOnce applications targeting .NET Framework 4.0 that reference the Microsoft.Net.Http package may experience a TypeLoadException or other errors after being installed.

Resolution

This occurs because ClickOnce fails to deploy certain required assemblies. As a workaround, do the following:

Right-click on the project and choose Add Existing Item
Browse to the HttpClient net40 package folder
In the File name text box enter *.*
Holding CTRL, select System.Net.Http.dll and System.Net.Http.Primitives.dll
Click the down-arrow next to the Add button and choose Add as Link
In Solution Explorer, holding CTRL select System.Net.Http.dll and System.Net.Http.WebRequest.dll
Right-click the selection, choose Properties and change Copy to Output Directory to Copy always
Republish

引用元:http://blogs.msdn.com/b/bclteam/p/httpclient.aspx

System.Net.Http.Primitives.dll とか System.Net.Http.WebRequest.dll のことも書いてあるけど、 System.Net.Http.dll だけでOKだった。
むしろ System.Net.Http.Primitives.dll をコピーしてると、起動時に「もうあるよ!」的なエラーで死んだ。
そもそも手順的に Primitives をコピーしてるのになぜ WebRequest が出てくるのか……怪しげな説明。。

Microsoft.Bcl / Microsoft.Bcl.Async

Issue 9

Symptom

ClickOnce applications targeting .NET Framework 4.0 that reference the Microsoft.Bcl or Microsoft.Bcl.Async packages may experience a TypeLoadException or other errors after being installed.

Resolution

This occurs because ClickOnce fails to deploy certain required assemblies. As a workaround, do the following:

Right-click on the project and choose Add Existing Item
Browse to the Microsoft.Bcl net40 package folder
In the File name text box enter *.*
Holding CTRL, select System.Runtime.dll and System.Threading.Tasks.dll
Click the down-arrow next to the Add button and choose Add as Link
In Solution Explorer, holding CTRL select System.Runtime.dll and System.Threading.Taks.dll
Right-click the selection, choose Properties and change Copy to Output Directory to Copy always
Republish

引用元:http://blogs.msdn.com/b/bclteam/p/asynctargetingpackkb.aspx

7月 232014
 
  • 調べた分だけ。
  • 割とわかりやすかった:Overview of Custom Storage Providers for ASP.NET Identity | The ASP.NET Site
  • 「ASP.NET Webアプリケーション」テンプレートの認証「個人ユーザーアカウント」で作成されたコードを眺めれば何となく分かる。
  • Microsoft.AspNet.Identity.EntityFrameworkとかはEFのCodeFirstでテーブル初期化とかDB読み書きとかやってくれるやつだけど、CodeFirstが嫌でIUserStore自作するなら不要な感じ。
  • UserManagerがASP.NET Identityの中心的存在の予感。
    • OWIN startup classの中でCreatePerOwinContext()にて初期化用Funcを設定する。

PasswordHasherの入れ替え

[csharp]

public class ApplicationUserManager : UserManager
{
public ApplicationUserManager(IUserStore store) : base(store) { }

public static ApplicationUserManager Create(IdentityFactoryOptions options, IOwinContext context)
{
var manager = new ApplicationUserManager(new UserStore(context.Get()));
manager.PasswordHasher = new HogePasswordHasher();
return manager;
}
}

public class HogePasswordHasher : IPasswordHasher
{
public string HashPassword(string password)
{
// 塩を振ったりストレッチングしたりしよう
throw new NotImplementedException();
}

public PasswordVerificationResult VerifyHashedPassword(string hashedPassword, string providedPassword)
{
if (hashedPassword == HashPassword(providedPassword))
return PasswordVerificationResult.Success;
else
return PasswordVerificationResult.Failed;
}
}
[/csharp]

ちなみに、ASP.NET vNext のデフォルトっぽいPasswordHasherは以下の様な実装。

  1. Rfc2898DeriveBytesでSaltサイズのみ指定(128bitでRNGCryptoServiceProviderによって生成されるランダムSalt)にしてパスワードハッシュ生成(1000回ストレッチング)
  2. Salt + パスワードハッシュな文字列を返す(DBとかに保存する文字列になる)

検証時は

  1. DB保存的文字列からSaltとパスワードハッシュを切り離し
  2. そのSaltを利用して、入力されたパスワードからパスワードハッシュを計算
  3. 照合

2.0.0のMicrosoft.AspNet.Identity.PasswordHasher.VerifyHashedPassword()も、vNextのコードで生成したハッシュを使って検証したら成功したので、多分同じロジック。

参考:Identity/src/Microsoft.AspNet.Identity/Crypto.cs

Roleによる認可的な

Controllerで

[csharp]
if(this.User.IsInRole(“Admin”))
{
}
[/csharp]
とか
[csharp]
[Authorize(Roles=”Admin”)]
public ActionResult Index()
{
return View();
}
[/csharp]
とか。

Viewで

[csharp]
@if (this.User.IsInRole(“Admin”))
{
}
[/csharp]
とか。

7月 222014
 

そのうちまとめるつもり。

  • .NETのカラマネ対応APIは、System.Windows.Media, System.Windows.Media.Imagingの中にちょっとだけある。ほぼWPF専用なのではないかという予感…
    クラス / 構造体 概要
    ColorConvertedBitmap WICで一度だけ色変換できるBitmapSource。微妙MarkupExtensionもあるよ。
    ColorContext ICCプロファイル的なやつ。
    Color sRGB/scRGBカラーを扱う。挙動が微妙なこともあり、カラマネ的には役に立たない可能性が。
    BitmapFrameと各種Encoder/Decoder 画像ファイルを取り扱うクラス群。画像プロファイルも読み書きしてくれるっぽい。中身はWICの模様。

  • 内部的にはICM / WCS, WICを利用している。
    • System.Windows.MediaがICMに対応して、System.Windows.Media.ImagingがWICに対応するイメージなのかな?
  • いずれの場合もTransformは使い捨ててるので、パフォーマンスは微妙。
    • WCSプロファイルはTransform生成がかなり遅い(iccの30倍位)ため、非常に残念な事になる。回避するには多分P/Invokeしかない。
  • 残念なことにデバイスプロファイル等、PC/ユーザーに設定されているプロファイルを取得する方法は用意されていないので、ファイルパスを指定するかP/Invokeするしかない。

System.Windows.Media.Imaging.ColorConvertedBitmap

  • 変換元、変換先のColorContextと、変換したいBitmapSourceを指定して色変換できる。
  • これ自身がBitmapSourceを継承してるので、Image.Sourceとかに指定できる。
  • 一度初期化したら変更できない。
  • 内部的にはIWICColorTransformを使ってる。
  • ColorConvertedBitmap のマークアップ拡張機能なんてのもあるが、各プロパティ指定できるの一度きりだし、果てしなく微妙。

System.Windows.Media.ColorContext

  • イメージ的にはICCプロファイルとかと同じ。
  • 内部的にはColorContextHelperを通してICMのOpenColorProfile()GetColorProfileHeader()を利用している。
  • PixelFormatを指定して初期化することでsRGBとかscRGBのColorContextを取得できることになっているが、実際に取得されるのは コントロールパネル>色の管理>詳細設定>デバイスプロファイル に設定されているプロファイルだったり。
    • これはICMのGetStandardColorSpaceProfile()を利用しているからで、sRGBのプロファイルIDを指定しているにもかかわらず上記のような結果になるという謎挙動が原因である。
    • 既定のデバイスプロファイルではなく、ちゃんとsRGBを指定したいならば、自分でURIを指定する必要がある。

System.Windows.Media.Color

  • 一見RGBを抽象化したものに見えるが、実際はsRGB/scRGBカラーを取り扱う構造体である。
  • FromValues()およびFromAValues()にてColorContextを指定できるが、これは非常にややこしいことに「指定されたColorContext」→「既定のデバイスプロファイル(大抵はsRGB)」という変換となる。
    • 最初は「指定されたColorContextのRGB」を表す型なのかと思ってたら全然違った。
    • ComputeScRgbValues()というprivate methodの中で、PixelFormats.Bgra32を用いて変換先ColorContextを初期化しており、このソースを見る限りは本当はsRGBを変換先とするつもりっぽいのだけど、上記ColorContextの謎挙動により既定のデバイスプロファイルが変換先となってしまっている。
    • この変換処理ではColorTransformというinternal classを使っている。それ使わせてくれよ…
      • ColorTransformは、ColorTransformHelperを経由してICMのCreateMultiProfileTransform()TranslateColors()をやってくれるクラス。
    • 一色変換するだけの処理にもかかわらずTransformを使い捨てしており、コスト的にも大分残念な感じになっている。何に使うんだろうこれ…

System.Windows.Media.Imaging.BitmapFrame とか

  • まだあまり試してないが、画像プロファイルの読み書きができそうで良さ気。
  • System.Windows.Media.Imagingは大体WICと同じ雰囲気っぽい?
  • 内部的には完全にWIC依存。
  • でもIWICColorTransformとかは使わせてくれない微妙な感じ…
  • BitmapFrame.Create時などにBitmapCreateOptions.IgnoreColorProfileを指定していないと、埋め込まれた画像プロファイルからsRGB (これも同様にデバイスプロファイルかも知れない) へ変換される
    • 変換されるくせに埋め込まれたプロファイルColorContexts[0]はsRGBに置き換えられず、そのままである
    • これに気付かずにColorConvertedBitmapに食わせると、二重に変換されたりして悲しい思いをする
    • BitmapCreateOptions.IgnoreColorProfileを指定した場合、元のカラースペースを保持した状態で読み込まれる
  • CMYK画像をBitmapFrame.Createする際にBitmapCreateOptions.PreservePixelFormatを指定していない場合も、RGB PixelFormatへ自動変換される
    • 同様に、プロファイルが埋め込まれていた場合ColorContexts[0]はCMYKプロファイルのままである
  • BitmapCacheOption.None以外で読み込んだ場合、その時に指定されたBitmapCreateOptionsで画像がキャッシュされ、再読込時のBitmapCreateOptionsは無視される
    • Streamから読み込む場合はキャッシュの影響は受けないようだが、即時読込するためにはBitmapCacheOption.OnLoadが必要な点に注意

モニタプロファイルの取得

  • .NET じゃ無理ぽ
  • EnumDisplayMonitors()GetMonitorInfo()MONITORINFOEX取得
    →取得したデバイス名からCreateDC()でデバイスコンテキスト取得
    GetICMProfile()でプロファイルパス取得
  • 実コードとかはそのうち…
7月 162014