4月 192019
 

.NET Core 3.0 Preview 4 で HttpClient の HTTP/2 サポートが追加されたようですね。
Announcing .NET Core 3 Preview 4 | .NET Blog

今までの .NET Standard では SslStream 自体が HTTP/2 の事実上必須な機能(ALPN)に対応しておらず、.NET Standard 2.1 でようやくサポートされる見込みだったため、どうやらちゃんとくるようで一安心というところです。
(HttpClient についてはこれのせいかは不明ですが…… SocketsHttpHandler が HTTP/2 対応していなかったのは確か)

しかしながら .NET Framework 4.8 の方は .NET Standard 2.0 止まりになることになっているので、HTTP/2 サポートは今後あるのかどうかすら怪しいですね……

Given many of the API additions in .NET Standard 2.1 require runtime changes in order to be meaningful, .NET Framework 4.8 will remain on .NET Standard 2.0 rather than implement .NET Standard 2.1.
Announcing .NET Standard 2.1 | .NET Blog

とはいえ .NET Standard はあくまでも API 標準を定めただけで実装は各プラットフォーム依存ですから、動くようになる可能性はあるかも?

とりあえず .NET Framework は 4.8 の時点では HttpClient + HttpClientHandler では動作しそうにありません。
BCL 以外でなら WinHttpHandler を使い、HttpRequestMessage のバージョンを明示的に指定することで、利用できます(Win10 1607↑ + .NET FW 4.6↑ に限る)。
参考: How to make the .net HttpClient use http 2.0?

実は Core 2.0 までも Windows 環境に限れば WinHttpHandler に丸投げしていたようで、HttpClient で HTTP/2 が動作します。
Core 2.1 以降 SocketsHttpHandler に移行し、環境依存を減らした為、HTTP/2 に一時的に非対応となっていたようです。

HttpClient の HTTP/2 対応

  • .NET Framework
    • HttpClientHandler では利用不可
    • WinHttpHandler (要NuGet & Win10 1607)を利用すれば利用可
  • .NET Core
    • ~2.0 : Win10 1607~のみ利用可?
      • WinHttpHandler を使ってる模様
    • 2.1~2.2 : 利用不可
      • SocketsHttpHandler に移行したため
      • ただし WinHttpHandler を利用するよう構成すれば Windows では利用可
    • 3.0~ : 利用可
      • SocketsHttpHandler の HTTP/2 対応?

Continue reading »

4月 192019
 

英語版(ndp48-devpack-enu.exe とか)を入れれば直る。

各国語版は Language Pack でしかない。
にも関わらず、少なくとも .NET Framework 4.8 時点ではブラウザの言語設定を見て勝手に言語選択されて Language Pack (ndp48-devpack-jpn.exe とか)がダウンロードされてしまう。
ので一旦ブラウザの言語設定を英語にし、英語版をダウンロードしましょう。

6月 272017
 


新しい csproj でこれをやる話。

結論

VSProjectSystem/automatic_DependentUpon_wireup.md at master · Microsoft/VSProjectSystem · GitHub
これ参照。
地味にめんどい。

Static dependency

地道に指定する方法の例。

[xml title=”StaticDependency.csproj”]


netstandard1.4



Hoge.cs


Fuga\Fuga.cs


[/xml]

Dynamic file dependency

ルールを作って動的に解析されるようにする方法の例。

[xml title=”DynamicDependency.csproj”]


netstandard1.4





[/xml]

[xml title=”ProjectItemsSchema.xaml”]




[/xml]

12月 022015
 

概要

一般的に、private setter を持つプロパティを TwoWay Binding すると、InvalidOperationException が発生して死ぬ。
しかし、ターゲットフレームワークが 4.5 の時のみ、何事もなかったかのように動作する。なにそれ……

※ OneWayToSource の場合も同様。

Continue reading »

9月 162015
 

Metro.cs #1ぐらばくセッションの後半として喋ったやつです。
実装と言いつつ概要レベルですが。
時間が短かったのもあって雰囲気くらいしか分からなかったのではないかという予感がしているので、詳しいことはソースコードを見つつテストコードをデバッグ実行しながら確かめてみてください。。

Continue reading »

9月 032015
 

条件をよく忘れるのでメモ。

条件

  • ItemsPanelVirtualizingPanel であること
    • だいたい VirtualizingStackPanel
  • VirtualizingPanel.IsVirtualizingTrue (既定値) であること
  • ScrollViewer.CanContentScrollTrue であること
    • 既定値は False
  • グループ化してる場合は VirtualizingPanel.IsVirtualizingWhenGroupingTrue

ListView なんかは初めから仮想化有効だけど、Template 弄る時なんかに無効化されてしまったりするので注意

既定値が気に食わないやつとか

  • VirtualizingPanel.VirtualizationModeRecycling
    • 使いまわしたほうがパフォーマンス良い
  • VirtualizingPanel.ScrollUnitPixel
    • 既定値の Item はスクロールしてる感乏しい
    • タッチだとカクカクしてなおさらキモい

サンプル

[xml]




















[/xml]
8月 112015
 

とりあえず簡単に。
ちゃんとしたのはそのうち気が向いたら書くかも。
でも既存開発者はわかってる人たちだからこれでも十分な気が……

新規開発も追々。
むしろちゃんと書くべきはこっち。。

KanColleViewer 4.0

KanColleViewer 4.0 がリリースされましたが、プラグインシステムが刷新されたため、3.x のプラグインは利用できなくなりました。

Release version 4.0 · Grabacr07/KanColleViewer

