Stack-Overflow-Driven Development

Thank God for StackOverflow.com. I seriously can’t imagine my (programming) life without it. And with it being one of the most visited sites on the web, I guess I’m not alone.

There’s a long friendship between Stack Overflow and me. It helped me countless times when I was stuck on a problem. It gave me an idea of how other people had approached the same problem. Sometimes these other people helped me solve my problem. Sometimes they gave me a hint for a possible solution. And sometimes reading their issues at least let me know that I wasn’t alone with a miserable bug…

After hours or even days of searching and trying different things, your shields are down. You are crawling through your code on all fours like a man who’s lost in the desert. But all of a sudden your search is fruitful! Eureka! Searching Stack Overflow has finally yielded a piece of code that works!

That’s when you have to watch out and resist the temptation to take code that works for the system that’s good. What you’ve found on Stack Overflow is – in all but the rarest cases – not a solution but rather a clue. It can certainly make for a great pointer, but it was not written with your exact problem/ requirements/ constraints/codebase/application in mind. And sometimes, it might just be a dirty hack.

Embrace Stack Overflow as a good source of guidance for specific problems. But also take the time to thoroughly and honestly evaluate if you’ve found a real, reliable solution.

Design Patterns

Sometimes, a solution is so beautiful, and you wish you had the right problem to apply it to. But unfortunately, issues come first. As impressive as your new screwdriver may be (imagine a handle made of gold, with your initials engraved, of course, if the problem at hand is to knock in a nail, it makes for only a less than perfect solution.

Now, after teaching you all I know about manual craft, let’s return to software development – and consider “design patterns” as your toolbox. Every design pattern you know (and understand) is an instrument in your toolbox. It’s certainly great to have many of them!

The problems start, however, as soon as you let the patterns dictate your coding. They should be there to support you, to propose a proven solution – for the right problem! Programming paradigms should be used where they fit and not be enforced. Your components should be designed with your application’s requirements in mind – not with a beautiful design pattern.

In cases where you’ve indeed found a helpful pattern for your current problem, there’s only one more thing: be sure to understand the pattern and its consequences on your coding.

Creating Good APIs

I’m sure you’ve used a third-party API at some point in your dev career – for example, to create new contacts in your CRM, to send emails through a newsletter service, or to do anything else with a third-party service virtually.

If you’ve interacted with a couple of such APIs, you will undoubtedly have noticed some differences between them: using one was probably more pleasant than the other. It’s easy to see which API was designed thoroughly, by an experienced developer, and perhaps with a lot of effort and thought. And it’s just as easy to be frustrated with an API that was designed poorly and sloppily. The former was probably a joy to use, while the latter was perhaps… not.

Since the effects are so visible, most developers tend to quickly agree that it’s almost a duty to design public APIs in a careful and thought-out way. Nobody wants to work with a crappy API – and nobody wants to burden other developers with using their API being crappy.

Modern software design puts great emphasis on the concept of “application programming interfaces”. However, as most developers already know, the idea goes a lot deeper and is not exclusive to a public interface. Instead, you should build APIs inside your application, for internal use, too.

Approaching these internal APIs in the same way you’d create a public one can make a huge difference: your colleagues (and you) will want to interact with this part of your application. Making the interaction as easy as possible for these people is one of the best goals you can have.

A secure, thoughtful API is probably the part of your software where quality matters the most. Your colleagues might forgive you a little sloppiness in the internals of this or that method. But they won’t (and shouldn’t) forgive you for creating a dangerous API.

Differences Between ASMX and WCF Services

Some differences between ASMX and WCF services are subtle and some differences between them are not subtle. The purpose of this section is to identify many of these differences and to provide guidance for how to handle them when preparing for, or when performing, migration. ASMX provides a very successful baseline for services, and WCF extends those capabilities for the next generation of services.

There are differences between ASMX and WCF, but it is important to also understand that WCF supports the same capabilities that ASMX provides. For example, you can use message types, XmlSerialization, custom SOAP headers, and Web Service Enhancements (WSE) in a WCF service. The remainder of this section describes some of these items; it also describes other areas that represent differences between ASMX and WCF.

The following subtopics describe the major differences between ASMX and WCF services:

  • Message Structure and Serialization
  • SOAP Extensions
  • Transport Protocols
  • Security
  • Exception Handling
  • State Management

Message Structure and Serialization

Serialization is the process of translating binary objects into a data format that can be transmitted across process boundaries, computer boundaries, and network boundaries. When serialized data reaches the destination, or endpoint, it can be deserialized back into binary objects for use by an application. Both ASMX and WCF use SOAP for messages passed between two endpoints. However, for serialization, each uses different classes that implement different rules.

ASMX uses the XmlSerializer to translate classes into XML for communication, and to translate the XML back into classes on the receiver’s end. All public members are serialized unless they are marked as non-serializable using the XmlIgnoreAttribute. A large number of attributes can also be used to control the structure of the XML. For example, a property can be represented as an attribute using the XmlAttributeAttribute, or as an element using the XmlElementAttribute. The use of these attributes provides a great deal of control over how a type is serialized into XML; however, that power comes with an unfortunate downside. It may be possible to create XML structures that are not easily translated by other type systems, such as Java; XML structures that are not easily translated can hamper interoperability.

WCF uses a DataContractSerializer to perform the same translation; however, the behavior is different from the XmlSerializer. The XmlSerializer uses an implicit model where all public properties are serialized unless they are marked with the XmlIgnoreAttribute, but the DataContractSerializer uses an explicit model where the properties and/or fields that you want to serialize must be marked with a DataMemberAttribute. It is important to note that WCF can also use the XmlSerializer to perform serialization operations.

A notable difference between ASMX and WCF is the WCF ability to serialize class members regardless of the access specifier used. This means it is now possible to serialize private fields. Using this capability, you can encapsulate fields in a data type. For example, you can provide read-only access to a private field by implementing only the get method on a property. You can then serialize that private field by adding the DataMember attribute to the field in a WCF service.

Another important difference is that the DataContractSerializer generates a simplified XML structure that increases its ability to interoperate between different operating systems. In addition, the ability for users to control the XML structure is limited. This simplified structure also means that future versions of WCF will be able to target this structure for optimization. Finally, in comparison to the XmlSerializer, the serialization of data is greatly improved with the DataContractSerializer.

Recommendation

Using WCF, you can use the XmlSerializer for types that are already created. However, to maximize interoperability, it is recommended to use WCF data contracts and the DataContractSerializer. The Web Service Software Factory (ASMX) guidance package, also referred to as the ASMX guidance package, creates types that should also migrate to WCF data contracts if no additional XML serialization attributes, such as XmlAttributeAttribute, are added. The ASMX guidance package includes an XmlNamespaceAttribute to specify the namespace of the types.

SOAP Extensions

Developers can use the SOAP extensions feature of ASP.NET to interact directly with SOAP messages. By using SOAP extensions, you can intercept the SOAP message and insert your own code into the SOAP message pipeline, which allows you to extend the capabilities of SOAP. For example, features such as security, transaction management, routing, and tracing can be implemented by using SOAP extensions. The downside of this capability is that it reduces the SOAP message’s ability to interoperate with other operating systems. In other words, other operating systems may not be able to handle a SOAP message that has been customized.

WCF does not support the use of SOAP extensions, but it does have other extensibility points that can be used to intercept and manipulate SOAP messages. For example, you can use a behavior extension to hook into the WCF Dispatcher with a class that implements IDispatchMessageInspector.

Recommendation

Avoid the use of SOAP extensions when developing new ASMX services that will be migrated to WCF unless you are willing to rewrite them or if you are confident that WCF provides a similar capability.

Transport Protocols

ASMX services use the HTTP transport protocol for communications with Internet Information Services (IIS) as the host. An ASMX service file has the file name extension .asmx, which is accessed using a Uniform Resource Locator (URL); for example, http://localhost/ASMXEmployee/EmployeeManager.asmx.

WCF services can also use the HTTP protocol, but unlike ASMX services, you also have the option to use other transport protocols. The following protocols are supported by WCF:

  • Hypertext Transfer Protocol (HTTP)
  • Transmission Control Protocol (TCP)
  • Message Queuing (also known as MSMQ)
  • Named pipes

Many different hosts can also be used with WCF services. For example, IIS can be used as a host with the HTTP transport protocol. Windows services and stand-alone applications can be used as a host for other transport protocols.

Accessing a service hosted in IIS is similar to accessing an ASMX service; for example, http://localhost/WCFEmployee/EmployeeManager.svc.

The only difference between the two services is the file name extension. However, you can also configure a WCF service to use the .asmx file name extension, as described in the Service Configuration topic. WCF services that use other transport protocols are accessed using methods associated with the specific protocol.

When migrating an ASMX service to WCF, the protocol you choose is based on the client applications that will be accessing the service. If you need to support ASMX client applications, you also need to use the HTTP protocol. In addition, when configuring a WCF service for ASMX client applications, you need to configure the service to use BasicHttpBinding, as described in the Service Configuration topic.

Recommendation

When migrating services from ASMX to WCF, and if ASMX client applications need to access the migrated service, use the HTTP protocol and configure the new service to use BasicHttpBinding.

Security

Typically, authentication and authorization with ASMX is done using IIS and ASP.NET security configurations and transport layer security. In addition, Web Service Extensions (WSE) can be used to provide additional security capabilities, such as message layer security.

WCF can use the same security components as ASMX, such as transport layer security and WSE. However, WCF also has its own built-in security, which allows for a consistent security programming model for any transport. The security implemented by WCF supports many of the same capabilities as IIS and WS-* security protocols. However, when using IIS, you must also enable anonymous access to the service so that WCF security is implemented.

A powerful reason for migrating an ASMX service to WCF is to take advantage of new security capabilities that are provided by WCF. For example, WCF provides support for claims-based authorization that provides finer-grained control over resources than role-based security. In addition, instead of depending on a transport protocol such as HTTP and extensions such as WSE, security is built into WCF. The end result is that security is consistent regardless of the host that is used to implement a WCF service.

Recommendation

When possible, migrate both client applications and services to WCF to take advantage of the new security features that are available with WCF. Use of the WCF Security guidance package is also recommended when configuring security for WCF services and client applications.

If a migrated WCF service must support ASMX client applications, you can use transport security associated with HTTP and HTTPS. You can also use WSE 3.0, but you must configure a custom WCF binding for this to work. For additional information about using WSE 3.0 with WCF, see Interoperating with WSE Sample on MSDN.

Exception Handling

With ASMX services, unhandled exceptions are always returned to client applications as SOAP faults. An ASMX service can also throw the SoapException class, which provides more control over the content of the SOAP fault that is returned to the client application.

However, when an unhandled exception occurs, the default configuration of WCF protects sensitive data from exposure by not returning sensitive information in SOAP fault messages. You can override this behavior by adding a serviceDebug element to the service behavior in the configuration file that is associated with a WCF service. Overriding this behavior is not recommended for deployment; it should be used only in a development environment.

Similar to the SoapException class used with ASMX services, you can also throw a custom exception by using the FaultException<T> type, where T is a data contract that contains the exception information. The use of custom exceptions also requires the declaration of a FaultContract on operations that will throw the exception.

The following code example demonstrates how a DataContract is used to define a FaultContract declared on a service operation in a ServiceContract.

[DataContract]
public class FindEmployeeFault
{
    [DataMember]
    public string Request;
    [DataMember]
    public string Description;
}

[ServiceContract]
public interface IEmployeeManager
{
    [OperationContract(Action = "FindEmployeeByLastName")]
    [FaultContract(typeof(EmployeeService.FaultContracts.FindEmployeeFault))]
    EmployeeService.DataContracts.Employee FindEmployeeByLastName(string request);
}

This next code example demonstrates how to catch a FaultException that may be thrown by the service operation shown in the preceding code example.

// client function used to find an employee
public Employee FindEmployee( string lastName )
{
    Employee employee = null;
    try
    {
        employee = proxy.FindEmployeeByLastName( lastName   );
    }
    catch( FaultException<FindEmployeeFault> ex )
    {
        Console.WriteLine("FaultException<FindEmployeeFault>: While finding " 
            + ex.Detail.Request
            + ". Because: " 
            + ex.Detail.Description );
    }
    return employee;
}

The filtering of exception data that is returned from a service is described using an Exception Shielding pattern. The pattern describes how exception handlers can be used to filter the data that is returned to a client application. To help facilitate the creation of exception handlers in WCF services, the Service Factory: Modeling Edition includes the Data Contract Model that contains a fault contract shape that you can use to create WCF fault contracts.

Recommendation

WCF provides exception shielding, but you should always define exception handlers for both ASMX and WCF services. For more information, see Exception Handling in Service Oriented Applications.

State Management

ASMX services have access to the HttpContext class, which provides access to state managers with a different scope, such as application scope and session scope. ASP.NET also provides control over how state data is managed. Consequently, you should minimize the use of state in a service because of the effect it has on the scalability of an application.

WCF provides extensible objects that can be used for state management. Extensible objects implement the System.ServiceModel.IExtensibleObject<T> interface. The two main classes that implement the IExtensibleObject interface are ServiceHostBasedand InstanceContext. The ServiceHostBased class provides the ability for all service instances in the same host to access the same state data. On the other hand, the InstanceContext class only allows access to state data within the same service instance.

To implement state management in WCF, you need to define a class that implements the IExtension interface, which is used to hold the state data. Instances of this class can then be added to one of the IExtensibleObject classes using the Extensions property. The following code example shows how to implement state using the InstanceContext.

internal class StateData: IExtension<InstanceContext>
{
    public string Identifier = string.Empty;
    public string Data = string.Empty;

    public StateData( string data )
    {
        Identifier = Guid.NewGuid().ToString();
        Data = data;
    }
}

public string AddStateData( string data )
{
    StateData state = new StateData( data );
    OperationContext.Current.InstanceContext.Extensions.Add(state);
    return state.Identifier;
}

public string GetStateData( string identifier )
{
    Collection<StateData> dataCollection = 
        OperationContext.Current.InstanceContext.Extensions.FindAll<StateData>();

    string result = string.Empty;
    foreach( StateData data in dataCollection )
    {
        if( data.Identifier == identifier )
        {
            Result = data.Data;
            break;
        }
    }
    return result;
}

Recommendation

The ability to control where state is maintained in WCF is much more limited than in ASP.NET. As a result, state management is commonly used as the primary reason for enabling the ASP.NET compatibility mode, which provides access to ASP.NET components; this means you have much more control over where state is maintained. For example, when a service is configured for ASP.NET compatibility, you have access to HTTP context classes that provide the same functionality as the ASMX implementation.

When developing new ASMX services, you should avoid the use of state in your services; all services should be stateless.

Original source from Microsoft, edited and moved here as the content on Microsoft was in fear of being removed.

Defining and Using Custom Attribute Classes in C#

Attributes are advantageous in C# to provide none business-related functionality in an application or to abstract out the code to make it easier to follow.

The issue is when does the attribute code get called and how do you force it to run?

I set the task on to write a simple console application showing different ways you can use attributes.

I found a fascinating article for my first sample application on Defining and Using Custom Attribute Class in C# by David Tansey, below is an edited version of this article:

The complex, component-style development that businesses expect out of modern software developers requires greater design flexibility than the design methodologies of the past.

Microsoft’s .NET Framework makes extensive use of attributes to provide added functionality through what is known as “declarative” programming. Attributes enhance flexibility in software systems because they promote loose coupling of functionality. Because you can create your custom attribute classes and then act upon them, you can leverage the loose coupling power of attributes for your purposes.

The .NET Framework makes many aspects of Windows programming much more straightforward. In many cases, the Framework’s use of metadata that .NET compilers bind to assemblies at compile time causes tricky programming easier. Indeed, the use of intrinsic metadata makes it possible for .NET to relieve us from “DLL Hell.”

Lucky for us, the designers of the .NET framework did not choose to keep these metadata “goodies” hidden away under the covers. The designers gave us the Reflection API through which a .NET application can programmatically investigate this metadata. An application can “reflect” upon any imaginable aspect of a given assembly or on its contained types and their members.

Binding the metadata to the executable provides many advantages. It makes the assemblies in .NET fully self-describing. This allows developers to share components across languages and eliminates the need for header files. (They can become out-of-date relative to the implementation code.)

With all this positive news about .NET metadata, it seems hard to believe there could be anything more to the story? But there is. You can create your application-specific metadata in .NET and then use that metadata for any purpose you can imagine.

Developers define their application-specific metadata through the use of Custom Attributes. Because these attribute values become just another part of the metadata bound into an assembly, the custom attribute values are available for examination by the Reflection API.

In this article, you’ll learn how to define custom attribute classes, how to apply attributes to classes and methods in your source code, and you’ll learn how to use the Reflection API to retrieve and act upon these values.

How Does .NET Use Attributes in the Common Language Runtime?

Before you start to consider what you can accomplish with your custom attribute classes, let’s examine some of the standard attributes that the Common Language Runtime already makes available.

The [WebService] attribute provides a simple example? It lets you turn any public method of a WebService subclass into a method that you can expose as part of the Web Service merely by attaching the [WebMethod] attribute to the method definition.

public class SomeWebService : System.Web.Services.WebService
{

   [WebMethod]
   public DataSet GetDailySales( )
   {
      // code to process the request...
   }
}

You just attach the [WebMethod] attribute to the method, and .NET handles everything else for you behind the scenes.

Using the [Conditional] attribute allows you to make a given method conditional based on the presence or absence of the specified preprocessing symbol. For example, the following code:

public class SomeClass
{
   [Conditional( "DEBUG" )]
   public void UnitTest( )
   {
      // code to do unit testing...
   }
}

Indicates that the UnitTest( ) method of this class is “conditional” based on the presence of the preprocessing symbol “DEBUG”. The fascinating part is what happens. The compiler stubs out all calls to the method when the condition fails rather than attempt to nullify the behaviour of the method the way an #if…#endif pre-processing directive does. This is a much cleaner approach, and again we didn’t have to do much of anything to utilise this functionality.

Attributes utilise positional and/or named parameters. In the example using the [Conditional] attribute, the symbol specification is a positional parameter. You must always supply positional parameters.

To look at named parameters, let’s return to the [WebMethod] attribute example. This attribute has a named parameter called Description. To use it you would change the line to read:

[WebMethod(Description = "Sales volume" )]

Named parameters are optional, and you write them using the name of the parameter followed by the assignment of a value. Named parameters follow after you’ve specified all positional parameters.

I will talk more about named and positional parameters later in this article when I show you how to create and apply your Attribute class.

Run-Time, Design-Time

The examples provided in this article are involved in run-time activities. But Binaries (assemblies) aren’t just for run-time. In .NET, the metadata you describe isn’t limited to being available only at runtime. You can query the metadata at any time after you’ve compiled an assembly.

Think about some design-time possibilities. The open nature of the IDE in Visual Studio.NET allows you to create tools (using .NET languages) that facilitate development and design (wizards, builders, etc.) Thus, one module’s run-time environment (the IDE tool) is another module’s design-time environment (the source code being developed). This presents an excellent opportunity to implement some custom attributes. You could allow the IDE tool to reflect and then act upon the source classes/types you develop. Unfortunately, due to the additional subject of the IDE tool code, exploring such an example is beyond the scope of a single article.

The standard .NET attributes contain a similar example. When a developer creates custom controls to include in the Toolbox of the Visual Studio .NET IDE, they have attributes available to them to indicate how to handle the control in the property sheet. Table 1 lists and describes the four standard .NET attributes that the property sheet uses.

These property sheet-related attributes make it clear that you can use attributes and their values in the design-time as well as in the run-time environment.

Custom Attributes vs. Class Properties

Apparent similarities exist between attributes and regular member properties of a class. This can make it difficult to decide when and where you might want to utilise a custom attribute class. Developers commonly refer to properties of a class and their values as being “attributes” themselves, so what is the difference between properties and attributes?

An attribute takes the same “shape and form” as a property when you define it, but you can attach it to all manner of different assembly level types?not just Classes. Table 2 lists all the assembly level types that you can apply attributes.

Let’s pick one item from the list as an example. You can apply an attribute to a parameter, which is a little bit like adding a property to a parameter? A very novel and powerful idea indeed, because you just can’t do that with class member properties. This emphasises the most significant way in which attributes and properties are different because properties are just always going to be members of a class?  They can’t be associated with a parameter or any number of other types listed in Table 2 different than Class.

Member properties of a class are also limited in another way in which attributes are not. By definition, a member property is tied to a specific class. That member property can only ever be used through an instance or subclass instance of the class on which the property was defined. On the other hand, you can attach/apply attributes anywhere! The only requirement is that the assembly type the attribute is being assigned to matches the validon definition in the custom attribute. We’ll talk more about the validon property of custom attribute classes in the next section. This characteristic of attributes helps to promote the loose coupling that is so helpful in component-style development.

Another difference between properties and attributes relates to the values you can store in each of them. The values of member properties are instance values and can be changed at run-time. However, in the case of attributes, you set values at design time (in source code) and then compile the attributes (and their values) directly into the metadata contained in an assembly. After that point you cannot change the values of the attributes?you’ve essentially turned the values of the attributes into hard-coded, read-only data.

Consider this when you attach an attribute. If you attach an attribute to a class definition, for example, every instance of the class will have the same values assigned to the attribute regardless of how many objects of this class type you instantiate. You cannot attach an attribute to an instance of a class. You may only attach an attribute to a Type/Class definition.

Creating a Custom Attribute Class

Now we’ll create a more realistic implementation of the ideas presented above. Let’s create a custom attribute class. This will allow us to store some tracking information about code modifications that you would typically record as comments in source code. For example, we’ll mark just a few items: defect id, developer id, the date of the change, the origin of the defect, and a comment about the fix. To keep the example simple we’ll focus on creating a custom attribute class (DefectTrackAttribute) designated for use only with classes and methods.

Listing 1 shows the source code for the DefectTrackAttribute class. You can identify some critical lines of code.

If you haven’t used attributes before, the following line of code might look a bit strange.

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = true)]

