JSIL - .NET to JavaScript compiler
JSIL is a compiler that transforms .NET applications and libraries from their native executable format - CIL bytecode - into standards-compliant, cross-browser JavaScript. You can take this JavaScript and run it in a web browser or any other modern JavaScript runtime. Unlike other cross-compiler tools targeting JavaScript, JSIL produces easy-to-debug JavaScript while still maintaining the behavior
.NET Framework のセキュリティ更新プログラムの整理 - 日本のセキュリティチーム - Site Home - TechNet Blogs
If you were looking for MSDN or TechNet blogs, please know that MSDN and TechNet blog sites have been retired, and blog content has been migrated and archived here. How to use this site Archived blogs are grouped alphabetically by the initial letter of the blog name. Select the initial letter from the TOC to see the full list of the blogs. You can also type the name of the blog or the title of the
Node.net – Node.js implemented in Javascript on the .NET runtime
Node.net – Node.js implemented in Javascript on the .NET runtime with 46 comments – Update: This has gotten more attention after I posted this and I haven’t gotten around to doing another post. I started working on a v8 port of this after the initial JScript version just to see if it was feasible after I got some comments suggesting using v8 instead of JScript. There is currently a really rough ve
Big Sky :: JScript.NETでスレッド
JScript.NETはMicrosoftが.NET Framework向けに拡張したJavasSriptで、Common Language Runtime(CLR)上で動作するJavaScript実装です。 CLR上ではC#、VB.NET等が動作しますが、JScript.NETは言語がJavaScriptという事もあって実はC#やVB.NET等と同等に使えない機能がいくらかあります。 JavaScriptは動的言語です。オブジェクトにプロパティを生やしてメソッドにしたり、prototypeを弄ったり、eval()で関数を生成したりも出来ます。つまりコンパイルするとは言えど、型が動的に変えられる言語です。 その為、.NET Frameworkの機能の一つであるDelegateが使えません。.NET FrameworkのThreadはDelegateという関数型拘束によりスレッドを安全に呼び
『PathTooLongException - 32000文字のまやかし』
レアケースだと思われるが、フルパスが260文字を超えるケースでのファイルコピーが発生したときにどうするか、という問題に取り組んでいる。 NTファイルシステム上は32000まで行けるらしいが、なぜか.Netでは行き届かず、260文字を超える場合はPathTooLongExceptionを吐く。 .Netとしての回避策はない。。。 とりあえずコピー周りだけさして、あとは.NETで出来るだけ対応しようと思い、 [DllImport("kernel32.dll", EntryPoint = "CopyFileW", SetLastError = true, CharSet = CharSet.Unicode, ExactSpelling = true, CallingConvention = CallingConvention.StdCall)] public static extern bool
W3CのDTDを取りに行きすぎるとBANされる | 水無月ばけらのえび日記
Yet we receive a surprisingly large number of requests for such resources: up to 130 million requests per day, with periods of sustained bandwidth usage of 350Mbps, for resources that haven't changed in years. W3CのサイトにおかれているDTDなどに対して、1日に1億3千万回ほどのアクセスがあるそうで。 たとえば、.NET FrameworkのXmlDocumentでXHTMLを読むなんてシチュエーションはありがちだと思いますが、XmlResolver = nullを指定せずにそのまま使うと、いちいちDTDにアクセスしに行ってしまいます。世界中でそういうことをされると、まあ、大変です
愛々問題をざっと調べてみた - ものがたり(旧)
id:kkamegawa:20081113:p1 なんてネタがあることをついったで教えてもらったので参戦してみるお。 以下とりあえずの実験に基づく考察。結論はまだ出ていません。 String.IndexOf()は、culture sensitivityのオプションを問わず、System.Char配列におけるインデックスを返さなければならないのだから、1を返すのは仕様ではなくバグ。 StringComparison.Ordinalでは問題ない。（当然か） 日本語ロケールでのみ発生する問題。CultureInfo.InvariantCultureやzh-CNでは問題なし。 .NET 1.1では問題なし。（確認） .NET 1.1で返されるSortKeyの値と、.NET 2.0で返されるSortKeyの値は同一。 ということは、ソートテーブルやnlpファイルに基づくculture depende
Re: 続:.NET FrameworkのCultureと"々" - biac の それさえもおそらくは幸せな日々@nifty
おくればせながら、 元ネタをよーやく検証しました。 ( もちろん ! ) 再現できたので、 Visual Studio & .Net Framework プロダクト フィードバック センターに vote / 検証 / 回避策 それぞれ ++ してきました。 > 一日でトップアクティブバグレポートに躍り出るとは思いませんでした。 私が出した WPF ネタが長らくトップだったのに。 残念じゃ～ (^^; > なんかわざとやっているのかと思います。 わざとかどうかは別として、 とりあえずは IndexOf() だけみたいですね。 StringComparison を指定できるその他のメソッド Compare(), LastIndexOf(), StartsWith() といったあたりは、 "愛々" では大丈夫そうでした。 → テストコード UnitTest1.cs ( 7,192 バイト, VS
愛が重ならない.NET Framework 2.0 - kkamegawa's weblog
なんというタイトルだと思われるかもしれませんが。 Console.WriteLine("{0}", "愛々,1,2,3".IndexOf(",")); これを実行してみましょう。結果は?なんと1です。PowerShellでも(当然)同じ結果になります。 $a = "愛々,1,2,3" $a.indexof(",") 1々がいけないのかと思ったのですが、これは2になります。 $a = "同々,1,2,3" $a.indexof(",") 2面白いことに、.NET Framework 3.5SP1(確認してないけど.NET Framework 2.0以降)ではこうなりますが、.NET Framework 1.1(Visual Studio .NET 2003)では2が返却されます。OS問わないのかもしれません。そこでこんなプログラムを作ってみました。とりあえずCJK統合漢字の範囲でどれだけ判定
.NET Framework 1.0 から .NET Framework 3.5 への移行(20071029) - Days with Microsoft Platform - Site Home - MSDN Blogs
Microsoft Visual Studio 担当マーケター 新村の Blog です。 Visual Studio Adevent Calender 2012 - Visual Studio が対応するアプリケーション タイプ 皆さんこんにちは。日本マイクロソフトで Visual Studio の製品マーケティングを担当している新村です。 Visual Studio Adevent Calender にご参加いただいた... Author: Takeshi Shinmura Date: 12/24/2012 アプリ紹介 「電撃もくろっく for Windows 8」 (20121102) 皆さんこんにちは。 急に寒くなってきましたが、風邪などひかれておりませんでしょうか? さて、Windows 8 も発売されて1週間がたちましたが、皆さんもうお使いいただいているでしょうか?... Aut
ScottGu's Blog - Releasing the Source Code for the .NET Framework Libraries
One of the things my team has been working to enable has been the ability for .NET developers to download and browse the source code of the .NET Framework libraries, and to easily enable debugging support in them. Today I'm excited to announce that we'll be providing this with the .NET 3.5 and VS 2008 release later this year. We'll begin by offering the source code (with source file comments inclu
PE ファイルとしてみたアセンブリ [合致+2][異種+4] - is BUG Ready ?
PE ファイルの構成については詳しくない*1んだけども、.NET のアセンブリは PE ファイルとしてみると、 ヘッダ部のフラグ設定が異なる スタートアップルーチンが少し特殊 .TEXT セクションがない（リソース DLL のように） .CLR セクションが配置されている といったところが代表的な違いだが、このような構造をもつ .NET アセンブリは、まるでクラシカル DLL であるかのように LoadLibrary 系の API によって読み込むこともできる。 上記をふまえて、 .NET アセンブリは .TEXT セクションを持つことができるか？ .NET アセンブリは exports を持つことができるか？ クラシカル DLL は、.CLR セクションを持つことができるか？ .NET アセンブリのスタートアップルーチンをクラシカル DLL から呼び出せるか？ という点について確認してみ
![PE ファイルとしてみたアセンブリ [合致+2][異種+4] - is BUG Ready ?](https://cdn-ak-scissors.b.st-hatena.com/image/square/05ffe39eb0b04b3f1ac2ec4977d76fdef26fef40/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127018810972%2F17680117127018911654%2F1554878749)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
C#/.NETがやっていること 第二版
C#を使ってDLL内の関数を動的に呼び出す方法
Fiddler HTTP Debugger - Fiddler