祝 .NET 5.0 リリース: .NET Core 3.1 からの移行話
祝 .NET 5.0 GA。 Announcing .NET 5.0 C# 9.0 on the record Visual Studio 2019 v16.8 and v16.9 Preview 1 Release Today Announcing ASP.NET Core in .NET 5 Visual Studio 2019 16.8 リリースノート Visual Studio 2019 18.9 Preview 1 リリースノート .NET Conf 2019 - Day 1 ライブ配信 一応注釈なんですが、 .NET は以下のような状態です。 .NET 5.0 からは単に「.NET」になります .NET Framework, Standard, Core の統合結果です TargetFramework 名、 net5.0 で、 netstandard2.1 と netcorea
C# で、同じソースコードから常に同じバイナリを生成する
昔、gist にだけ置いてて、そういえばブログに書いてなかったものを思い出したので書いておくことに。 (一応、部分的には言及したことがあるんですけど、ちゃんとした話はしたことがなかったはず。) 決定論的ビルド 3年くらい前まで、C# コードをコンパイルすると、ソースコードを一切書き換えていなくても、生成結果の exe/dll や pdb のバイナリが変化していました(決定性(deteminism)がない)。 原因は以下の2つです。 バイナリ中に埋め込まれる GUID にタイムスタンプと乱数から生成される値を使っていた デバッグ用のファイル情報がフルパスで埋め込まれていた GUID の方はタイムスタンプと乱数なので本当に致命的で、ローカルで再コンパイルしても毎回バイナリが変化していました。 フルパスの方は基本的には pdb (デバッグ用シンボル情報)だけの問題なんですが、 exe/dll で
✓DO、X DO NOT の誤訳事案
だいぶ炎上してる例のあれ doの意味が全体的に逆になっています。 #118 対応ミスってるとはいえさすがにかわいそうなレベルでいいがかり付けられてる感じもするのでちょっと補足を。 元々の問題 マイクロソフトの機械翻訳がよくやらかすのはいつものことなんですが。 今回は何をやらかしたかというと、よくある ✓DO: 〇〇してください X DO NOT: 〇〇はしないでください みたいなやつを、DOもDO NOTもどっちも「しないで」と訳してしまっているという問題。 「しないで」も不自然だし、ましてDOの方は真逆の意味になっているという誤訳。 どうしてこうなる… みたいな気持ちはもちろんあるものの、こういう「普通の文章」になっていない部分の単語ってのは、機械翻訳では一番ミスを起こしがちな部分です。 たぶん、原文の時点で何らかのアノテーションでも付けておくとかしないと、今後も同様の誤訳は起こりまくる
プロジェクトの分割
プログラムや、プログラムを作るための部品は「プロジェクト」という単位で管理します。 ここでは、プロジェクトという単位に分ける動機などについて説明していきます。 概要 依存関係 補足: .NETのソースコード ファイル配置 プロジェクト プロジェクトの成果物 プロジェクトの分け方 いろんなプログラムから1つの部品を使う いろんな環境から1つの部品を使う アセンブリ 概要 プロジェクト管理で触れたように、プログラムや、プログラムを作るための部品は「プロジェクト」という単位で管理します。 依存関係を考える最小単位がプロジェクト .NETの場合、プロジェクトの成果物は「アセンブリ」(dllもしくはexe) いろんなプログラム、いろんな環境で使える部分を別プロジェクトに切り出して使う 依存関係 プログラムをちゃんと部品として分けて作って、その部品をいろんなプログラムから再利用するためには、依存関係の
.NET Coreへの移植
twitterで流れてきてて、気になったやつ。 Porting to .NET Core 内容的には、 フィードバック募集中なのでお願いします .NET Coreは今、ASP.NET、UWP、コンソール アプリに使えるけども、.NET Frameworkからの移植のモチベーションはそれぞれ何か .NET Framework と .NET Coreの関係・差分 意図して.NET Coreには取り込まなかったものがちらほらあるから注意 .NET Core化するかどうか、単純に時間的な不足で検討してないものもちらほら 特にフィードバックほしいのはここ。ほしいかどうか、優先度付けしたい 移植にあたってのコツ みたいなの。 以下、さらっと概要。 何を移植するか ASP.NET 移植する理由: .NET Coreならクロスプラットフォーム。MacやLinuxで動く マシン全体に対するインストールじゃな
新しい csproj 形式
Visual Studio 2017で、csproj 形式が新しくなりました。 背景としては、 一時期、脱msbuildをしようとしてた -脱msbuildのついでに、csprojを辞めて、project.json 形式にプロジェクト設定全部入れようとしてた時期があった 結局、msbuildに戻ったけども、既存のcsprojをもっとシンプルにしたいという要件だけが残った というものです。過渡期に関しては昔書いたブログ参照: .csproj + project.json 「project.json辞めます」の意味 最近、やっと新形式のcsprojの扱いに慣れてきたのでブログに書き残しておきます。 サンプル: https://github.com/ufcpp/UfcppSample/tree/master/Demo/2017/NewCsproj 新形式 これまで、Visual StudioでC
プログラミング言語における文字コードの話
世の中がほぼUnicode前提になってめでたしめでたし。とはいかなかった現実の話。 String型でできる文字列処理とか、ソースコード自体、特に識別子で使える文字とか。 軽くおさらい: Unicode まあいろんなところでいろんな人が書いてると思うのでさらっと概要だけ。 Unicodeは、元々、「65,536文字あれば十分だろ」とかいう幻想の元、2バイト固定長の文字コードとして作られていました。 もちろん足りなくて、ビット数を拡張。基本が2バイトのままでこの拡張した分を取り扱えるようにしたのが今のUTF-16で、拡張分は2文字分(4バイト)を使って表現。 この、2文字分使って1文字を表すやつのことをサロゲートペア(surrogate pair: 代理対)と呼びます。 あと、ASCII文字も2バイトになるのを欧米人が嫌って、ASCII文字はASCIIコードのまま、逆に漢字・ひらがな・カタカナ
今更ながら LaTeX
概要 今の世の中、文書ファイルの標準的なフォーマットと言えばMicrosoftのWordドキュメントかAdobeのPDFでしょうか。 ウェブ上に公開するにしてもXMLかHTMLが一般的です。 そんな中LaTeXが根強く生き残ってるのは、アンチM$な人たちがWordを使わないのと、ただであることと、あと数式を書くならやっぱりLaTeXが一番楽だからでしょうか。 ちなみに、僕がLaTeX使ってる理由は3つ目の理由、つまり数式を使いたいからです。 とはいえ、LaTeXっていうとリファレンス本片手に持ちながらでないととてもじゃないけれども使えません。 たいてい、家でLaTeXを使うときには本を片手にLaTeXを使っているのですが、 家でも研究室でもLaTeXを使いたいけれでも本は1冊しかなくて困っています。 そういうわけでネット上でLaTeX小ネタ集を作って家からも研究室からも見れるようにしようと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