This line attaches an [AttributeUsage] attribute to the attribute class definition. Square bracket syntax identifies the construct as an attribute. So, Attributes classes can have their attributes. This may seem a bit confusing at first, but it should become more evident as we show you what you’ll use it for.

The [AttributeUsage] attribute has one positional parameter and two named parameters. The positional parameter validon specifies which of the various assembly types you can attach this attribute to. The value for this parameter uses a combination of values from the AttributeTargets enumeration. In my example, I allow only classes and methods, so I get the proper specification by OR’ing the two AttributeTargets values together.

The first named parameter of the [AttributeUsage] attribute (and the only one specified in the example) is the AllowMultiple parameter, which indicates whether you can apply this type of attribute multiple times to the same category. The default value is false. However, you want to use the AllowMultiple parameter of the Attribute more than once on a single type because that represents what the example will model. A given method or class potentially goes through many revisions during its lifetime, and you need to be able to denote each of these changes with an individual [DefectTrack] attribute.

The second named parameter of the [AttributeUsage] attribute is the Inherited parameter, which indicates whether or not derived classes inherit the attribute. I’ve made the default value for this parameter false. I opted to take the default value, so I did not specify this named parameter. Why? The source code modification information I want to capture is always related to each class and method individually. Would it confuse the developer for a class to inherit the [DefectTrack] attribute(s) from its parent class? The developer couldn’t distinguish which [DefectTrack] attributes came from the parent and which were specified directly.

