About the JIT compiler

If the JIT compiler inlines the property accessor, it must JIT that code when the containing method is called.

It's not your responsibility to determine the best machine-level representation of your algorithms. The C# compiler and the JIT compiler together do that for you. The C# compiler generates the IL for each method, and the JIT compiler translates that IL into machine code on the destination machine. You should not be too concerned about the exact rules the JIT compiler uses in all cases; those will change over time as better algorithms are developed. Instead, you should be concerned about expressing your algorithms in a manner that makes it easiest for the tools in the environment to do the best job they can. Luckily, those rules are consistent with the rules you already follow for good software-development practices. One more time: smaller and simpler functions

Remember that translating your C# code into machine-executable code is a two-step process. The C# compiler generates IL that gets delivered in assemblies. The JIT compiler generates machine code for each method (or group of methods, when inlining is involved), as needed. Small functions make it much easier for the JIT compiler to amortize that cost. Small functions are also more likely to be candidates for inlining. It's not just smallness: Simpler control flow matters just as much. Fewer control branches inside functions make it easier for the JIT compiler to enregister variables. It's not just good practice to write clearer code; it's how you create more efficient code at runtime.

Posted in: .NET Framework| Tags: .NET Code C# JIT responsibility method property compiler representation accessor

---

Working with Dynamic Language Code in the DataList Control

In this part of the walkthrough you will use dynamic language code to perform data binding instead of using the Eval method that is generated by default for declarative data binding.

To use dynamic language code with the DataList control

1. Switch to Source view.
2. Remove the Eval methods from the DataList1 control markup. When you are finished, the DataList control markup will look like the following:

   <asp:DataList ID="DataList1" runat="server"
   DataSourceID="AccessDataSource1">
   <ItemTemplate>
   CategoryName:
   <asp:Label ID="CategoryNameLabel" runat="server"
   Text='<%# CategoryName %>'>
   </asp:Label><br />
   Description:
   <asp:Label ID="DescriptionLabel" runat="server"
   Text='<%# Description %>'>
   </asp:Label><br />
   <br />
   </ItemTemplate>
   </asp:DataList>

   The data bindings are now simply dynamic language code. Because the code is dynamic, the field names can be resolved using late binding.

3. Click Ctrl+F5 to run the page, and verify that the page looks the same.
4. Close the browser.

Because the bindings are dynamic language code, you can use them to change the way the field values are displayed. In this part of the walkthrough, you will change the case of the CategoryName field, and change the background color of the Description field depending on the length of the CategoryName field.

To use dynamic language code to change the appearance of fields

1. Switch to the code for the page, and add the following import statement:

   IronPython

   		
   from System.Drawing import Color

2. Add the following function to return a color based on the size of a string:

   IronPython

   		
   def ColorPicker(input):
   input = str(input)
   if len(input) > 10:
   return Color.Yellow
   else:
   return Color.White

3. Return to the Web page markup, replace the text CategoryName: with the text The <%# CategoryName.upper() %> category includes: and remove the CategoryNameLabel Label control from the item template.

   When you are finished, the item template will look like the following.

   IronPython

   		
   <ItemTemplate>
   The <%# CategoryName.upper() %> category includes:
   Description:
   <asp:Label ID="DescriptionLabel" runat="server"
   Text='<%# Description %>'>
   </asp:Label><br />
   <br />
   </ItemTemplate>

   The dynamic language compiler will resolve the field name and apply the ToUpper() method to the field. Be sure to include the parentheses. If you omit them, the compiler generates an object representing the method itself, which will not display anything.

   Note   You can use either the Python upper method or the .NET Framework ToUpper method.

4. Remove the text Description: above the DescriptionLabel control, and add a BackColor attribute to the DescriptionLabel control. When you are finished, the item template will look like the following.

   IronPython

   		
   <ItemTemplate>
   The <%# CategoryName.upper() %> category includes:
   <asp:Label ID="DescriptionLabel" runat="server"
   Text='<%# Description %>'
   BackColor='<%# ColorPicker(CategoryName) %>' >
   </asp:Label><br />
   <br />
   </ItemTemplate>

   The dynamic language compiler will evaluate the expression and call the ColorPicker method, changing the background color of descriptions for category names longer than ten characters.

5. Press Ctrl+F5 to run the page and verify that the category name appears in upper case, and that the description has a yellow background color whenever the category name is longer than ten characters.

Posted in: .NET Framework Website-asp.net| Tags: Dynamic Data DataList Control Code IronPython

---

Designing for Simplified Cryptography Functionality