プラグイン システムの刷新 (version 3.8.2 またはそれ以前に向けて作られたプラグインは使用できなくなります)

というわけで、3.x プラグインをどう移行すればいいかを 雑に 簡単に説明します。

実際のコードは、本体に付属しているプラグインの実装などを参考にすると良いでしょう。

Continue reading »

7月 212015
 

仕様的な

  • Analyzer を使う際、Analyzer の依存アセンブリも Analyzer として参照追加する必要がある
    • 通常の参照追加じゃダメ
  • NuGet を用いた Analyzer のインストールは install.ps1 で行われる
  • RTM 版テンプレートの install.ps1 では、nupkg 解凍直下の analyzers ディレクトリにある dll を Analyzer として登録する
  • ので、上手いことそこにアセンブリが配置されるよう nuspec を書く必要がある
  • だがどうやら lib 配下以外に配置すると pack 時に怒られるので、-NoPackageAnalysis オプションが必要
  • この仕様では、Analyzer の依存アセンブリは同梱配布しかできないのではないか疑惑 (PowerShell頑張ればなんとかなるんだろうか)

とりあえずどうすればいいのか

  • csproj を使って nuget pack する前提の nuspec を書くパターン
  • bin\$configuration$\ 直下の dll を全部 analyzers ディレクトリに突っ込むようにする(Analyzer 開発用アセンブリは除外)
  • Analyzer が依存してるアセンブリの「ローカルにコピー」を True にして含まれるようにする
  • プロジェクト新規作成時点で指定されている packages.config の中身は開発時しか使わないので developmentDependency=”true” にして利用時の依存を除外

こんな感じ。

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2011/08/nuspec.xsd">
  <metadata>
    <id>$id$</id>
    <title>$title$</title>
    <version>$version$</version>
    <authors>$author$</authors>
    <owners>$author$</owners>
    <licenseUrl>http://LICENSE_URL_HERE_OR_DELETE_THIS_LINE</licenseUrl>
    <projectUrl>http://PROJECT_URL_HERE_OR_DELETE_THIS_LINE</projectUrl>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>$description$</description>
    <language>ja-JP</language>
    <tags>analyzers</tags>
    <frameworkAssemblies>
    </frameworkAssemblies>
    <dependencies>
    </dependencies>
  </metadata>
  <files>
    <file src="bin\$configuration$\*.dll" target="analyzers\" exclude="**\Microsoft.CodeAnalysis.*;**\System.Collections.Immutable.*;**\System.Reflection.Metadata.*;**\System.Composition.*" />
    <file src="tools\*.ps1" target="tools\" />
  </files>
</package>

で、こう

nuget pack Hoge.csproj -NoPackageAnalysis -Properties Configuration=Release
7月 102015
 

参照 : Damir’s Corner – Quick Guide to Unit Testing Diagnostic Analyzers

Visual Studio 2015 RC にて、.NET Compiler Platform SDK Templates for RC の「Analyzer with Code Fix」テンプレートで Analyzer 用のプロジェクトを作成すると、自動的にテストプロジェクトも生成されます。

んでもってこれを使ってテストコードを書くわけですが、どうやらここでテストコードに与えるソース文字列がコンパイル通らないコードだとテストに失敗することがあるようです。

で、アセンブリ参照が足りない場合なんかも同様にコケるわけですが、テストプロジェクトにアセンブリ参照を追加しても残念ながら参照してくれません。

ではどうすれば良いかというと、テストプロジェクトの Helpers/DiagnosticVerifier.Helper.cs 内の CreateProject メソッドにアセンブリ参照を追加している箇所があるので、そこに追加します。

[csharp mark=”4-7,23-24″]
public abstract partial class DiagnosticVerifier
{
//中略
private static readonly MetadataReference KanColleViewerCompositionReference
= MetadataReference.CreateFromAssembly(typeof(Grabacr07.KanColleViewer.Composition.IPlugin).Assembly);
private static readonly MetadataReference SystemComponentModelCompositionReference
= MetadataReference.CreateFromAssembly(typeof(System.ComponentModel.Composition.ExportAttribute).Assembly);
//中略
private static Project CreateProject(string[] sources, string language = LanguageNames.CSharp)
{
string fileNamePrefix = DefaultFilePathPrefix;
string fileExt = language == LanguageNames.CSharp ? CSharpDefaultFileExt : VisualBasicDefaultExt;

var projectId = ProjectId.CreateNewId(debugName: TestProjectName);

var solution = new AdhocWorkspace()
.CurrentSolution
.AddProject(projectId, TestProjectName, TestProjectName, language)
.AddMetadataReference(projectId, CorlibReference)
.AddMetadataReference(projectId, SystemCoreReference)
.AddMetadataReference(projectId, CSharpSymbolsReference)
.AddMetadataReference(projectId, CodeAnalysisReference)
.AddMetadataReference(projectId, KanColleViewerCompositionReference)
.AddMetadataReference(projectId, SystemComponentModelCompositionReference)
;

int count = 0;
foreach (var source in sources)
{
var newFileName = fileNamePrefix + count + “.” + fileExt;
var documentId = DocumentId.CreateNewId(projectId, debugName: newFileName);
solution = solution.AddDocument(documentId, newFileName, SourceText.From(source));
count++;
}
return solution.GetProject(projectId);
}
//以下略
[/csharp]

これでアセンブリが参照されるようになり、テストが通るようになります。

これは RC 版でのテンプレートの問題なので、もしかしたら将来変更されるかもしれませんね。