Listing1 then lists the class declaration. Attribute classed are subclassed from System.Attribute. You will directly or indirectly subclass all custom Attribute classes from System.Attribute.

Next, Listing 1 shows that I’ve defined five private fields to hold the values for the attribute.

The first method in our Attribute class is the class constructor, which has a call signature with three parameters. The parameters of a constructor for an Attribute class represent the positional parameters for that attribute, which makes these required parameters. If you choose, you can create overloaded constructors and have more than one proper positional / configuration of parameter needed.

The remainder of the Attribute class is a series of public property declarations that correspond to the private fields of the class. You’ll use these properties to access the values of the attribute when you get to the example that examines the metadata. Note that the properties that correspond to the positional parameters only have a get clause and do not have a set clause. This makes these properties read-only and communicates with the fact that these are meant to be positional and not named parameters.

Applying the Custom Attribute

You’ve already seen that you can attach an attribute to a target item in your C# code by putting the attribute name and its parameters in square brackets immediately before the item’s declaration statement.

In Listing 2 you attach the [DefectTrack] attribute to a couple of methods and a couple of classes.

You need to ensure that you have access to the class definition for your custom attribute, so you start by including this line.

using MyAttributeClasses;

Beyond that, you’re merely “adorning” or “decorating” your class declarations and some of your methods with the [DefectTrack] custom attribute.

