Unger Technologies LLC


Type Basics

A type defines the blueprint for a value. A value is a storage location denoted by a variable (if it can change) or a constant (if it cannot).

All values in C# are an instance of a specific type. The meaning of a value, and the set of possible values a variable can have, is determined by its type.

The Type class represents type declarations: class types, interface types, array types, value types, enumeration types, type parameters, generic type definitions, and open or closed constructed generic types.

Type is the root of the System.Reflection functionality and is the primary way to access metadata. 

Use the members of Type to get information about a type declaration, about the members of a type (such as the constructors, methods, fields, properties, and events of a class), as well as the module and the assembly in which the class is deployed.

No permissions are required for code to use reflection to get information about types and their members, regardless of their access levels. No permissions are required for code to use reflection to access public members, or other members whose access levels would make them visible during normal compilation. However, in order for your code to use reflection to access members that would normally be inaccessible, such as private or internal methods, or protected fields of a type your class does not inherit, your code must have ReflectionPermission. See Security Considerations for Reflection.

Type is an abstract base class that allows multiple implementations. The system will always provide the derived class RuntimeType. In reflection, all classes beginning with the word Runtime are created only once per object in the system and support comparison operations.


Contextual keywords

A contextual keyword is used to provide a specific meaning in the code, but it is not a reserved word in C#. Some keywords are contextual, meaning they can also be used as identifiers—without an @ symbol.

These are:

addDefines a custom event accessor that is invoked when client code subscribes to the event.
asyncIndicates that the modified method, lambda expression, or anonymous method is asynchronous.
awaitSuspends an async method until an awaited task is completed.
dynamicDefines a reference type that enables operations in which it occurs to bypass compile-time type checking.
getDefines an accessor method for a property or an indexer.
globalSpecifies the default global namespace, which is otherwise unnamed.
partialDefines partial classes, structs, and interfaces throughout the same compilation unit.
removeDefines a custom event accessor that is invoked when client code unsubscribes from the event.
setDefines an accessor method for a property or an indexer.
valueUsed to set accessors and to add or remove event handlers.
varEnables the type of a variable declared at method scope to be determined by the compiler.
whereAdds constraints to a generic declaration. (See also where).
yieldUsed in an iterator block to return a value to the enumerator object or to signal the end of iteration.

With contextual keywords, ambiguity cannot arise within the context in which they are used.

The Future of C#

Do you know what Shared Access Signatures are?


Using a shared access signature (SAS) is a powerful way to grant limited access to objects in your storage account to other clients, without having to expose your account key. In Part 1 of this tutorial on shared access signatures, we'll provide an overview of the SAS model and review SAS best practices. Part 2 of the tutorial walks you through the process of creating shared access signatures with the Blob service.

What is a shared access signature?

A shared access signature provides delegated access to resources in your storage account. This means that you can grant a client limited permissions to objects in your storage account for a specified period of time and with a specified set of permissions, without having to share your account access keys. The SAS is a URI that encompasses in its query parameters all of the information necessary for authenticated access to a storage resource. To access storage resources with the SAS, the client only needs to pass in the SAS to the appropriate constructor or method.

When should you use a shared access signature?

