.NET 4.5がリリースされてからほぼ1年が経ちました。しかし、Microsoft の最近のリリースのほとんどでは、.NET 開発者とのコミュニケーションの問題により、開発者が知っている機能は 1 つまたは 2 つだけであり、他の機能は MSDN に留まり、簡単なドキュメントの形でしか存在していないことが明らかになりました。
たとえば、.NET 開発者に .NETFrameworkkernel の新機能について尋ねると、ほとんどの開発者は async と await とだけ答えるでしょう (少なくとも私が話をした人たちはこれらの機能についてしか話していません )。
さらに、すべての新機能を理解するのは困難です。これらの機能は、現在開発中の作業にとっては思ったほど興味深いものではない可能性があるためです。
ということで、この記事では、.NET 4.5 カーネルで私が気に入っている 5 つの機能について触れたいと思います。もちろん、これは私の好みであり、あなたの好みではないかもしれません。しかし、これらの機能を選択するときは、より大規模な .NET コミュニティについても考慮しており、その期待に応えられることを願っています。
ヒント: この記事では、ASP.NET、WCF、WPF、WWF などの新機能については説明しません。私はカーネルの新機能についてのみ話しました。
この機能は過剰に宣伝されており、すべての .NET エバンジェリストがそれについて話しています。しかし、これは依然として私が気に入っていることであり、ここからわずか数行でその理由がわかるでしょう。
Async と await は、タスク (スレッド) が終了したときにコードのどこに制御を戻すかをマークするマーカーです。
次のコードを通して上記の文の意味を理解してみましょう。次のコードの流れを理解すると、
Static void main() は最初から Method() メソッドを呼び出します。
Method() メソッドは LongTask という名前のタスク (スレッド) を生成し、スレッドは 10 秒間待機します。
同時に、タスクを呼び出した後、制御は Method() メソッドに戻り、残りのコードの実行を継続します。言い換えれば、LongTask は、マルチスレッド (Task.Run...) と呼ばれたとおり、まだ実行されています。たとえば、10 秒待つと、Method() メソッドの残りの部分が実行されます。
今度は、同じシナリオで、ステップ 3 を別の方法で実行したいとします。 LongTask() の実行が完了した後、制御が Method メソッドに戻って次のコードを実行する必要があります。 「async」および「await」キーワードは、上記の機能を実現するのに役立ちます。
キーワード「async」と「await」について覚えておくべき 3 つの重要なポイントを次に示します。
async と await は 1 組のキーワードです。これらを単独で使用することはできません。
メソッドに非同期的に適用されます。このキーワードはフラグであり、メソッドに wait キーワードがあることを意味します。
wait キーワードは、タスクが実行を再開する場所をマークします。したがって、このキーワードは常にタスクに関連付けられています。
以下は、先ほど説明したコードの修正版で、async と await を適用しています。他のすべてのステップは上記のとおりですが、「ステップ 2」が完了した後に「ステップ 3」が実行されます。簡単に言えば、タスクが完了すると、コントロールは Method() メソッドに戻ります。
「async」と「await」について読んだところで、質問させてください。上記のコードは、Task.Wait または Task.ContinueWith を通じて実装することもできますが、両者の違いは何でしょうか?この質問は宿題として残しておきます。
Zip は、最も受け入れられているファイル形式の 1 つです。 Zip 形式は、ほとんどすべてのオペレーティング システムでいくつかの組み込み名でサポートされています。
Windowsオペレーティングシステムでは、「圧縮ファイル」という名前で実装されています。
MAC OSでは「Document Utility」という名前で実装されています。
現在、.NET には、Zip 圧縮を実行するためのサポートが組み込まれていません。多くの開発者は、「DotnetZip」などのサードパーティ コンポーネントを使用しています。 .NET 4.5 では、Zip 属性 がフレームワーク自体に組み込まれ、System.IO.Compression の 名前空間 に組み込まれます。
最初のステップでは、2 つの名前空間を 参照する必要があります:
using System.IO.Compression;
ZipFile.CreateFromDirectory(@"D:\data",@"D:\data.zip");
ZipFile.ExtractToDirectory(@"D:\data.zip", @"D:\data\unzip");
string をデプロイする可能性があります。
この問題に対する適切な解決策は、正規表現の実行時にタイムアウトを設定することです。幸いなことに、.NET 4.5 では、次のコードに示すようにタイムアウト プロパティを定義できます。したがって、悪意のある文字列を受信した場合でも、アプリケーションは永久にループ で実行されなくなります。
try
{
var regEx = new Regex(@”^(\d+)+$”, RegexOptions.Singleline, TimeSpan.FromSeconds(2));
var match = regEx.Match(“123453109839109283090492309480329489812093809x”);
}
catch (RegexMatchTimeoutException ex)
{
Console.WriteLine(“Regex Timeout”);
}
为了创建“配置文件”这个文件，首先你需要引入System.Runtime命名空间。然后你可以调用静态类ProfileOptimization的SetProfileRoot和StartProfile方法。现在当应用启动后台JIT，它将会读取配置文件并且在后台编译启动方法从而降低启动时间。
using System.Runtime;
// Call the Setprofilerroot and Startprofile method
ProfileOptimization.SetProfileRoot(@"D:\ProfileFile");
ProfileOptimization.StartProfile("ProfileFile");重要提示：ASP.NET 4.5和Silverlight 5应用默认支持Profileoptimization。所以上述代码在这些技术中无需编写。
垃圾回收在.NET应用中是一项真正繁重的任务。当是ASP.NET应用的时候，它变得更繁重。ASP.NET应用在服务器运行，许多客户端向服务器发送请求从而产生对象负荷，使得垃圾回收确实努力清理不需要的对象。
在.NET4.0中，当垃圾回收运行清理的时候，所有的应用程序线程都暂停了。在上图中你可以看到我们有3个应用程序线程在执行。有两个垃圾回收运行在不同的线程上。一个垃圾回收线程对应一个逻辑处理器。现在应用程序线程运行并执行它们的任务，伴随着这些应用程序线程的执行它们也创建了操作对象。
在某个时间点，后台垃圾回收运行开始清理。当这些垃圾回收开始清理的时候，它们暂停了所有的应用程序线程。这使得服务器/应用程序在那一刻不响应了。
为了克服上述问题，服务器垃圾回收被引进了。在服务器垃圾回收机制中多创建了一个运行在后台的线程。这个线程在后台运行并持续清理2代对象（关于垃圾回收0,1和2代的视频）从而降低主垃圾回收线程的开销。由于双垃圾回收线程的执行，主应用程序线程很少被暂停，进而增加了应用程序吞吐量。为了使用服务器垃圾回收，我们需要使用gcServer XML标签并且将它置为true。
<configuration> <runtime> <gcserver></gcserver> </runtime> </configuration>
设置默认应用程序域的区域性
在上一个版本的.NET中如果我想设置区域性那么我需要在每个线程中设置。下面的示例程序演示了在线程级别设置区域性的痛苦。当我们有大量多线程应用程序的时候这是真正的痛苦。
CultureInfo cul = new CultureInfo(strCulture); Thread.CurrentThread.CurrentCulture = cul; Thread.CurrentThread.CurrentUICulture = cul;
在4.5中我们可以在应用程序域级别设置区域性并且所有在这个应用程序域当中的线程都会继承这个区域性。下面就是如何实现DefaultThreadCurrentCulture的示例代码。
CultureInfo culture = CultureInfo.CreateSpecificCulture("fr-FR");
CultureInfo.DefaultThreadCurrentCulture = culture;数组支持超过2GB容量
我不确定在什么样的情景下我们会需要2GB的容器。所以我个人并不清楚我们将在哪用到这个特性。如果我曾需要如此之大的容器我会把它分解成小份。但我确信在框架中启用此功能应该有个很好的理由。
控制台支持Unicode编码
我把这个特性留在讨论范围之外是因为非常少的人用控制台程序工作。我曾见过有人把控制台用于学术目的。总而言之，我们现在也对控制台应用有了Unicode编码支持。
引用
http://msdn.microsoft.com/en-us/library/ms171868.aspx
Mr Sukesh marla的精彩文章ASP.NET 4.5 new features
当你有空的时候，一定来看看我的网站 www.questpond.com关于.NET4.5面试问和答，我已经在这方面有了不少努力。
以上が.NET Framework 4.5 の 5 つの優れた機能の共有の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