SomeCustomPricingClass has two uses of the [DefectTrack] attribute attached. The first [DefectTrack] attribute uses only the three positional parameters whereas the second [DefectTrack] attribute also includes a specification for the named parameter Origin.

[DefectTrack( "1377", "12/15/02", "David Tansey" ) ]
[DefectTrack( "1363", "12/12/02", "Toni Feltman", Origin = "Coding: Unhandled Exception")]
public class SomeCustomPricingClass
{ ... }

The PriceIsValid( ) method also uses the [DefectTrack] custom attribute, and it includes a specification for both of the named parameters, Origin and FixComment. Listing 2 contains a couple of additional uses of the [DefectTrack] attribute that you can examine on you own.

Some readers might wonder if you could rely on the old-fashioned approach of using comments for this sort of source modification information. .NET does make tools available for using XML blocks within comments to give them some structure and form.

You can easily see a comment in your source code right at the relevant place. You could process such information by text parsing the comments in the source, but it’s tedious and potentially error-prone. .NET provides tools to process XML blocks in comments that practically eliminate this issue.

Using a custom attribute for the same purpose also provides you with a structured approach to recording and processing the information, but it has an added advantage. Consider that after you compile source code into a binary, you lose your comments?forever removed from the byproduct executable code. By comparison, the values of the attributes become a part of the metadata that you’ve permanently bound to the assembly?you have still had access to the information even without any source code.