Cryptography in applications can be implemented in many ways. Typically, developers must duplicate code to perform common tasks. To meet the needs of their organization, they may have to familiarize themselves with many different ways of implementing cryptography. The Cryptography Application Block is designed to simplify and abstract the implementation of cryptography in applications.

Design Implications
Ensuring that the application block simplifies the task of accessing cryptography functionality resulted in the following design decisions:

It should expose only a small number of methods that a developer would need to understand.
It should accept and return data using consistent data types.
It should support common algorithms.
The following subtopics describe these decisions.

Small Number of Methods
The application block supports a small number of methods that simplify the most common cryptography tasks. It provides a Cryptographer class and the corresponding non-static CryptographyManager façade (for use with the Unity Application Block) that define the set of static methods the application block supports. These methods include the following:

CreateHash
CompareHash
EncryptSymmetric
DecryptSymmetric
Consistent Data Types
Each public method has two overloads. One overload accepts parameters as type string; the other overload accepts the parameters as a byte array. For example, the following code shows the two overloads for the CreateHash method

C# Copy Code 
public static byte[] CreateHash(string hashInstance, byte[] plainText)

public static string CreateHash(string hashInstance, string plaintext)

Visual Basic Copy Code 
Public Shared Function CreateHash(ByVal hashInstance As String, ByVal plainText As Byte()) As Byte()

Public Shared Function CreateHash(ByVal hashInstance As String, ByVal plainText As String) As String

Common Algorithms
The Cryptography Application Block includes two implementations of symmetric providers. The DpapiSymmetricCryptoProvider uses DPAPI to provide cryptography services. Developers can use the SymmetricAlgorithmProvider to select and configure symmetric algorithms included with the .NET Framework.

The Cryptography Application Block includes two implementations of hash providers. The KeyedHashAlgorithmProvider allows developers to configure hash algorithms included with the .NET Framework that require a generated key. The HashAlgorithmProvider allows developers to configure hash algorithms that do not require a generated key. Both providers allow the developer to ensure that a random string (known as a salt value) is generated and pre-pended to the plaintext before hashing. Consider using salt values for storing passwords, because they dramatically slow dictionary attacks as each entry in the dictionary must be hashed with each salt value.

Note:
SHA256Managed is the recommended hash algorithm; the SHA1Managed algorithm is still acceptable but not encouraged. The MD4 and MD5 algorithms are not recommended. For symmetric encryption, AES (such as Rijndael) is currently recommended; DES is no longer recommended.

Posted in: .NET Framework| Tags: Enterprise Library Cryptography Block Application Design Code method functionality overload number createhash

---

Code Protection Best Practices, Part 2

Debugging Protected Assemblies

The Secure Virtual Machine (SVM) protection process does not provide reversing tools, however, you can use the following guidelines to simplify the analysis of unexpected errors that occur within protected methods.

• Do not use method cloaking. Method cloaking can obscure the call stack at the error point. This is good to impede hacking, but makes life very difficult when analyzing the source of an error. This feature is turned off by default.
• When throwing exceptions or logging errors (during development of the unprotected code) insert a unique error identifier for each location in the code (e.g. a GUID). This will leave the code obscure, but will allow the developer to pinpoint the line that generated the error based solely on this identifier.

Unsupported Method Constructs

SLP Code Protector does not support the transformation methods with the following constructs.

• Methods within generic classes.
• Methods containing explicit instantiation of generic types.
• Methods with generic parameters.
• Non-static methods of a structure.
• Methods with out or ref parameters.
• Methods that invoke other methods with out or ref parameters.
• Methods that modify any method parameter, even if the parameter is defined as a by value parameter.
• Methods with a variable number of parameters (for example, the params keyword in C#).
• Methods with too many local variables or parameters (> 254).
• Methods that contain calls to Reflection.Assembly.GetExecutingAssembly method, Reflection.MethodInfo.GetCurrentMethod method, or Reflection.Assembly.GetCallingAssembly method.
• For the Microsoft Common Language Runtime (CLR) 1.1 only: methods that create objects by using constructors with a variable number of parameters. This restriction does not exist when a non-constructor method is invoked.
• Implicit and explicit cast operators cannot be transformed to the Secure Virtual Machine (SVM).
• Unsafe code – For example, in C#, methods that contain the keyword unsafe cannot usually be transformed.

If you attempt to perform an SVM transformation on a method that violates one of the unsupported constructs in this section, SLP Code Protector will issue a warning.

Posted in: .NET Framework| Tags: Code Protection Best Practice .NET Code Debugging Parameter identifier part protection method methods error ref

---