You can use a SAS when you want to provide access to resources in your storage account to a client that can't be trusted with the account key. Your storage account keys include both a primary and secondary key, both of which grant administrative access to your account and all of the resources in it. Exposing either of your account keys opens your account to the possibility of malicious or negligent use. Shared access signatures provide a safe alternative that allows other clients to read, write, and delete data in your storage account according to the permissions you've granted, and without need for the account key.
A common scenario where a SAS is useful is a service where users read and write their own data to your storage account. In a scenario where a storage account stores user data, there are two typical design patterns:
1. Clients upload and download data via a front-end proxy service, which performs authentication. This front-end proxy service has the advantage of allowing validation of business rules, but for large amounts of data or high-volume transactions, creating a service that can scale to match demand may be expensive or difficult.
2. A lightweight service authenticates the client as needed and then generates a SAS. Once the client receives the SAS, they can access storage account resources directly with the permissions defined by the SAS and for the interval allowed by the SAS. The SAS mitigates the need for routing all data through the front-end proxy service.
Many real-world services may use a hybrid of these two approaches, depending on the scenario involved, with some data processed and validated via the front-end proxy while other data is saved and/or read directly using SAS.
Additionally, you will need to use a SAS to authenticate the source object in a copy operation in certain scenarios:
  • When you copy a blob to another blob that resides in a different storage account, you must use a SAS to authenticate the source blob. With version 2015-04-05, you can optionally use a SAS to authenticate the destination blob as well.
  • When you copy a file to another file that resides in a different storage account, you must use a SAS to authenticate the source file. With version 2015-04-05, you can optionally use a SAS to authenticate the destination file as well.
  • When you copy a blob to a file, or a file to a blob, you must use a SAS to authenticate the source object, even if the source and destination objects reside within the same storage account.

Types of shared access signatures

Version 2015-04-05 of Azure Storage introduces a new type of shared access signature, the account SAS. You can now create either of two types of shared access signatures:
  • Account SAS. The account SAS delegates access to resources in one or more of the storage services. All of the operations available via a service SAS are also available via an account SAS. Additionally, with the account SAS, you can delegate access to operations that apply to a given service, such as Get/Set Service Properties and Get Service Stats. You can also delegate access to read, write, and delete operations on blob containers, tables, queues, and file shares that are not permitted with a service SAS. See Constructing an Account SAS for in-depth information about about constructing the account SAS token.
  • Service SAS. The service SAS delegates access to a resource in just one of the storage services: the Blob, Queue, Table, or File service. See Constructing a Service SAS and Service SAS Examples for in-depth information about constructing the service SAS token.

How a shared access signature works

A shared access signature is a URI that points to one or more storage resources and includes a token that contains a special set of query parameters. The token indicates how the resources may be accessed by the client. One of the query parameters, the signature, is constructed from the SAS parameters and signed with the account key. This signature is used by Azure Storage to authenticate the SAS.
The account SAS and service SAS tokens include some common parameters, and also take a few parameters that that are different.

Parameters common to account SAS and service SAS tokens

  • Api version An optional parameter that specifies the storage service version to use to execute the request.
  • Service version A required parameter that specifies the storage service version to use to authenticate the request.
  • Start time. This is the time at which the SAS becomes valid. The start time for a shared access signature is optional; if omitted, the SAS is effective immediately.
  • Expiry time. This is the time after which the SAS is no longer valid. Best practices recommend that you either specify an expiry time for a SAS, or associate it with a stored access policy (see more below).
  • Permissions. The permissions specified on the SAS indicate what operations the client can perform against the storage resource using the SAS. Available permissions differ for an account SAS and a service SAS.
  • IP. An optional parameter that specifies an IP address or a range of IP addresses outside of Azure (see the section Routing session configuration state for Express Route) from which to accept requests.
  • Protocol. An optional parameter that specifies the protocol permitted for a request. Possible values are both HTTPS and HTTP (https,http), which is the default value, or HTTPS only (https). Note that HTTP only is not a permitted value.
  • Signature. The signature is constructed from the other parameters specified as part token and then encrypted. It's used to authenticate the SAS.

Parameters for an account SAS token

  • Service or services. An account SAS can delegate access to one or more of the storage services. For example, you can create an account SAS that delegates access to the Blob and File service. Or you can create a SAS that delegates access to all four services (Blob, Queue, Table, and File).
  • Storage resource types. An account SAS applies to one or more classes of storage resources, rather than a specific resource. You can create an account SAS to delegate access to:
    • Service-level APIs, which are called against the storage account resource. Examples includeGet/Set Service PropertiesGet Service Stats, and List Containers/Queues/Tables/Shares.
    • Container-level APIs, which are called against the container objects for each service: blob containers, queues, tables, and file shares. Examples include Create/Delete Container,Create/Delete QueueCreate/Delete TableCreate/Delete Share, and List Blobs/Files and Directories.
    • Object-level APIs, which are called against blobs, queue messages, table entities, and files. For example, Put BlobQuery EntityGet Messages, and Create File.