Additionally, the way an attribute “reads” in source code allows it to fill the same valuable design-time function still that the original comment did.

Retrieving the Values of the Custom Attributes

At this point, even though you’ve applied your custom attribute to some classes and methods, you haven’t seen it in action. It seems as if nothing indeed occurs whether you attach the attributes or not. But something does happen and you don’t have to take my word for it. You can use the MSIL Disassembler to open an EXE or DLL that contains types you’ve decorated with your custom attributes. The MSIL Disassembler lets you see that .NET included your attributes and their values right there in the IL code. Figure 1 shows an example of ILDASM form with the EXE from the sample code in this article opened.

Despite seeing the attribute values in the disassembly as proof of their existence, you still haven’t seen any action related to them. Now you’ll use the Reflection API to traverse the types/objects of an assembly, query for your custom attribute, and retrieve the attribute values when you find types that have your custom attribute attached to them.

Consider the general structure and intent of the test program in Listing 3. The program loads the specified assembly, gets an array of all members of the assembly, and iterates through each member looking for classes that have the [DefectTrack] attribute attached. For classes that have the attribute, the test program outputs the values of the attribute to the console. The program then performs the same steps and iteration for methods. These loops “walk” their way through the entire assembly.

Now examine some of the more critical lines of code. The first line and second line of the DisplayDefectTrack( ) method retrieve a reference to an Assembly object by loading the specified Assembly and then extracts an array containing all of the types in the assembly.

Assembly loAssembly = Assembly.Load( lcAssembly ) ;
Type[ ] laTypes = loAssembly.GetTypes( ) ;

A FOR…EACH loop iterates through each of the types of the assembly. The program outputs the name of the current type to the console, and then the following line of code queries the present type for an array containing [DefectTrack] attributes.

object[ ] laAttributes = loType.GetCustomAttributes(typeof(DefectTrackAttribute ), false ) ;

You specify the parameter typeof(DefectTrackingAttribute) on the GetCustomAttributes() method so that you can limit the returned custom attributes to be only of the type that you created in the example. The second parameter of false indicates that you do not want to include the type’s inheritance chain when trying to find your attributes.

A FOR…EACH loop iterates through each of the custom attributes and outputs its values to the console. You should recognise that the first line of the FOR…EACH block creates a new variable and does a typecast against the current attribute.

DefectTrackAttribute loDefectTrack = (DefectTrackAttribute)loAtt ;

Why is this necessary? The GetCustomAttributes() method returned an array that contains references that get cast to the generic type Object. You want to gain access to the values from your custom attribute class, and to do so, you must recast these references to their actual concrete type, DefectTrackAttribute. Once you’ve completed this, you can use the attributes, and the program can output the attribute values to the console.

Because you can apply your attribute to either classes or methods, the program then calls the GetMethods() method of the current type object from the assembly.

MethodInfo[ ] laMethods =
  loType.GetMethods(
    BindingFlags.Public |
    BindingFlags.Instance |
    BindingFlags.DeclaredOnly ) ;

For example, we have chosen to pass some values from the BindingFlags enumeration to GetMethods(). These three BindingFlags, when used in combination, limit the methods returned to ones that you defined directly in the current class. I wanted to limit the amount of output in the example, but you probably would not do this in practice because a developer might apply the [DefectTrackAttribute] to an overridden method. My implementation would not catch those attributes.

The remaining code does virtually the same processing for each of the methods that it did for each of the classes? The code queries each method for custom attributes of the [DefectTrack] type and then outputs the values for the ones it finds to the console.

Conclusion

This is just presented the implementation as only one example of how a developer might use .NET attributes to enhance their development process. Custom attributes are a bit like XML in that the significant benefits aren’t related to “what it does.” Custom attributes’ real interests lie in “what you can do with it.” The possibilities are truly limitless, and the open nature of custom attributes makes it likely that some of their most novel and powerful uses have yet to be conceived of.

Listing 1: Custom attribute class for DefectTrack attribute

using System;

namespace DefiningAndUsingCustomAttribute
{
 [AttributeUsage(AttributeTargets.Class |
 AttributeTargets.Method,
 AllowMultiple = true)]
 public class DefectTrackAttribute : System.Attribute
 {
 private string cDefectID;
 private DateTime dModificationDate;
 private string cDeveloperID;
 private string cDefectOrigin;
 private string cFixComment;

public DefectTrackAttribute(string lcDefectID, string lcModificationDate, string lcDeveloperID)
 {
 this.cDefectID = lcDefectID;
 this.dModificationDate = System.DateTime.Parse(lcModificationDate);
 this.cDeveloperID = lcDeveloperID;
 }

public string DefectID
 { get { return cDefectID; } }

public DateTime ModificationDate
 { get { return dModificationDate; } }

public string DeveloperID
 { get { return cDeveloperID; } }

public string Origin
 {
 get { return cDefectOrigin; }
 set { cDefectOrigin = value; }
 }

public string FixComment
 {
 get { return cFixComment; }
 set { cFixComment = value; }
 }
 }
}

