It has been almost a year since .NET 4.5 was released. But with most of Microsoft's recent releases, conversations with .NET developers have shown that developers only know about one or two features, and other features just stay on MSDN and exist in the form of simple documentation.
For example, when you ask a .NET developer what’s new in the .NET Framework kernel, most of them will just say async and await (at least with me The people we talked to only talked about these properties).
In addition, it is difficult to understand all the new features. Because these features may not be as interesting as they sound for the work you are currently developing.
So in this article I want to mention 5 features that I like in .NET 4.5 kernel. Of course, this may just be my preference and not yours. But what I do is I also think about the larger .NET community when I choose these features, and I hope I meet that expectation.
Tip: This article does not discuss new features in ASP.NET, WCF, WPF, WWF, etc. I only talked about the new features of the kernel.
This feature has been over-hyped and every .NET evangelist talks about it. But this is still what I like and you'll see why it's only a few lines from here.
Async and await are markers that mark where control should be restored to the code when the task (thread) ends.
Let’s try to figure out the meaning of the above statement through the following code. If you understand the flow of the following code:
Static void main() calls the Method() method from the beginning.
The Method() method generates a task (thread) named LongTask, and the thread will wait for 10 seconds.
At the same time, after calling the task, control returns to the Method() method to continue executing the remaining code. In other words, LongTask is still running just as it was called multi-threaded (Task.Run...). For example, wait 10 seconds and the rest of the Method() method is executed.
Now in the same situation, we want step 3 to be performed differently. We want that after the LongTask() execution is completed, control should return to the Method method to execute the next code. The "async" and "await" keywords can help achieve the above functions.
Here are three key points to remember about the keywords "async" and "await":
Async and await are A pair of keywords. You cannot use them independently.
Asynchronously applies to methods. This keyword is a flag, which means that the method will have a wait keyword.
The wait keyword marks the location where the task resumes execution. So you always find this keyword associated with Task.
Below is a revised version of the code discussed earlier, where we apply async and await. All other steps remain as described above, but "Step 3" will be performed after "Step 2" is completed. Simply put, the control returns to the Method() method after the task is completed.
Now that you’ve read about “async” and “await”, let me ask a question. The above code can also be implemented through Task.Wait or Task.ContinueWith, so what is the difference between them? I leave this question as homework for you.
Zip is one of the most accepted file formats. The Zip format is supported by almost all operating systems under some built-in names.
In Windows operating systems, it is implemented under the name "Compressed File".
In MAC operating systems, it is implemented under the name "Document Utility".
Currently in .NET we have no built-in support for performing Zip compression. Many developers use third-party components such as "DotnetZip". In .NET 4.5, the Zip attribute is built into the framework itself, built into the namespace of System.IO.Compression.
In the first step you need to reference two namespaces:
System.IO.Compression.FileSystem
System.IO.Compression
Next, reference the following two namespaces:
using System.IO.Compression;
If you want to compress files from a folder you can call as shown below CreateFromDirectoryFunction.
ZipFile.CreateFromDirectory(@"D:\data",@"D:\data.zip");
If you want to decompress, you can call the ExtractToDirectory function as shown in the following code.
ZipFile.ExtractToDirectory(@"D:\data.zip", @"D:\data\unzip");
"Regular expression" has always been the preferred way to do verification . If you are new to regular expressions, see Regular Expressions where I explain how regular expressions perform. But it is precisely because of the typical logical parsing of regular expressions that they are exposed to DOS attacks. Let's try to understand what I just said.
As an example please consider this regular expression - "^(\d+)$". This regular expression indicates that there can only be numbers. You can also see the regular expression symbol diagram, which shows how the regular expression will be evaluated. Now let us assume that we want to verify "123456X". This will have 6 paths as shown in the image below.
But if we add one more number, there will be 7 paths. In other words, as the character length increases, the regular expression will take more time to execute. That is, evaluation time scales linearly with character length.
Now let us change the previously defined regular expression from "^(\d+)$" to "^(\d+)+$". If you look at the regex notation diagram it's quite complex. If we now try to verify "123456X", there will be 32 paths. If you add one more character, the number of paths will increase to 64.
In other words, the time overhead in the above regular expression is exponentially related to the number of characters.
Now you may be asking, does this matter? The linearly rising evaluation time can be exploited by hackers to conduct DOS (denial of service) attacks. They can deploy a string that is long and long enough to make your application hang forever.
The appropriate solution to this problem is to set a timeout on regular expression execution. The good news is that in .NET 4.5 you can define a timeout property as shown in the following code. So if you receive any malicious string, the application will not execute in a loop forever.
try { var regEx = new Regex(@”^(\d+)+$”, RegexOptions.Singleline, TimeSpan.FromSeconds(2)); var match = regEx.Match(“123453109839109283090492309480329489812093809x”); } catch (RegexMatchTimeoutException ex) { Console.WriteLine(“Regex Timeout”); }
We all know that .NET code is in a semi-compiled format . At runtime, the JIT (Just-in-Time) compiler executes and converts this semi-compiled IL code into machine-native code. One of the biggest complaints about the JIT is that when a .NET application is first executed, it runs very slowly because the JIT is busy converting IL code to machine code.
In order to reduce this startup time, there is something called "optimization configuration file" in .NET4.5. A configuration file is nothing more than a simple file that records a list of methods that your application needs to start running. So when the application starts, the background JIT executes and starts converting the IL code of these methods into machine/native language.
This background JIT compiles startup methods on multiple processors to further reduce startup time. Also note that you will need a multi-core processor to achieve profile optimization. If you don't have a multi-core processor this setting will be ignored.
为了创建“配置文件”这个文件,首先你需要引入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面试问和答,我已经在这方面有了不少努力。
The above is the detailed content of .NET Framework 4.5 five great features shared. For more information, please follow other related articles on the PHP Chinese website!