RSSイントレ。
Tag for "C#"
.NETなプログラムってUACが効かない？ようで、ファイルの仮想化などは行われないみたい。
標準ユーザーでProgram Files内にファイルを書き込んだりしようとすると例外が飛んじゃう。
アプリと同じ場所に設定ファイルを書き込もうとしたりする場合にちょっと都合が悪い。
普通はAppDataに書き込む(MSが推奨している)んだけど、バックアップ忘れるから好きじゃなかったり。
という事で、ファイルのアクセス権限を取得して書き込めるか否かで分岐させる事にしてみた。
小難しい事はぐぐれば先生が教えてくれると婆ちゃんが言ってた。
ファイルの所有者やアクセス権限を取得する(未完)
ファイルのアクセス権を取得する(完)
ズバリな内容がありました。
ファイルorフォルダのアクセスルールを取得。
現在のユーザー、もしくはユーザーが所属してるグループのSIDと合致するFileSystemAccessRuleを取得。
FileSystemAccessRule.FileSystemRightsを参照し、FileSystemRights.Writeを持ってれば書き込み権限があると判断。
折角なのでLINQを使ってコードを単純にしてみました。
public static class FileAccessPermissionHelper
{
// 書き込み権限持ってる？
public static bool IsGotWriteAccessPermission(string path)
{
var rule = GetCurrentAccessRule(path);
return ((rule != null) && ((rule.FileSystemRights & FileSystemRights.Write) == FileSystemRights.Write));
}
// 現在のユーザーが持っている指定パスのFileSystemAccessRuleを得る
public static FileSystemAccessRule GetCurrentAccessRule(string path)
{
var fileSecurity = File.GetAccessControl(path);
var rules = fileSecurity.GetAccessRules(true, true, typeof(SecurityIdentifier)).OfType<FileSystemAccessRule>();
var currentIdentity = WindowsIdentity.GetCurrent();
var sids = new[] { currentIdentity.User }.Concat(currentIdentity.Groups);
// アクセスルール内にユーザーSIDがある？無ければグループSIDも探す
return rules.FirstOrDefault(rule => sids.Contains(rule.IdentityReference));
}
}
ファイルがないと例外が飛んじゃうので、フォルダの権限を取得してやってみました。
…で、デスクトップ内やProgram Files内ではうまく動くのですが、
C:\内などになると書き込み権限がない(読み/ファイル実行権限のみ)と判断されちゃう。
実際は書き込みは問題なく行えるのですが…。
むぅ。
標準ユーザーでProgram Files内にファイルを書き込んだりしようとすると例外が飛んじゃう。
アプリと同じ場所に設定ファイルを書き込もうとしたりする場合にちょっと都合が悪い。
普通はAppDataに書き込む(MSが推奨している)んだけど、バックアップ忘れるから好きじゃなかったり。
という事で、ファイルのアクセス権限を取得して書き込めるか否かで分岐させる事にしてみた。
小難しい事はぐぐれば先生が教えてくれると婆ちゃんが言ってた。
ファイルの所有者やアクセス権限を取得する(未完)
ファイルのアクセス権を取得する(完)
ズバリな内容がありました。
ファイルorフォルダのアクセスルールを取得。
現在のユーザー、もしくはユーザーが所属してるグループのSIDと合致するFileSystemAccessRuleを取得。
FileSystemAccessRule.FileSystemRightsを参照し、FileSystemRights.Writeを持ってれば書き込み権限があると判断。
折角なのでLINQを使ってコードを単純にしてみました。
public static class FileAccessPermissionHelper
{
// 書き込み権限持ってる？
public static bool IsGotWriteAccessPermission(string path)
{
var rule = GetCurrentAccessRule(path);
return ((rule != null) && ((rule.FileSystemRights & FileSystemRights.Write) == FileSystemRights.Write));
}
// 現在のユーザーが持っている指定パスのFileSystemAccessRuleを得る
public static FileSystemAccessRule GetCurrentAccessRule(string path)
{
var fileSecurity = File.GetAccessControl(path);
var rules = fileSecurity.GetAccessRules(true, true, typeof(SecurityIdentifier)).OfType<FileSystemAccessRule>();
var currentIdentity = WindowsIdentity.GetCurrent();
var sids = new[] { currentIdentity.User }.Concat(currentIdentity.Groups);
// アクセスルール内にユーザーSIDがある？無ければグループSIDも探す
return rules.FirstOrDefault(rule => sids.Contains(rule.IdentityReference));
}
}
ファイルがないと例外が飛んじゃうので、フォルダの権限を取得してやってみました。
…で、デスクトップ内やProgram Files内ではうまく動くのですが、
C:\内などになると書き込み権限がない(読み/ファイル実行権限のみ)と判断されちゃう。
実際は書き込みは問題なく行えるのですが…。
むぅ。
SlimDX更新してみたついでに。
ちゃんと触るのは初めてなのでサンプルを眺めてみた。
…で、XAudio2のサンプルがかなり簡単で面白いなぁと。
static void PlayPCM(string filePath)
{
using(var device = new SlimDX.XAudio2.XAudio2())
using(var master = new SlimDX.XAudio2.MasteringVoice(device))
using(var stream = new SlimDX.Multimedia.WaveStream(filePath))
using(var source = new SlimDX.XAudio2.SourceVoice(device, stream.Format))
using(var buffer = new SlimDX.XAudio2.AudioBuffer())
{
buffer.AudioBytes = (int)stream.Length;
buffer.AudioData = stream;
source.SubmitSourceBuffer(buffer);
source.Start();
Console.WriteLine("[ENTER]で終了します...");
Console.ReadLine();
}
}
無圧縮Waveファイルを再生するコードなんですが、ここまでシンプルです。
抜粋して書き直してるけど殆どマンマです。
デバイス作ってマスター作って、ソースを作るという手順はDirectSoundのBuffer/SecondBufferの感じに似てますね。
AudioBufferにStream渡してる部分はSlimDXの仕様のようで、アンマネージの方だとバイト配列渡してるみたいですね。
マネージ→アンマネージのやりとりの段階でGCHandle使ってるようで、AudioBufferの生存期間には気をつけないといけないようですが。
AudioBufferをSourceVoiceにSubmitSourceBufferして「積む」ことでバッファリングも出来るようですし、
これならストリーミングも簡単に出来そうですし、デコードする部分を適当に作ってやれば他のフォーマットにも対応可能な感じ。
案外いいかもしれませんね。
アンマネージのXAudio2はいろいろ面倒な感じが見受けられましたが、
シンプルに実装されている分SlimDXはかなりいいのかもしれませんね…。
もうちょっと遊んでみよう。
ちゃんと触るのは初めてなのでサンプルを眺めてみた。
…で、XAudio2のサンプルがかなり簡単で面白いなぁと。
static void PlayPCM(string filePath)
{
using(var device = new SlimDX.XAudio2.XAudio2())
using(var master = new SlimDX.XAudio2.MasteringVoice(device))
using(var stream = new SlimDX.Multimedia.WaveStream(filePath))
using(var source = new SlimDX.XAudio2.SourceVoice(device, stream.Format))
using(var buffer = new SlimDX.XAudio2.AudioBuffer())
{
buffer.AudioBytes = (int)stream.Length;
buffer.AudioData = stream;
source.SubmitSourceBuffer(buffer);
source.Start();
Console.WriteLine("[ENTER]で終了します...");
Console.ReadLine();
}
}
無圧縮Waveファイルを再生するコードなんですが、ここまでシンプルです。
抜粋して書き直してるけど殆どマンマです。
デバイス作ってマスター作って、ソースを作るという手順はDirectSoundのBuffer/SecondBufferの感じに似てますね。
AudioBufferにStream渡してる部分はSlimDXの仕様のようで、アンマネージの方だとバイト配列渡してるみたいですね。
マネージ→アンマネージのやりとりの段階でGCHandle使ってるようで、AudioBufferの生存期間には気をつけないといけないようですが。
AudioBufferをSourceVoiceにSubmitSourceBufferして「積む」ことでバッファリングも出来るようですし、
これならストリーミングも簡単に出来そうですし、デコードする部分を適当に作ってやれば他のフォーマットにも対応可能な感じ。
案外いいかもしれませんね。
アンマネージのXAudio2はいろいろ面倒な感じが見受けられましたが、
シンプルに実装されている分SlimDXはかなりいいのかもしれませんね…。
もうちょっと遊んでみよう。
昨日から？GoogleReaderNotifierがおとなしい。
変なので調べてみたらログインでコケてた。
ログインの認証時に https://www.google.com/accounts/ServiceLoginAuth にアクセスするんだけど404が帰ってきてた。
Account Authentication APIを見たところ、アドレスが変わってるような？
とりあえず、アクセス先のアドレスを https://www.google.com/accounts/ClientLogin へ変更。
さらにポストするデータに accountType=HOSTED_OR_GOOGLE を付加してみたら一応ログインは出来たようだ。
…と思ったんだけど、うまくデータを取得出来てない。orz
うーん、どうなってるんだろ…。
不便だから早く対策したい…が……。
◆追記
ログイン処理にミスがあった。
https://www.google.com/accounts/ClientLogin にアクセスしたときに帰ってくる文字のうち、
SIDとLSIDをそれぞれクッキーに食わせてやる必要があるらしい。
その上でGoogle Reader APIアクセスすればOKっぽい。
クッキー処理初めてなのでドキドキですｗ
とりあえず無事に動いたので、GoogleReaderNotifier改を更新しておきます。
変なので調べてみたらログインでコケてた。
ログインの認証時に https://www.google.com/accounts/ServiceLoginAuth にアクセスするんだけど404が帰ってきてた。
Account Authentication APIを見たところ、アドレスが変わってるような？
とりあえず、アクセス先のアドレスを https://www.google.com/accounts/ClientLogin へ変更。
さらにポストするデータに accountType=HOSTED_OR_GOOGLE を付加してみたら一応ログインは出来たようだ。
…と思ったんだけど、うまくデータを取得出来てない。orz
うーん、どうなってるんだろ…。
不便だから早く対策したい…が……。
◆追記
ログイン処理にミスがあった。
https://www.google.com/accounts/ClientLogin にアクセスしたときに帰ってくる文字のうち、
SIDとLSIDをそれぞれクッキーに食わせてやる必要があるらしい。
その上でGoogle Reader APIアクセスすればOKっぽい。
クッキー処理初めてなのでドキドキですｗ
とりあえず無事に動いたので、GoogleReaderNotifier改を更新しておきます。
Tech Days 2009、Silverlight 2によるセッションストリーミング配信開始！
内容はPDC08のラップアラウンドが殆どですが、
最近の事情が入ってるということ、日本語というのがポイントですね。
やっぱり英語だと解りかねる部分がありますし。
ただ、スピーカーにもよるんですが、
大体にして日本人のセッションはグダグダ感がありますね…(汗)。
ただ、個人的にはWPFロードマップのVSMの説明がありがたかったです。
あとXNAとの連携のデモ。ちょっとしかなかったけど。
こういうのをみるとやっぱり.NET4.0や次期WPF、VS2010がお試ししたくなっちゃいますね…。
内容はPDC08のラップアラウンドが殆どですが、
最近の事情が入ってるということ、日本語というのがポイントですね。
やっぱり英語だと解りかねる部分がありますし。
ただ、スピーカーにもよるんですが、
大体にして日本人のセッションはグダグダ感がありますね…(汗)。
ただ、個人的にはWPFロードマップのVSMの説明がありがたかったです。
あとXNAとの連携のデモ。ちょっとしかなかったけど。
こういうのをみるとやっぱり.NET4.0や次期WPF、VS2010がお試ししたくなっちゃいますね…。
Model-View-ViewModel デザイン パターンによる WPF アプリケーション
デザインパターンというとMVCしか知らないんですが、
それとよく似たWPFに非常に相性の良いMVVMというデザインパターンがあるそうです。
コントローラをビュー用モデルとして組み上げる二段構造のモデルが特徴のようで。
基本構造はこんな感じ？
・モデル
データ構造。
データ検証のためのIDataErrorInfoを実装。
・ビュー
ビューモデルをDataContextに。
必要なデータはすべてバインディングで済ませる。
ボタンの押下などもコマンドバインディングで済ませる。
・ビューモデル
モデルを保有し、モデルのブリッジプロパティを公開。
ビューのUI操作に応答するためのコマンドプロパティ(ICommand)を公開。
ビューの状態を保持するためのプロパティも備える。
ビューへ変更を通知するためにINotifyPropertyChangedを実装。
プロパティとモデルのデータ検証のためにIDataErrorInfoを実装。
モデルを保存、復元するためのメソッドを実装。
一番複雑なのはビューモデルですかね。
逆にモデルとビューは非常にすっきりします。
MSDNマガジンのサンプルでは、ICommandの実装はRelayCommandクラスが担当しています。
Composite Application Guidanceで見かけたDelegateCommandと役割は一緒ですね。
要はWPFのCommandで丸投げ出来ればそれで良いと。
基本操作はすべてビューモデルに任せられている感じですかね。
モデルとビューがお互いに意識しなくても大丈夫な予感です。
WCFを使うならモデルに属性つけまくれば良いですね。
データ検証やプロパティ変更通知の義務を、
モデルに持たせるのか、ビューモデルに持たせるのかはちょっと考えた方がよさそう。
INotifyPropertyChangedの実装も考えてやらないと煩雑になるしねぇ。
しかし、良いものを教えてもらった感じです。
デザインパターンというとMVCしか知らないんですが、
それとよく似たWPFに非常に相性の良いMVVMというデザインパターンがあるそうです。
コントローラをビュー用モデルとして組み上げる二段構造のモデルが特徴のようで。
基本構造はこんな感じ？
・モデル
データ構造。
データ検証のためのIDataErrorInfoを実装。
・ビュー
ビューモデルをDataContextに。
必要なデータはすべてバインディングで済ませる。
ボタンの押下などもコマンドバインディングで済ませる。
・ビューモデル
モデルを保有し、モデルのブリッジプロパティを公開。
ビューのUI操作に応答するためのコマンドプロパティ(ICommand)を公開。
ビューの状態を保持するためのプロパティも備える。
ビューへ変更を通知するためにINotifyPropertyChangedを実装。
プロパティとモデルのデータ検証のためにIDataErrorInfoを実装。
モデルを保存、復元するためのメソッドを実装。
一番複雑なのはビューモデルですかね。
逆にモデルとビューは非常にすっきりします。
MSDNマガジンのサンプルでは、ICommandの実装はRelayCommandクラスが担当しています。
Composite Application Guidanceで見かけたDelegateCommandと役割は一緒ですね。
要はWPFのCommandで丸投げ出来ればそれで良いと。
基本操作はすべてビューモデルに任せられている感じですかね。
モデルとビューがお互いに意識しなくても大丈夫な予感です。
WCFを使うならモデルに属性つけまくれば良いですね。
データ検証やプロパティ変更通知の義務を、
モデルに持たせるのか、ビューモデルに持たせるのかはちょっと考えた方がよさそう。
INotifyPropertyChangedの実装も考えてやらないと煩雑になるしねぇ。
しかし、良いものを教えてもらった感じです。
Utilities
- タグ
- カレンダー
- 最近の更新
- Adsense