Listing 2: Two example classes with attributes attached

namespace DefiningAndUsingCustomAttribute
{
 [DefectTrack("1377", "12/15/02", "David Tansey")]
 [DefectTrack("1363", "12/12/02", "Toni Feltman",
 Origin = "Coding: Unhandled Exception")]
 public class SomeCustomPricingClass
 {
 public double GetAdjustedPrice(double tnPrice, double tnPctAdjust)
 {
 return tnPrice + (tnPrice * tnPctAdjust);
 }

[DefectTrack("1351", "12/10/02", "David Tansey", Origin = "Specification: Missing Requirement", FixComment = "Added PriceIsValid( ) function")]
 public bool PriceIsValid(double tnPrice)
 {
 return tnPrice > 0.00 && tnPrice < 1000.00;
 }
 }
}

Listing 3: Code to walk assembly and output attribute values

using System;
using System.Reflection;

namespace DefiningAndUsingCustomAttribute
{
 public class TestMyAttribute
 {
 public static void Main()
 {
 DisplayDefectTrack("DefiningAndUsingCustomAttribute");
 Console.ReadLine();
 }

public static void DisplayDefectTrack(
 string lcAssembly)
 {
 Assembly loAssembly = Assembly.Load(lcAssembly);

Type[] laTypes = loAssembly.GetTypes();

foreach (Type loType in laTypes)
 {
 Console.WriteLine("*======================*");
 Console.WriteLine("TYPE:\t" + loType.ToString());
 Console.WriteLine("*=====================*");

object[] laAttributes = loType.GetCustomAttributes(typeof(DefectTrackAttribute), false);

if (laAttributes.Length > 0)
 Console.WriteLine("\nMod/Fix Log:");

foreach (Attribute loAtt in laAttributes)
 {
 DefectTrackAttribute loDefectTrack = (DefectTrackAttribute)loAtt;

Console.WriteLine("----------------------");
 Console.WriteLine("Defect ID:\t" + loDefectTrack.DefectID);
 Console.WriteLine("Date:\t\t" + loDefectTrack.ModificationDate);
 Console.WriteLine("Developer ID:\t" + loDefectTrack.DeveloperID);
 Console.WriteLine("Origin:\t\t" + loDefectTrack.Origin);
 Console.WriteLine("Comment:\n" + loDefectTrack.FixComment);
 }

MethodInfo[] laMethods = loType.GetMethods(BindingFlags.Public | BindingFlags.Instance | BindingFlags.DeclaredOnly);

if (laMethods.Length > 0)
 {
 Console.WriteLine("\nMethods: ");
 Console.WriteLine("----------------------");
 }

foreach (MethodInfo loMethod in laMethods)
 {
 Console.WriteLine("\n\t" + loMethod.ToString());

object[] laMethodAttributes = loMethod.GetCustomAttributes(typeof(DefectTrackAttribute), false);

if (laMethodAttributes.Length > 0)
 Console.WriteLine("\n\t\tMod/Fix Log:");

foreach (Attribute loAtt in laMethodAttributes)
 {
 DefectTrackAttribute loDefectTrack = (DefectTrackAttribute)loAtt;
 Console.WriteLine("\t\t----------------");
 Console.WriteLine("\t\tDefect ID:\t" + loDefectTrack.DefectID);
 Console.WriteLine("\t\tDeveloper ID:\t" + loDefectTrack.DeveloperID);
 Console.WriteLine("\t\tOrigin:\t\t" + loDefectTrack.Origin);
 Console.WriteLine("\t\tComment:\n\t\t" + loDefectTrack.FixComment);
 }
 }
 Console.WriteLine("\n\n");
 }
 }
 }
}

Table 1: Standard .NET attributes that the property sheet uses at design-time in the Visual Studio .NET IDE.

Attribute Description
Designer Specifies the class used to implement design-time services for a component.
DefaultProperty Specifies which property to indicate as the default property for a component in the property sheet.
Category Specifies the category in which the property will be displayed in the property sheet.
Description Specifies the description to display in the property sheet for a property.

Table 2: .NET assembly level types that you can apply attributes to.

Type
Assembly
Class
Delegate
Enum
Event
Interface
Method
Module
Parameter
Constructor
Field
Property
ReturnValue
Structure

DefiningAndUsingCustomAttribute.zip

GDPR Compliance Checklist

A quick list for GDPR Compliance

Do you have a contact form?

Make sure you add a checkbox explicitly asking the user for the form if they consent to you storing and using their personal information to get back in touch with them. The box must be unchecked by default. Also, mention if you will send or share the data with any 3rd-parties and which.

Can visitors comment anywhere on your website?

Make sure you add a checkbox explicitly asking the user of the comment section if they consent to store their message attached to the e-mail address they’ve used to comment. The box must be unchecked by default. Also, mention if you will send or share the data with any 3rd-parties and which.

GDPR and your website

On 25th May 2018, the GDPR (General Data Protection Regulation) enacted by the EU will come into effect.

  • How do you make your website GDPR compliant?
  • What are the steps that you must take to ensure that you follow the guidelines?
  • What if you neglect this?

This article will help you in your endeavour to be ready when the regulation kicks in.

  • First, we’re going to talk in detail about the GDPR guidelines, the specific areas of your business that the guidelines affect, and why you should be concerned about your website and GDPR compliance.
  • Next, we will cover the basics of making a website site compliant with the guidelines.
  • Finally, we will discuss the implications of the use of tools on your website and how your GDPR compliance might be affected.

What is GDPR?

Disclaimer. This post is not legal advice. I am not lawyer.
GDPR stands for General Data Protection Regulation, and it is a new data protection law in the EU, which comes into force in May 2018.

The GDPR aims to give citizens of the EU control over their data and change the approach of organisations across the world towards data privacy.