Parameters for a service SAS token

  • Storage resource. Storage resources for which you can delegate access with a service SAS include:
    • Containers and blobs
    • File shares and files
    • Queues
    • Tables and ranges of table entities.

More information

Do you know when to use the different WCF Context Modes?

Let's talk about WCF's InstanceContextMode, give a brief overview of the possible values and determine when to use them.

InstanceContextMode is a property on the ServiceBehaviorAttribute class in .NET Framework 4.5. A developer will use the InstanceContextMode property to specify when new service objects are created.

Because the service object is not directly connected to the communicating channel, the lifetime of the service objects is independent of the lifetime of the channel between a client and the service application. The default value, PerSession, instructs the service application to create a new service object when a new communication session is established between a client and the service application. Subsequent calls in the same session are handled by the same object.

There are 3 context modes in WCF:

  1. PerCall
  2. PerSession (Default)
  3. Single

The default value, PerSession, instructs the service application to create a new service object when a new communication session is established between a client and the service application. Subsequent calls in the same session are handled by the same object. PerSession indicates that each service object handles requests from one client channel. A service configured for private sessions cannot typically support more than a few dozen (or perhaps up to a few hundred) outstanding clients due to the cost associated with each such dedicated service instance.

PerCall creates a new InstanceContext object prior to and recycled subsequent to each call. If the channel does not create a session this value behaves as if it were PerCall. After the method call returns, if the object implements IDisposable, then Windows Communication Foundation calls IDisposable.Dispose on it.

Single creates only one InstanceContext object. It is used for all incoming calls and is not recycled subsequent to the calls. If a service object does not exist, one is created. The singleton service is the ultimate shareable service. When a service is configured as a singleton, all clients get connected to the same single well-known instance independently of each other, regardless of which endpoint of the service they connect to. The singleton service lives forever, and is only disposed of once the host shuts down. The singleton is created exactly once when the host is created.

Which instance context mode to use and when

Per session (Default)

• When you want to maintain states between WCF calls.
• When you don't have very many concurrent connections and don't need to scale up.
• When you have light resource references

Per call

• When you want a stateless services
• When your service holds intensive resources like connection and huge memory objects.
• When scalability is a prime requirement.
• When your WCF functions are called in a single threaded model.


• When you want share global data through your WCF service.
• When scalability is not a concern.

Do you follow SOLID principles? If you don't, you may be doing yourself a disservice

From wikipedia: In computer programming, SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) is a mnemonic acronym introduced by Michael Feathers for the "first five principles" named by Robert C. Martin in the early 2000s that stands for five basic principles of object-oriented programming and design. The principles, when applied together, intend to make it more likely that a programmer will create a system that is easy to maintain and extend over time. The principles of SOLID are guidelines that can be applied while working on software to remove code smells by causing the programmer to refactor the software's source code until it is both legible and extensible. It is part of an overall strategy of agile and adaptive programming.

S (SRP) - Single responsibility principle states that a class should have only a single responsibility 

O (OCP) - Open/closed principle states that software entities should be open for extension, but closed for modification.

L (LSP) - Liskov substitution principle states that objects in a program should be replaceable with instances of their sub-types without altering the correctness of that program. (See also design by contract.)

I (ISP) - Interface segregation principle states that many client-specific interfaces are better than one general-purpose interface.

D (DIP) - Dependency inversion states that we depend upon abstractions not concretions.

You will find that many higher level jobs, specifically jobs for domain, data or enterprise level architecture will require you know what SOLID is and abide by its principles. As you will see, SOLID is fairly straight-forward, however if you find that you don't understand any of the principles stated here, SOLID principles hedges against anti-patterns as well as problems with application coupling, rigidity and fragility. I urge you to do further research so you understand these principles. They are basic and fundamental principles that any good program would know.