om the setup file manually and disassemble it separately from the install. Once the image is installed on the user's disk, it's in assembly form rather than IL. In addition to security, this buys you a little speed when the application runs because the JIT compiler doesn't need to compile the IL code then.
Third-Party Vendors Might Hesitate
As an application vendor for desktop applications, you know what you have to do. You can write unmanaged C++ and use it from your managed VB code. You designed your application and feel safe because you know the code is good and won't corrupt process spaces it shouldn't corrupt. Although managed code is guaranteed to behave itself, your unmanaged code is stable and reliable, and it's yours. However, if you're a third-party vendor and choose unmanaged code over managed code in your components, you force consumers to step back from the benefits of .NET and open themselves up to the same problems they have now. Part of .NET's beauty is the ability to write managed code and know that doing so won't corrupt the memory used by the process space of your application and other applications. But without that knowledge, vendors might avoid writing controls in .NET managed code to restrict consumer access to the IL and potentially to algorithms their application uses.
I love VS.NET, and VB.NET in particular. The IDE's enhancements themselves provide enough of a reason to change to VB.NET (see the VBPJ .NET article in Resources). The language enhancements add to your programming tools, and the simple access to the underlying OS makes your Declare life easier. VB.NET serves as a fine tool for creating secure ASP.NET applications. However, if your main target is a thick client or desktop application, you might want to investigate the issues before shipping code with VS.NET. We'll see what Microsoft does to help developers who program desktop applications.
Third-Party Vendors Might Hesitate
As an application vendor for desktop applications, you know what you have to do. You can write unmanaged C++ and use it from your managed VB code. You designed your application and feel safe because you know the code is good and won't corrupt process spaces it shouldn't corrupt. Although managed code is guaranteed to behave itself, your unmanaged code is stable and reliable, and it's yours. However, if you're a third-party vendor and choose unmanaged code over managed code in your components, you force consumers to step back from the benefits of .NET and open themselves up to the same problems they have now. Part of .NET's beauty is the ability to write managed code and know that doing so won't corrupt the memory used by the process space of your application and other applications. But without that knowledge, vendors might avoid writing controls in .NET managed code to restrict consumer access to the IL and potentially to algorithms their application uses.
I love VS.NET, and VB.NET in particular. The IDE's enhancements themselves provide enough of a reason to change to VB.NET (see the VBPJ .NET article in Resources). The language enhancements add to your programming tools, and the simple access to the underlying OS makes your Declare life easier. VB.NET serves as a fine tool for creating secure ASP.NET applications. However, if your main target is a thick client or desktop application, you might want to investigate the issues before shipping code with VS.NET. We'll see what Microsoft does to help developers who program desktop applications.
相关文章
 我来说两句 |
对此文章发表了评论 |
评论列表 （最新 评论仅限网友观点！）
推荐文章