The GDPR provides much stronger rules than existing laws and is much more restrictive than the “EU cookie law.”

For instance, users must confirm that their data can be collected, there must a clear privacy policy showing what data is going to be stored, how it is going to be used, and provide the user with a right to withdraw the consent to the use of personal data (consequently deleting the data), if required.

The GDPR law applies to data collected about EU citizens from anywhere in the world. As a consequence, a website with any EU visitors or customers must comply with the GDPR, which means that virtually all sites and businesses must meet.

To better understand the regulation, take a look at the publication of the rules in the Official Journal of the European Union, which defines all terms related to the law. There are two main aspects of the GDPR: “personal data” and “processing of personal data.” Here’s how it relates to running a website:

  • personal data pertains to “any information relating to an identified or identifiable natural person” – like name, email, address or even an IP address,
  • whereas processing of personal data refers to “any operation or set of operations which is performed on personal data”. Therefore, a simple operation of storing an IP address on your web server logs constitutes processing of personal data of a user.

Should GDPR be taken seriously?

Organisation of websites has time until May 2018 to comply with the regulations set by the GDPR. The penalty for non-compliance can be 4% of annual global turnover, up to a maximum of €20 million.

There are various slabs of penalties according to the seriousness of the breach, which has been described in the FAQ section of the GDPR portal.

Such a high amount of penalties has been proposed to increase compliance. However, one may wonder what steps for the supervision of websites are in place. Supervisory Authorities (SA) of different member states are going to be set up, with the full support of the law. Each member state may have multiple SAs, depending on the constitutional, administrative and organisational structures. There are various powers that SAs will have:

  • carry out audits on websites,
  • issue warnings for non-compliance,
  • issue corrective measures to be followed with deadlines.

SAs have both investigative and corrective powers to check compliance with the law and suggest changes to be compliant.

It is too early to speculate how SAs of various member states would interlink and work together, but one aspect is evident; SAs would enjoy the considerable power to enforce the GDPR guidelines.

Six months after the guidelines were released, PwC surveyed 200 CXOs of large US firms to assess the impact of the GDPR guidelines. The results revealed that a majority of the businesses had taken up the GDPR guidelines as their top data protection priority, with 76% of them prepared to spend more than $1 million on GDPR. This shows that owing to a substantial presence in the EU, and large corporations are taking up the GDPR compliance seriously.

The details of your Website GDPR compliance

So with all the official information out of the way, let’s take a moment to talk about how to make sure that your website is compliant and that you won’t experience any Website GDPR problems.

Before you move on to each of the aspects and how to comply with them, a security audit on your website site should, in general, reveal how data is being processed and stored on your servers, and steps that are required to comply with the GDPR.

Some usual ways in which a standard website site might collect user data:

  • user registrations,
  • comments,
  • contact form entries,
  • analytics and traffic log solutions,
  • any other logging tools and plugins,
  • security tools and plugins.

Here are some key aspects of the website GDPR that users need to take care of:

(a) Breach notification

Under the GDPR compliance, if your website is experiencing a data breach of any kind, that violation needs to be communicated to your users.

A data breach may result in a risk for the rights and freedoms of individuals, due to which notifying users promptly becomes necessary. Under the GDPR, a notification must be sent within 72 hours of first becoming aware of a breach. Data processors are also required to notify users as well as the data controllers, immediately after early becoming aware of a data breach.

In a website scenario, if you notice a data breach, you would need to notify all those affected by the breach within this designated time frame. However, the complexity here is the definition of the term “user” – it may constitute regular website users, contact form entries, and potentially even commenters.

This clause of the GDPR thus creates a legal requirement to assess and monitor the security of your website. The ideal way is to watch web traffic and web server logs.

(b) Data collection, processing and storage

Three elements of this: Right to AccessRight to Be Forgotten and Data Portability.

  • The right to access provides users with complete transparency in data processing and storage – what data points are being collected, where are these data points being processed and stored, and the reason behind the collection, processing and storage of the data. Users will also have to be provided with a copy of their data free of cost within 40 days.
  • The right to be forgotten gives users an option to erase personal data, and stop further collection and processing of the data. This process involves the user withdrawing consent for their own data to be used.
  • The data portability clause of the GDPR provides users with a right to download their data, for which they have previously given consent, and further transmit that data to a different controller.

Privacy by design encourages controllers to enforce data policies which enable the processing and storage of only that data which is necessary. This helps site owners and controllers to adopt potentially safer procedures for data, by limiting the access to some data points.

As a website site owner, you first need to publish a detailed policy on which personal data points you’re using, how they are being processed and stored.

Next, you need to have a setup to provide users with a copy of their data. This is perhaps the most challenging part of the process. However, we can assume that when the time comes, most plugin developers or tool developers – for the tools and plugins that you have on your site – will have already come forward with their solutions to this.

It is still advised, however, to have a system in place to derive the required data out of your database.

Further, it may be wise to avoid data storage altogether in some instances. For instance, contact forms could be set up to directly forward all communication to your email address instead of storing them anywhere on the web server.

(c) Use of plugins or tools – implications of GDPR compliance

Any plugin or tool that you use will also need to comply with the GDPR rules. As a site owner, it is still your responsibility, though, to make sure that every plugin can export/provide/erase user data it collects in compliance with the GDPR rules.

This can still mean some tough times for some of the most popular plugins out there. For instance, solutions like Gravity Forms have a lot of modules that collect user data by nature. How are those tools going to comply with the GDPR accurately?

For plugins too, the same rules apply, although they must be approached from the website owner. Each plugin needs to establish a data flow and inform about the processing of personal data. If you are the developer of a plugin, consider providing users of your plugin an addendum that they may add to their website’s terms to make them GDPR compliant. Gravity Forms, for instance, needs to let the user know how personal data being filled in a contact form is going to be published, and an option to get it removed, if necessary.

Also, some tools that sit seemingly outside of your website will see the impact of this too. Take, email marketing tools, for example. It’s a common practice to have those integrated with your site and to send promotional emails based on a list of email addresses. Depending on how you run your newsletters/lists, those addresses might not have been obtained by getting explicit consent from users.

