AddIfNotNull collection extensions

I want to post a few recently created collection extensions to write in one line, what otherwise takes 2 or more
     public static void AddIfNotNull( this IList coll, T newItem) where T : class
        {
            if (newItem != null)
            {
                coll.Add(newItem);
            }
        }

         public static void AddRangeIfNotNullOrEmpty( this List coll, IEnumerable newItems) where T : class
        {
            if (!newItems.IsNullOrEmptySequence())
            {
                coll.AddRange(newItems);
            }
        }
 
  public static void AddIfNotContains( this Dictionary dictionary,  TKey key, TValue value)
        {
            if (!dictionary.ContainsKey(key))
            {
                dictionary.Add(key, value);
            }
        }
The methods use
public static bool IsNullOrEmptySequence(this IEnumerable c)
              {
                      return (c == null || !c.Any() );
              }

I’ve also found a few extensions, that could be useful in https://pikacode.com/Barankin/Fabrika-dveri/file/default/CRM/Common/Extensions/LinqExtensions.cs

Override ToString() using Json serialization or something else.

When creating a new data class, it’s a good idea to override ToString() method to output most of the data.
It will help to see details in logs.

The only exception if the class has a sensitive data like CreditCard number or password.
For DataContract classes just use

public override string ToString()
              {
                      //Use JSON as the simplest serializer
                      string sRet = this.ToExtJsJsonItem();
                      return sRet;
              }
 
Sometimes it is useful to create extensions to standard .Net classes.
E.g. In CookieHelper class I’ve created
  public static string ToJsonString( this HttpCookie httpCookie)
        {
            string sRet = httpCookie.ToExtJsJsonItem();
            return sRet;
        }
 
The actual extension we are using was written by Nikita Pinchuk
      public static string ToExtJsJsonItem( this object item)
        {
            DataContractJsonSerializer serializer = new DataContractJsonSerializer(item.GetType());
            using ( MemoryStream ms = new MemoryStream ())
            {
                serializer.WriteObject(ms, item);
                StringBuilder sb = new StringBuilder ();

                sb.Append( Encoding.UTF8.GetString(ms.ToArray()));

                return sb.ToString();
            }
        }
 
For non DataContract classes the extension method may not work-it could cause an error: 
A first chance exception of type ‘System.Runtime.Serialization.InvalidDataContractException’ occurred in System.Runtime.Serialization.dll

In this case you can try  JSON.NET or the JsonValue types (nuget package JsonValue).

Sometimes I am using
 string sRet = this.XmlSerializeSafe();
 
But it is also not working for all types, e.g. 
MyClass cannot be serialized because it does not have a parameterless constructor.
In some places we are using LinqPad’s Dump an arbitrary object To Html String, but we found it is too heavy for logs, plain text is easier to read than HTML.
I haven’t tried yet ServiceStack.Text  C# .NET Extension method: T.Dump();

Deploy PDB files into production to ease exception report investigation.

 

 For a long time I believed that PDB as a part of debugging information should not be included in production deployment. Recently my colleague suggested to copy them to simplify exception investigations. 

 

The following  SO discussion convinced us that it is a good idea  ( at least for web sites).

 http://stackoverflow.com/questions/933883/are-there-any-security-issues-leaving-the-pdb-debug-files-on-the-live-servers

    These files will not be exposed to the public if kept in the right places (websitebin). 

 
 So we decided to deploy the PDBs into production.
 

BTW, if you include PDBs with your deployments, you don’t need to store them in a symbol server,

 as it is suggested in http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/05/11/pdb-files-what-every-developer-must-know.aspx

However we found that  PDBs   were generated not for all DLLs.  After some analysis we believe that MS changed default settings starting from VS 2008 (or may be since VS 2005) and make generation of PDB-only even for release mode. This is why older projects had generation of PDBs disabled.

To change setting in Visual Studio there is an option in the “Project Properties”, “Build”, “Advanced…”.

Change “Debug Info:” to PDB-only.

The screenshots are available in the posthttp://callicode.com/Homeltpagegt/tabid/38/EntryId/24/How-to-disable-pdb-generation-in-Visual-Studio-2008.aspx

 

Related links:
The article http://blog.vuscode.com/malovicn/archive/2007/08/05/releasing-the-build.aspx compares different options for debug and release and confirms that in 2007 pdbonly was the default for release configuration of visual studio   
              

/optimize+ /debug:pdbonly (release configuration of visual studio)

The article Include .pdb files in Web Application Publish for Release mode (VS2012)  wasn’t applicable for us, but may be useful for someone else.