For instance, a checkbox that’s selected by default would count as a violation. Under the GDPR, everything that’s part of your online presence as a business will need to collect consent and have a privacy policy in place explicitly. There are other implications too – if you wish to buy a mailing list, you would be sending emails illegally to the recipients, since no one explicitly asked to receive emails from you.

Although the final responsibility lies with the site owner, webmasters themselves may have to look into its processes to become compliant as well.

Final thoughts

To sum up what it means to make your website GDPR compliant:

  • the law comes into effect in May 2018,
  • it applies to any site that deals with personal information of EU users,
  • it gives the user the right to control the flow of their personal information,
  • there are defined processes to monitor compliance, and huge fines are in place for non-compliance.

In a nutshell, to make your website GDPR compliant, you should

  1. look into all the different ways in which you’re collecting visitor data. Next,
  2. put mechanisms in place to make sure that users can control their data. Additionally,
  3. it’s probably a good idea to avoid collecting user data where it’s not necessary (like the contact form example from above). And most importantly of all,
  4. even if you’re using third-party tools and solutions, you still need to make sure that those are GDPR compliant as well.

If you don’t have all of the above-taken care of by May 2018, trouble.

Nonetheless, the GDPR regulation is the right step in ensuring transparency in the handling of data. Although this post has covered the basics of GDPR, you may want to go through the regulation in detail if you have a profitable business running on your website. Remember, not complying can be fined up to €20 million or 4% of your global revenue.

Some further reading:

Original article by Shaumik Daityari

EF Migrations Command Reference

Entity Framework is always a pain the back side when it comes to managing multiple database and know what to do if things get out of sync, an article by Anders Abel clearly lays out what need to be done and what can be used to sort out any sync problems, here is a snip from his article:

Entity Framework Migrations are handled from the package manager console in Visual Studio. The usage is shown in various tutorials, but I haven’t found a complete list of the commands available and their usage, so I created my own. There are four available main commands.

  • Enable-Migrations: Enables Code First Migrations in a project.
  • Add-Migration: Scaffolds a migration script for any pending model changes.
  • Update-Database: Applies any pending migrations to the database.
  • Get-Migrations: Displays the migrations that have been applied to the target database.

There are also three extra commands that are used by NuGet packages that install Entity Framework providers. These commands are not usually used as part of normal application development.

Original post from Anders Abel,

GDPR and SQL Server

Data privacy and data security have become one of the most prominent topics in organizations in almost every industry across the globe. New regulations are emerging that formalize requirements around these topics, and compel organizations to comply.

The upcoming EU Global Data Protection Regulation (GDPR) is one of the most noteworthy of these new regulations.

The GDPR takes effect on 25th May 2018 and sets a new global bar for privacy rights, security, and compliance. It mandates many requirements and obligations on organizations across the globe. Complying with this regulation will necessitate significant investments in data handling and data protection for a very large number of organizations.

Microsoft has produced some guidelines for SQL Service, which can be found here:  microsoft-sql-and-the-gdpr

For more information on the GDPR, please visit the EU GDPR page.

For an in-depth guide on how Microsoft can help customers being their journey to GDPR compliance, see Beginning your General Data Protection Regulation (GDPR) Journey.

To learn more about Microsoft’s commitment to privacy and GDPR principles, visit the Trust Center GDPR site atwww.microsoft.com/GDPR.

Parse JSON into a C# Object

Let’s start with a simple JSON string. In most cases, you will get this string from a web service call. For the sake of this tutorial, we will do this manually.

var example1 = @"{""name"":""John Doe"",""age"":20}";

example1 is a simple JSON object with 2 fields: name and age.

In order to access the field(s) in this JSON string, we need to deserialize it into something C# can understand. This is where I would like to introduce the JavaScriptSerializer class, which is part of the System.Web.Script namespace.

var JSONObj = new JavaScriptSerializer().Deserialize<Dictionary<string, string>>(example1);

What this line does is it deserializes the string example1 into an object of type Dictionary<string, string>.

Once we have done that, we can access the fields like this:

JSONObj["name"]; // equals John Doe
JSONObj["age"]; // equals 20

Note: the Dictionary definition must match the types of the values in our JSON. “John Doe” is a string but 20 is an integer, so we have to use <string, string> and not <string, int>.

Okay, so we have deserialized it but you still have to reference it in a clunky way – object["field_name"] – so let’s fix that!

First, create a class which matches the definition of your JSON. In our case, we need a class with a string property and an int property:

class Example1Model
{
    public string name { get; set; }
    public int age { get; set; }
}

And now, to deserialize our JSON into an object of that type:

var example1Model = new JavaScriptSerializer().Deserialize<Example1Model>(example1);

And to reference the fields:

example1Model.name; // equals John Doe
example1Model.age; // equals 20

As you can see, this is much cleaner! Your IDE will give you intellisense/auto-completion, type information and everything you would expect from a native type in .NET.

Show me more!

Our first example was great, but it was basic. Now let us handle a complex JSON string — how about a list of orders for a customer?

var example2 = @"{""custId"": 123, ""ordId"": 4567, ""items"":[{""prodId"":1, ""price"":9.99, ""title"":""Product 1""},{""prodId"":78, ""price"":95.99, ""title"":""Product 2""},{""prodId"":1985, ""price"":3.01, ""title"":""Product 3""}] }";

As in example 1, the first thing we need to do is to create your classes, which represent the data in JSON. Here, I created 2 classes — the CustomerOrderSummary is for the outer fields (custId and ordId) and a list of objects of type Item.

class Item
{
    public int prodId { get; set; }
    public double price { get; set; }
    public string title { get; set; }
}
class CustomerOrderSummary
{
    public int custId { get; set; }
    public int ordId { get; set; }
    public List<Item> items { get; set; }
}

And to deserialize the JSON we simply do:

var example2Model = new JavaScriptSerializer().Deserialize<CustomerOrderSummary>(example2);

And to reference the fields:

example2Model.custId; // equals 123
example2Model.ordId; // equals 4567
example2Model.items.Count; // equals 3
example2Model.items[0].price // equals 9.99

There you have it! You can now parse JSON into .NET objects using C#! If you would like to retrieve and read the JSON via Objective-C and Node.js, feel free to read these two articles: iOS QuickTip: Getting and Reading JSON Data from a URL and How to Use JSON files in Node.js

Other Useful references:

original article