NDepend

Improve your .NET code quality with NDepend

Author: Patrick Smacchia

My dad being an early programmer in the 70's, I have been fortunate to switch from playing with Lego, to program my own micro-games, when I was still a kid. Since then I never stop programming. I graduated in Mathematics and Software engineering. After a decade of C++ programming and consultancy, I got interested in the brand new .NET platform in 2002. I had the chance to write the best-seller book (in French) on .NET and C#, published by O'Reilly (> 15.000 copies) and also did manage some academic and professional courses on the platform and C#. Over the years, I gained a passion for understanding structure and evolution of large complex real-world applications, and for talking with talented developers behind it. As a consequence, I got interested in static code analysis and started the project NDepend. Today, with more than 8.000 client companies, including many of the Fortune 500 ones, NDepend offers deeper insight and understanding about their code bases to a wide range of professional users around the world. I live with my wife and our twin babies Léna and Paul, in the beautiful island of Mauritius in the Indian Ocean.

Exploring .NET Core 3.0 new API

.NET Core 3.0 is representing a major step for the .NET community. It is interesting to analyze what’s new in the API directly from the compiled bits. In this post I will first explain how to diff .NET Core 3.0 against .NET Core 2.2 with NDepend, and then how to browse diff results.

Arguably the biggest progress of .NET Core 3.0 will be the support for Winforms and WPF on the Windows platform. Since everything is new here, compare to .NET Core 2.2, we won’t analyze this part. However it will be interesting to analyze .NET Fx Winforms/WPF APIs vs .NET Core 3.0 Winforms/WPF APIs in another post.

Analyzing two versions of .NET Core with NDepend

It takes a few minutes to download NDepend trial, install it and start VisualNDepend.exe, and it takes a few minutes to compare .NET Core 3.0 against .NET Core 2.2. If you want to browse the diff on your machine, expect 5 to 10 minutes to get hands-on.

First Start VisualNDepend.exe and click Compare 2 versions of a code base:

How to compare 2 versions of a code base

For both builds, choose Add Assemblies in Folder:

Choose C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.2.2 for Older Build
Choose C:\Program Files\dotnet\shared\Microsoft.NETCore.App\3.0.0-preview-27324-5 for Newer Build

Respectively 156 and 161 assemblies are gathered. Click Ok to run two analysis, on older and newer build. Both analysis results will be then diffed automatically.

Ready to compare 2 versions of .NET Core

Querying new API

Let’s start with a few CQLinq code queries to explore the new .NET Core 3.0 APIs:

This query match all new public code elements, including new assemblies, namespace, types, methods and fields:

from x in Application.CodeElements
where x.WasAdded()  
 && (!x.IsTypeOrMember || x.AsTypeOrMember.IsPubliclyVisible)
select x

from x in Application.CodeElements

where x.WasAdded()

&& (!x.IsTypeOrMember || x.AsTypeOrMember.IsPubliclyVisible)

select x

Use the NDepend query result to browse this large new API set : 5 new assemblies, 83 new namespaces, 297 new types, 4 924 new methods and 307 new fields. Note that code elements with pink background are not matched by the query, they are just here for preserving the code hierarchy in the result:

Download here this long list obtained by exporting the query result to excel. For a better result formatting I actually used this refined query to show properly parent assemblies/namespaces/types in excel columns:

from x in Application.CodeElements
where x.WasAdded()  
 && (!x.IsTypeOrMember || x.AsTypeOrMember.IsPubliclyVisible)
select new { x, 
Assembly = x.IsAssembly ?  x.Name : 
           x.IsNamespace ? x.Parent.Name : 
                           x.AsTypeOrMember.ParentAssembly.Name,

Namespace = x.IsAssembly ?  " " : 
            x.IsNamespace ? x.Name: 
                            x.AsTypeOrMember.ParentNamespace.Name,

Type = x.IsAssembly ? " " :
       x.IsNamespace ? " " :
       x.IsType ? x.Name:
       x.AsMember.ParentType.Name,

Member = x.IsMember ? x.Name : " "
}

from x in Application.CodeElements

where x.WasAdded()

&& (!x.IsTypeOrMember || x.AsTypeOrMember.IsPubliclyVisible)

select new { x,

Assembly = x.IsAssembly ? x.Name :

x.IsNamespace ? x.Parent.Name :

x.AsTypeOrMember.ParentAssembly.Name,

Namespace = x.IsAssembly ? " " :

x.IsNamespace ? x.Name:

x.AsTypeOrMember.ParentNamespace.Name,

Type = x.IsAssembly ? " " :

x.IsNamespace ? " " :

x.IsType ? x.Name:

x.AsMember.ParentType.Name,

Member = x.IsMember ? x.Name : " "

}

It is interesting to just focus on the 297 new public types with the code query below. Download the list here or browse the same list at the end of this post.

from t in Application.Types
where t.IsPubliclyVisible && t.WasAdded() 
select t

from t in Application.Types

where t.IsPubliclyVisible && t.WasAdded()

select t

It is also interesting to browse the new 1.101 public methods and 38 public fields added on public types that existed already in .NET Core 2.2. Download this list here.

from m in Application.Members
where m.IsPubliclyVisible 
   && m.WasAdded()
   && !m.ParentType.WasAdded()
select new { m }

from m in Application.Members

where m.IsPubliclyVisible

&& m.WasAdded()

&& !m.ParentType.WasAdded()

select new { m }

API Breaking Changes

NDepend proposes 6 default rules to browse API breaking changes.

These rules matche 19 public types removed from .NET Core 2.2 (see list below) 176 public methods removed and 36 public fields removed

Listing Methods Changed

Exploring the API evolution is useful for API consumers. For those working on the framework .NET Core itself, it is interesting to also browse implementation changes. The NDepend search by change panel proposes various options for that. Note that this search panel is actually a code query generator. The Edit query button proposes to edit and refine the currently generated query.

Another interesting point is that it is a semantic implementation change. All matched methods do behave differently at runtime. This makes this tool ideal to plan code change review without bothering with formatting and comments change.

Matched code elements can be highlighted in the metric view. From the screenshot above we can see at a glance that System.Xml and System.Data are much more stable than System.RunTime for example. By zooming in the view, we can get more information about which code was churned.

In the query result panel, a code element is underlined when its implementation changed. If you have compiled both source versions on your machine and analyzed those compiled versions, you can right click an underlined method and directly compare the diff in source code.

I hope you see value both in the results offered and in the how-to-diff procedure that can be applied to any .NET code base, assuming you have 2 versions to compare.

New .NET Core 3.0 types

Here is the list of the 297 new types added to .NET Core 3.0.

ParentAssembly	Full Name
WindowsBase	System.Windows.Markup .ValueSerializerAttribute
System.Xml.Linq	System.Xml.XPath.XDocumentExtensions
System.Threading.ThreadPool	System.Threading.IThreadPoolWorkItem
System.Threading.Tasks	System.Runtime.CompilerServices .AsyncIteratorMethodBuilder
System.Threading.Tasks	System.Runtime.CompilerServices .ConfiguredCancelableAsyncEnumerable<T>
System.Text.Json	System.Text.Json.JsonCommentHandling
System.Text.Json	System.Text.Json.JsonTokenType
System.Text.Json	System.Text.Json.JsonDocument
System.Text.Json	System.Text.Json.JsonElement
System.Text.Json	System.Text.Json .JsonElement+ArrayEnumerator
System.Text.Json	System.Text.Json .JsonElement+ObjectEnumerator
System.Text.Json	System.Text.Json.JsonProperty
System.Text.Json	System.Text.Json.JsonValueType
System.Text.Json	System.Text.Json.JsonReaderException
System.Text.Json	System.Text.Json.JsonReaderOptions
System.Text.Json	System.Text.Json.JsonReaderState
System.Text.Json	System.Text.Json.Utf8JsonReader
System.Text.Json	System.Text.Json.JsonWriterOptions
System.Text.Json	System.Text.Json.JsonWriterState
System.Text.Json	System.Text.Json.Utf8JsonWriter
System.Security.Principal.Windows	System.Security.Principal .WindowsAccountType
System.Security.Cryptography.Primitives	System.Security.Cryptography .PbeEncryptionAlgorithm
System.Security.Cryptography.Primitives	System.Security.Cryptography .PbeParameters
System.Security.Cryptography.Algorithms	System.Security.Cryptography.AesCcm
System.Security.Cryptography.Algorithms	System.Security.Cryptography.AesGcm
System.Runtime.WindowsRuntime.UI.Xaml	Windows.UI.Xaml.CornerRadius
System.Runtime.WindowsRuntime.UI.Xaml	Windows.UI.Xaml.DurationType
System.Runtime.WindowsRuntime.UI.Xaml	Windows.UI.Xaml.Duration
System.Runtime.WindowsRuntime.UI.Xaml	Windows.UI.Xaml.GridUnitType
System.Runtime.WindowsRuntime.UI.Xaml	Windows.UI.Xaml.GridLength
System.Runtime.WindowsRuntime.UI.Xaml	Windows.UI.Xaml.Thickness
System.Runtime.WindowsRuntime.UI.Xaml	Windows.UI.Xaml.LayoutCycleException
System.Runtime.WindowsRuntime.UI.Xaml	Windows.UI.Xaml.Markup .XamlParseException
System.Runtime.WindowsRuntime.UI.Xaml	Windows.UI.Xaml.Automation .ElementNotAvailableException
System.Runtime.WindowsRuntime.UI.Xaml	Windows.UI.Xaml.Automation .ElementNotEnabledException
System.Runtime.WindowsRuntime.UI.Xaml	Windows.UI.Xaml.Media.Matrix
System.Runtime.WindowsRuntime.UI.Xaml	Windows.UI.Xaml.Media.Media3D.Matrix3D
System.Runtime.WindowsRuntime.UI.Xaml	Windows.UI.Xaml.Media.Animation.KeyTime
System.Runtime.WindowsRuntime.UI.Xaml	Windows.UI.Xaml.Media.Animation .RepeatBehaviorType
System.Runtime.WindowsRuntime.UI.Xaml	Windows.UI.Xaml.Media.Animation .RepeatBehavior
System.Runtime.WindowsRuntime.UI.Xaml	Windows.UI.Xaml.Controls.Primitives .GeneratorPosition
System.Runtime.WindowsRuntime	Windows.UI.Color
System.Runtime.WindowsRuntime	Windows.Foundation.Point
System.Runtime.WindowsRuntime	Windows.Foundation.Rect
System.Runtime.WindowsRuntime	Windows.Foundation.Size
System.Runtime.WindowsRuntime	System.WindowsRuntimeSystemExtensions
System.Runtime.WindowsRuntime	System.IO .WindowsRuntimeStorageExtensions
System.Runtime.WindowsRuntime	System.IO.WindowsRuntimeStreamExtensions
System.Runtime.WindowsRuntime	System.Threading.DispatcherQueueHandler
System.Runtime.WindowsRuntime	System.Threading.DispatcherQueuePriority
System.Runtime.WindowsRuntime	System.Runtime.InteropServices .WindowsRuntime.AsyncInfo
System.Runtime.WindowsRuntime	System.Runtime.InteropServices .WindowsRuntime.WindowsRuntimeBuffer
System.Runtime.WindowsRuntime	System.Runtime.InteropServices .WindowsRuntime .WindowsRuntimeBufferExtensions
System.Runtime.Serialization	System.Runtime.Serialization .ISerializationSurrogateProvider
System.Runtime.Loader	System.Runtime.Loader .AssemblyDependencyResolver
System.Runtime.Intrinsics	System.MidpointRounding
System.Runtime.Intrinsics	System.Runtime.Intrinsics.Vector64
System.Runtime.Intrinsics	System.Runtime.Intrinsics.Vector64<T>
System.Runtime.Intrinsics	System.Runtime.Intrinsics.Vector128
System.Runtime.Intrinsics	System.Runtime.Intrinsics.Vector128<T>
System.Runtime.Intrinsics	System.Runtime.Intrinsics.Vector256
System.Runtime.Intrinsics	System.Runtime.Intrinsics.Vector256<T>
System.Runtime.Intrinsics	System.Runtime.Intrinsics.X86 .FloatComparisonMode
System.Runtime.Intrinsics	System.Runtime.Intrinsics.X86.Aes
System.Runtime.Intrinsics	System.Runtime.Intrinsics.X86.Avx
System.Runtime.Intrinsics	System.Runtime.Intrinsics.X86.Avx2
System.Runtime.Intrinsics	System.Runtime.Intrinsics.X86.Bmi1
System.Runtime.Intrinsics	System.Runtime.Intrinsics.X86.Bmi2
System.Runtime.Intrinsics	System.Runtime.Intrinsics.X86.Fma
System.Runtime.Intrinsics	System.Runtime.Intrinsics.X86.Lzcnt
System.Runtime.Intrinsics	System.Runtime.Intrinsics.X86.Pclmulqdq
System.Runtime.Intrinsics	System.Runtime.Intrinsics.X86.Popcnt
System.Runtime.Intrinsics	System.Runtime.Intrinsics.X86.Sse
System.Runtime.Intrinsics	System.Runtime.Intrinsics.X86.Sse2
System.Runtime.Intrinsics	System.Runtime.Intrinsics.X86.Sse3
System.Runtime.Intrinsics	System.Runtime.Intrinsics.X86.Sse41
System.Runtime.Intrinsics	System.Runtime.Intrinsics.X86.Sse42
System.Runtime.Intrinsics	System.Runtime.Intrinsics.X86.Ssse3
System.Runtime.Intrinsics	System.Runtime.Intrinsics.Arm.Arm64.Aes
System.Runtime.Intrinsics	System.Runtime.Intrinsics.Arm.Arm64.Base
System.Runtime.Intrinsics	System.Runtime.Intrinsics.Arm.Arm64.Sha1
System.Runtime.Intrinsics	System.Runtime.Intrinsics.Arm.Arm64 .Sha256
System.Runtime.Intrinsics	System.Runtime.Intrinsics.Arm.Arm64.Simd
System.Runtime.InteropServices	System.Runtime.CompilerServices .IDispatchConstantAttribute
System.Runtime.InteropServices	System.Runtime.InteropServices .StandardOleMarshalObject
System.Runtime.InteropServices	System.Runtime.InteropServices .NativeLibrary
System.Runtime.Extensions	System.AppDomainSetup
System.Runtime.Extensions	System.Security.IStackWalk
System.Runtime.Extensions	System.Security.PermissionSet
System.Runtime.Extensions	System.Security.Permissions .PermissionState
System.Runtime.Extensions	System.Runtime.ProfileOptimization
System.Runtime	System.ArgIterator
System.Runtime	System.IAsyncDisposable
System.Runtime	System.Index
System.Runtime	System.Range
System.Runtime	System.Text.Rune
System.Runtime	System.Text.StringRuneEnumerator
System.Runtime	System.Globalization.ISOWeek
System.Runtime	System.Threading.Tasks.Sources .ManualResetValueTaskSourceCore<TResult>
System.Runtime	System.Runtime.Remoting.ObjectHandle
System.Runtime	System.Runtime.CompilerServices .AsyncIteratorStateMachineAttribute
System.Runtime	System.Runtime.CompilerServices .CallerArgumentExpressionAttribute
System.Runtime	System.Collections.Generic .IAsyncEnumerable<T>
System.Runtime	System.Collections.Generic .IAsyncEnumerator<T>
System.Private.CoreLib	System.IAsyncDisposable
System.Private.CoreLib	System.Index
System.Private.CoreLib	System.Range
System.Private.CoreLib	System.Text .StringBuilder+ChunkEnumerator
System.Private.CoreLib	System.Text.Rune
System.Private.CoreLib	System.Text.SpanRuneEnumerator
System.Private.CoreLib	System.Text.StringRuneEnumerator
System.Private.CoreLib	System.Globalization.ISOWeek
System.Private.CoreLib	System.Buffers.OperationStatus
System.Private.CoreLib	System.Buffers.StandardFormat
System.Private.CoreLib	System.Buffers.Text.Utf8Formatter
System.Private.CoreLib	System.Buffers.Text.Utf8Parser
System.Private.CoreLib	System.Buffers.Binary.BinaryPrimitives
System.Private.CoreLib	System.Threading.Tasks.Sources .ManualResetValueTaskSourceCore<TResult>
System.Private.CoreLib	System.Runtime.Remoting.ObjectHandle
System.Private.CoreLib	System.Runtime.Loader .AssemblyDependencyResolver
System.Private.CoreLib	System.Runtime.CompilerServices .AsyncIteratorMethodBuilder
System.Private.CoreLib	System.Runtime.CompilerServices .AsyncIteratorStateMachineAttribute
System.Private.CoreLib	System.Runtime.CompilerServices .CallerArgumentExpressionAttribute
System.Private.CoreLib	System.Runtime.CompilerServices .ConfiguredCancelableAsyncEnumerable<T>
System.Private.CoreLib	System.Runtime.CompilerServices .ConfiguredCancelableAsyncEnumerable<T >+Enumerator
System.Private.CoreLib	System.Runtime.Intrinsics.Vector64
System.Private.CoreLib	System.Runtime.Intrinsics.Vector128
System.Private.CoreLib	System.Runtime.Intrinsics.Vector256
System.Private.CoreLib	System.Runtime.Intrinsics.X86.Bmi1+X64
System.Private.CoreLib	System.Runtime.Intrinsics.X86.Bmi2+X64
System.Private.CoreLib	System.Runtime.Intrinsics.X86.Lzcnt+X64
System.Private.CoreLib	System.Runtime.Intrinsics.X86.Popcnt+X64
System.Private.CoreLib	System.Runtime.Intrinsics.X86.Sse+X64
System.Private.CoreLib	System.Runtime.Intrinsics.X86.Sse2+X64
System.Private.CoreLib	System.Runtime.Intrinsics.X86.Sse41+X64
System.Private.CoreLib	System.Runtime.Intrinsics.X86.Sse42+X64
System.Private.CoreLib	System.Runtime.InteropServices .DllImportResolver
System.Private.CoreLib	System.Runtime.InteropServices .NativeLibrary
System.Private.CoreLib	System.Runtime.InteropServices .ComActivationContext
System.Private.CoreLib	System.Runtime.InteropServices .ComActivationContextInternal
System.Private.CoreLib	System.Runtime.InteropServices .ComActivator
System.Private.CoreLib	System.Runtime.InteropServices .ComEventInterfaceAttribute
System.Private.CoreLib	System.Runtime.InteropServices .DefaultParameterValueAttribute
System.Private.CoreLib	System.Diagnostics.DebugProvider
System.Private.CoreLib	System.Collections.Generic .IAsyncEnumerable<T>
System.Private.CoreLib	System.Collections.Generic .IAsyncEnumerator<T>
System.Private.CoreLib	Internal.Resources.PRIExceptionInfo
System.Private.CoreLib	Internal.Resources .WindowsRuntimeResourceManagerBase
System.Private.CoreLib	Internal.Threading.Tasks .AsyncCausalitySupport
System.Private.CoreLib	Internal.Runtime.InteropServices .WindowsRuntime.ExceptionSupport
System.ObjectModel	System.Reflection.ICustomTypeProvider
System.ObjectModel	System.ComponentModel .TypeConverterAttribute
System.ObjectModel	System.ComponentModel .TypeDescriptionProviderAttribute
System.ObjectModel	System.Windows.Markup .ValueSerializerAttribute
System.Net.Sockets	System.Net.Sockets.SafeSocketHandle
System.Memory	System.Text.SpanRuneEnumerator
System.Memory	System.Buffers.SequenceReader<T>
System.Memory	System.Buffers.SequenceReaderExtensions
System	System.StringNormalizationExtensions
System	System.Reflection.ICustomTypeProvider
System	System.Windows.Markup .ValueSerializerAttribute
System	System.Runtime.InteropServices .StandardOleMarshalObject
System	System.Diagnostics.ConsoleTraceListener
System	System.Diagnostics .XmlWriterTraceListener
System	System.Diagnostics.StackFrameExtensions
System	System.Security.SecureStringMarshal
System	System.Net.Sockets .SocketReceiveFromResult
System	System.Net.Sockets .SocketReceiveMessageFromResult
System	System.Net.Sockets.SocketTaskExtensions
System.Diagnostics.TextWriterTraceListener	System.Diagnostics.ConsoleTraceListener
System.Diagnostics.TextWriterTraceListener	System.Diagnostics .XmlWriterTraceListener
System.Data	System.Xml.XmlDataDocument
System.Data	System.Data.Common.DbColumn
System.Data	System.Data.Common .DbDataReaderExtensions
System.Data	System.Data.Common .IDbColumnSchemaGenerator
System.Core	System.Security.Cryptography.AesCng
System.Core	System.Security.Cryptography.DSACng
System.Core	System.Security.Cryptography .TripleDESCng
System.Core	System.Security.Cryptography.ECCurve
System.Core	System.Security.Cryptography .ECParameters
System.Core	System.Security.Cryptography.ECPoint
System.Core	System.Security.Cryptography .IncrementalHash
System.Core	System.Security.Cryptography .X509Certificates.CertificateRequest
System.Core	System.Security.Cryptography .X509Certificates .DSACertificateExtensions
System.Core	System.Security.Cryptography .X509Certificates .SubjectAlternativeNameBuilder
System.Core	System.Security.Cryptography .X509Certificates.X509SignatureGenerator
System.ComponentModel.TypeConverter	System.ComponentModel.VersionConverter
System.ComponentModel.Primitives	System.ComponentModel .InvalidAsynchronousStateException
System.ComponentModel.DataAnnotations	System.ComponentModel.DataAnnotations .AssociatedMetadataTypeTypeDescriptionPr ovider
System.ComponentModel.DataAnnotations	System.ComponentModel.DataAnnotations .MetadataTypeAttribute
System.ComponentModel.Annotations	System.ComponentModel.DataAnnotations .AssociatedMetadataTypeTypeDescriptionPr ovider
System.ComponentModel.Annotations	System.ComponentModel.DataAnnotations .MetadataTypeAttribute
mscorlib	System.TupleExtensions
mscorlib	System.AppDomainSetup
mscorlib	System.Globalization .GlobalizationExtensions
mscorlib	System.Threading.ThreadPoolBoundHandle
mscorlib	System.Threading.PreAllocatedOverlapped
mscorlib	System.Runtime.ProfileOptimization
mscorlib	System.Runtime.Remoting.ObjectHandle
mscorlib	System.Runtime.CompilerServices .RuntimeFeature
mscorlib	System.Runtime.CompilerServices .IsByRefLikeAttribute
mscorlib	System.Runtime.CompilerServices.ITuple
mscorlib	System.Runtime.CompilerServices .IsReadOnlyAttribute
mscorlib	System.Runtime.CompilerServices .TupleElementNamesAttribute
mscorlib	System.Runtime.CompilerServices .IDispatchConstantAttribute
mscorlib	System.Runtime.InteropServices .RuntimeInformation
mscorlib	System.Runtime.InteropServices .Architecture
mscorlib	System.Runtime.InteropServices .OSPlatform
mscorlib	System.Reflection.Emit.DynamicILInfo
mscorlib	System.Security.IStackWalk
mscorlib	System.Security.PermissionSet
mscorlib	System.Security.Permissions .PermissionState
mscorlib	System.Security.Principal .WindowsAccountType
mscorlib	System.Diagnostics.Tracing .EventSourceCreatedEventArgs
Microsoft.VisualBasic	Microsoft.VisualBasic.Collection
Microsoft.VisualBasic	Microsoft.VisualBasic.CompareMethod
Microsoft.VisualBasic	Microsoft.VisualBasic.ComClassAttribute
Microsoft.VisualBasic	Microsoft.VisualBasic.ControlChars
Microsoft.VisualBasic	Microsoft.VisualBasic.DateAndTime
Microsoft.VisualBasic	Microsoft.VisualBasic.Information
Microsoft.VisualBasic	Microsoft.VisualBasic .MyGroupCollectionAttribute
Microsoft.VisualBasic	Microsoft.VisualBasic.VariantType
Microsoft.VisualBasic	Microsoft.VisualBasic .VBFixedArrayAttribute
Microsoft.VisualBasic	Microsoft.VisualBasic .VBFixedStringAttribute
Microsoft.VisualBasic	Microsoft.VisualBasic.VBMath
Microsoft.VisualBasic	Microsoft.VisualBasic.FileIO.FileSystem
Microsoft.VisualBasic	Microsoft.VisualBasic.FileIO .DeleteDirectoryOption
Microsoft.VisualBasic	Microsoft.VisualBasic.FileIO .RecycleOption
Microsoft.VisualBasic	Microsoft.VisualBasic.FileIO .SearchOption
Microsoft.VisualBasic	Microsoft.VisualBasic.FileIO .UICancelOption
Microsoft.VisualBasic	Microsoft.VisualBasic.FileIO.UIOption
Microsoft.VisualBasic	Microsoft.VisualBasic.FileIO .MalformedLineException
Microsoft.VisualBasic	Microsoft.VisualBasic.FileIO .SpecialDirectories
Microsoft.VisualBasic	Microsoft.VisualBasic.FileIO .TextFieldParser
Microsoft.VisualBasic	Microsoft.VisualBasic.FileIO.FieldType
Microsoft.VisualBasic	Microsoft.VisualBasic.CompilerServices .BooleanType
Microsoft.VisualBasic	Microsoft.VisualBasic.CompilerServices .DecimalType
Microsoft.VisualBasic	Microsoft.VisualBasic.CompilerServices .Versioned
Microsoft.VisualBasic	Microsoft.VisualBasic.CompilerServices .DoubleType
Microsoft.VisualBasic	Microsoft.VisualBasic .ApplicationServices.StartupEventArgs
Microsoft.VisualBasic	Microsoft.VisualBasic .ApplicationServices .StartupNextInstanceEventArgs
Microsoft.VisualBasic	Microsoft.VisualBasic .ApplicationServices .UnhandledExceptionEventArgs
Microsoft.VisualBasic	Microsoft.VisualBasic.Devices .NetworkAvailableEventArgs
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.CallType
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.Collection
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.CompareMethod
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.ComClassAttribute
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.Constants
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.ControlChars
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.DateAndTime
Microsoft.VisualBasic.Core	Microsoft.VisualBasic .HideModuleNameAttribute
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.Information
Microsoft.VisualBasic.Core	Microsoft.VisualBasic .MyGroupCollectionAttribute
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.Strings
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.VariantType
Microsoft.VisualBasic.Core	Microsoft.VisualBasic .VBFixedArrayAttribute
Microsoft.VisualBasic.Core	Microsoft.VisualBasic .VBFixedStringAttribute
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.VBMath
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.FileIO.FileSystem
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.FileIO .DeleteDirectoryOption
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.FileIO .RecycleOption
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.FileIO .SearchOption
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.FileIO .UICancelOption
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.FileIO.UIOption
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.FileIO .MalformedLineException
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.FileIO .SpecialDirectories
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.FileIO .TextFieldParser
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.FileIO.FieldType
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.CompilerServices .BooleanType
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.CompilerServices .Conversions
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.CompilerServices .DecimalType
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.CompilerServices .DesignerGeneratedAttribute
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.CompilerServices .SiteDelegate0
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.CompilerServices .SiteDelegate1
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.CompilerServices .SiteDelegate2
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.CompilerServices .SiteDelegate3
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.CompilerServices .SiteDelegate4
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.CompilerServices .SiteDelegate5
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.CompilerServices .SiteDelegate6
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.CompilerServices .SiteDelegate7
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.CompilerServices .IncompleteInitialization
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.CompilerServices .NewLateBinding
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.CompilerServices .ObjectFlowControl
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.CompilerServices .ObjectFlowControl+ForLoopControl
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.CompilerServices .Operators
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.CompilerServices .OptionCompareAttribute
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.CompilerServices .OptionTextAttribute
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.CompilerServices .ProjectData
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.CompilerServices .StandardModuleAttribute
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.CompilerServices .StaticLocalInitFlag
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.CompilerServices .Utils
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.CompilerServices .Versioned
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.CompilerServices .DoubleType
Microsoft.VisualBasic.Core	Microsoft.VisualBasic .ApplicationServices.StartupEventArgs
Microsoft.VisualBasic.Core	Microsoft.VisualBasic .ApplicationServices .StartupNextInstanceEventArgs
Microsoft.VisualBasic.Core	Microsoft.VisualBasic .ApplicationServices .UnhandledExceptionEventArgs
Microsoft.VisualBasic.Core	Microsoft.VisualBasic.Devices .NetworkAvailableEventArgs

Advanced Code Search : A Case Study

This morning I stumbled on a complex test to write. The need was to create and show a custom Form (written with Windows Form) that relies on the System.ComponentModel.BackgroundWorker to do initialization stuff without freezing the UI. The test is complex because after creating and showing the form, it must wait somehow to release the UI thread for a while to let the BackgroundWorker achieve the RunWorkerCompleted on the UI thread.

I know that this is something we’ve done in the past and I know this is tricky enough to not reinvent the wheel. But with a test suite of over 13.000 tests this is quite challenging to find where we did that. So I decided to use NDepend querying facility to search.

First I analyze all NDepend assemblies, test assemblies included. Then I generate a code query to match all classes that derive from Form. This can be done from the NDepend Search panel : search Form by name in third-party types and then use a right-click menu to generate the code query:

The CQLinq code query generated is:

from t in Types 
let depth0 = t.DepthOfDeriveFrom("System.Windows.Forms.Form")
where depth0  >= 0 orderby depth0
select new { t, depth0 }

from t in Types

let depth0 = t.DepthOfDeriveFrom("System.Windows.Forms.Form")

where depth0 >= 0 orderby depth0

select new { t, depth0 }

60 classes are matched:

Let’s refine this query to match all methods that create any of those form classes.This could be achieved by iterating over (all methods) x (all form classes), but the NDepend.API extension method ThatCreateAny() acts like a join and operates in a linear time. For our search scenario, waiting a few seconds to get a search result is not a problem. But for a code rule written with CQLinq, this is important to run it as fast as possible in a few milliseconds, to run all queries and rules often in Visual Studio within a few seconds, hence the query performance entry on the documentation.

let formTypes = 
  (from t in Types 
   let depth0 = t.DepthOfDeriveFrom("System.Windows.Forms.Form")
   where depth0  >= 0
   select t)

from m in Application.Methods.ThatCreateAny(formTypes)
select m

let formTypes =

(from t in Types

let depth0 = t.DepthOfDeriveFrom("System.Windows.Forms.Form")

where depth0 >= 0

select t)

from m in Application.Methods.ThatCreateAny(formTypes)

select m

280 methods are instantiating some form classes. Let’s refine the query to match only tests method. The cleanest way would be to check for the usage of TestAttribute, but here just checking for parent assemblies names that contain “Test” is enough:

let formTypes = 
  (from t in Types 
   let depth0 = t.DepthOfDeriveFrom("System.Windows.Forms.Form")
   where depth0  >= 0
   select t)
from m in Application.Methods.ThatCreateAny(formTypes)
where m.ParentAssembly.Name.Contains("Test")
select m

let formTypes =

(from t in Types

let depth0 = t.DepthOfDeriveFrom("System.Windows.Forms.Form")

where depth0 >= 0

select t)

from m in Application.Methods.ThatCreateAny(formTypes)

where m.ParentAssembly.Name.Contains("Test")

select m

Still 122 test methods matched.

Before filtering the result even more, let’s refine the query to display for each test the form class(es) it instantiates. This can be achieved with a LINQ range variable formsCreated that we use in the result:

let formTypes = 
  (from t in Types 
   let depth0 = t.DepthOfDeriveFrom("System.Windows.Forms.Form")
   where depth0  >= 0
   select t)

from m in Application.Methods.ThatCreateAny(formTypes)
where m.ParentAssembly.Name.Contains("Test")
let formsCreated = formTypes.Where(t =>m.CreateA(t))
select new { m, formsCreated }

let formTypes =

(from t in Types

let depth0 = t.DepthOfDeriveFrom("System.Windows.Forms.Form")

where depth0 >= 0

select t)

from m in Application.Methods.ThatCreateAny(formTypes)

where m.ParentAssembly.Name.Contains("Test")

let formsCreated = formTypes.Where(t =>m.CreateA(t))

select new { m, formsCreated }

We can now browse which form(s) are instantiated by each test:

Finally let’s browse only tests that use some asynchronous related code. Many ways can be used to check for asynchronous usages. The easiest way is certainly to look at methods called by a test method, and check which ones have named related to async stuff. I tried a few words like “Async” “Sync” “Thread” “TimeOut” “Wait”… and “Wait” worked:

let formTypes = 
  (from t in Types 
   let depth0 = t.DepthOfDeriveFrom("System.Windows.Forms.Form")
   where depth0  >= 0
   select t)
from m in Application.Methods.ThatCreateAny(formTypes)
where m.ParentAssembly.Name.Contains("Test")
let formsCreated = formTypes.Where(t =>m.CreateA(t))
where m.MethodsCalled.Any(m1 => m1.SimpleName.Contains("Wait"))
select new { m, formsCreated }

let formTypes =

(from t in Types

let depth0 = t.DepthOfDeriveFrom("System.Windows.Forms.Form")

where depth0 >= 0

select t)

from m in Application.Methods.ThatCreateAny(formTypes)

where m.ParentAssembly.Name.Contains("Test")

let formsCreated = formTypes.Where(t =>m.CreateA(t))

where m.MethodsCalled.Any(m1 => m1.SimpleName.Contains("Wait"))

select new { m, formsCreated }

In the source code of the highlighted test I had everything I needed for my scenario, including a link to a tricky stackoverflow answer that we found years ago. I found what I needed within a few minutes and had a bit of fun. I hope the methodology and the resulting query can be adapted to your advanced search scenarios.

NDepend and .NET Fx v4.7.2: an extension method collision and how to solve it easily

In Oct 2017 I wrote about the potential collision problem with extension methods. At that time the .NET Framework 4.7.1 was just released with this new extension method that is colliding with our own NDepend.API Append() extension method with same signature.

System.Linq.Enumerable.Append<TSource>(this System.Collections.Generic.IEnumerable<TSource>, TSource)

1	System.Linq.Enumerable.Append<TSource>(this System.Collections.Generic.IEnumerable<TSource>, TSource)

The problem was solved easily because just one default rule consumed our Append() extension method, we just had to refactor this method to use it as a static method call instead of an extension method call: ExtensionMethodsEnumerable.Append(...)

Unfortunately with the recent release of .NET Framework 4.7.2, the same problem just happened again, this time with this extension method:

System.Linq.Enumerable.ToHashSet<TSource>(this System.Collections.Generic.IEnumerable<TSource>)

1	System.Linq.Enumerable.ToHashSet<TSource>(this System.Collections.Generic.IEnumerable<TSource>)

This time 22 default code rules are relying on our ToHashSet() extension method. This method is used widely because it is often the cornerstone to improve significantly performances. But this means that after installing the .NET Fx v4.7.2, 22 default rules will break.

This time the problem is not solved easily by calling our ExtensionMethodsSet.ToHashSet<TSource>(this IEnumerable<TSource>) extension method as a static method because in most of these 22 rules source code, changing the extension method call into a static method call require a few brain cycle. Moreover it makes the rules source code less readable: For example the first needs to be transformed into the second:

let disposeMethods = disposableTypes.ChildMethods().WithName("Dispose()").ToHashSet()
let disposeMethods = ExtensionMethodsSet.ToHashSet(disposableTypes.ChildMethods().WithName("Dispose()"))

1 2	let disposeMethods = disposableTypes.ChildMethods().WithName("Dispose()").ToHashSet() let disposeMethods = ExtensionMethodsSet.ToHashSet(disposableTypes.ChildMethods().WithName("Dispose()"))

We wanted a straightforward and clean way for NDepend users to solve this issue on all their default-or-custom code rules. The solution is the new extension method ToHashSetEx().

Solving the issue on an existing NDepend deployment is now as simple as replacing .ToHashSet() with .ToHashSetEx() in all textual files that contain the user code rules and code queries (the files with extension .ndproj and .ndrules).

We just released NDepend v2018.1.1 with this new extension method ExtensionMethodsSet.ToHashSetEx<TSource>(this IEnumerable<TSource>). Of course all default rules and generated queries now rely on ToHashSetEx() and also a smart error message is now shown to the user in such situation:

We hesitated between ToHashSetEx() and ToHashSet2() but we are confident that this problem won’t scale (more explanation on suffixing a class or method name with Ex here).

Actually we could have detected this particular problem earlier in October 2017 because Microsoft claimed that the .NET Fx will ultimately support .NET Standard 2.0 and .NET Standard 2.0 already presented this ToHashSet() extension method. So this time we analyzed both C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\netstandard.dll and NDepend.API.dll to double-check with this code query that there is no more risk of extension method collision:

// <Name>List extension methods with same name declared in different assemblies</Name>
let lookup = Application.Methods.Where(m => m.IsExtensionMethod).ToLookup(m => m.SimpleName)
from l in lookup
where l.ParentAssemblies().Count() > 1
select new { method = l.First(), overloads =l.ToArray() }

// <Name>List extension methods with same name declared in different assemblies</Name>

let lookup = Application.Methods.Where(m => m.IsExtensionMethod).ToLookup(m => m.SimpleName)

from l in lookup

where l.ParentAssemblies().Count() > 1

select new { method = l.First(), overloads =l.ToArray() }

We find back both Append() and ToHashSet() collisions and since NDepend.API is not concerned with queryable, there is no more risk of collision:

Quickly assess your .NET code compliance with .NET Standard

Yesterday evening I had an interesting discussion about the feasibility of migrating parts of the NDepend code to .NET Standard to ultimately run it on .NET Core. We’re not yet there but this might make sense to run at least the code analysis on non Windows platform, especially for NDepend clones CppDepend (for C++), JArchitect (for Java) and others to come.

Then I went to sleep (as every developers know the brain is coding hard while sleeping), then this morning I went for an early morning jogging and it stroke me: NDepend is the perfect tool to assess some .NET code compliance to .NET Standard, or to any other libraries actually! As soon on my machine I did a proof of concept in less than an hour.

The key is that .NET standard 2.0 types and members are all packet in a single assemblies netstandard.dll v2.0 that can be found under C:\Program Files\dotnet\sdk\NuGetFallbackFolder\netstandard.library\2.0.3\build\netstandard2.0\ref\netstandard.dll (on my machine). A quick analyze of netstandard.dll with NDepend shows 2 317 types in 78 namespaces, with 24 303 methods and 884 fields. Let’s precise that netstandard.dll doesn’t contain any code, it is a standard not an implementation. The 68K IL instructions represent the IL code for throw null which is the method body for all non-abstract methods.

(Btw, I am sure that if you read this you have an understanding of what is .NET Standard but if anything is still unclear, I invite you to read this great article by my friend Laurent Bugnion wrote 3 days ago A Brief History of .NET Standard)

Given that, what stroke me this morning is that to analyze some .NET code compliance to .NET Standard, I’d just have to include netstandard.dll in the list of my application assemblies and write a code query that filters the dependencies the way I want. Of course to proof test this idea I wanted to explore the NDepend code base compliance to .NET Standard:

NetStandard assembly included in the NDepend assemblies to analyze

The code query was pretty straightforward to write. It is written in a way that:

it is easy to use to analyze compliance with any other library than .NET standard,
it is easy to explore the compliance and the non-compliance with a library in a comprehensive way, thanks to the NDepend code query result browsing facilities,
it is easy to refactor the query for querying more, for example below I refactor it to assess the usage of third-party non .NET Standard compliant code

// <Name>Non-compliance with netstandard</Name>

// asm is a sequence of application assemblies that contains elements to use
// here asm contains only the netstandard assembly
let asm =Application.Assemblies.WithNameIn("netstandard"/*, "anyotherlib1", "anyotherlib2"*/)

// hashset contains all full names of netstandard types/methods/fields 
let hashset = asm.ChildTypesAndMembers().Select(x => x.FullName).ToHashSetEx()

// iterate over all types/methods/fields of the application
from c in Application.Assemblies.Except(asm).ChildTypesAndMembers()

let nonNetStandardElemsUsed = 
   c.IsType   ? c.AsType.TypesUsed.Where    (t => t.IsThirdParty && !hashset.Contains(t.FullName)).ToArray() :
   c.IsMethod ? c.AsMethod.MembersUsed.Where(m => m.IsThirdParty && !hashset.Contains(m.FullName)).ToArray() :
   new IMember[0]  // Here c.IsField and a field is not using anything!

let netStandardElemsUsed = 
   c.IsType   ? c.AsType.TypesUsed.Where    (t => t.IsThirdParty && hashset.Contains(t.FullName)).ToArray() :
   c.IsMethod ? c.AsMethod.MembersUsed.Where(m => m.IsThirdParty && hashset.Contains(m.FullName)).ToArray() :
   new IMember[0] 

// Just comment or change this line to explore the compliance and/or non-compliance with netstandard
where nonNetStandardElemsUsed.Any()

select new { c, nonNetStandardElemsUsed, netStandardElemsUsed, loc = c.GetNbLinesOfCode_GuaranteedIfPDBFound() }

// <Name>Non-compliance with netstandard</Name>

// asm is a sequence of application assemblies that contains elements to use

// here asm contains only the netstandard assembly

let asm =Application.Assemblies.WithNameIn("netstandard"/*, "anyotherlib1", "anyotherlib2"*/)

// hashset contains all full names of netstandard types/methods/fields

let hashset = asm.ChildTypesAndMembers().Select(x => x.FullName).ToHashSetEx()

// iterate over all types/methods/fields of the application

from c in Application.Assemblies.Except(asm).ChildTypesAndMembers()

let nonNetStandardElemsUsed =

c.IsType ? c.AsType.TypesUsed.Where (t => t.IsThirdParty && !hashset.Contains(t.FullName)).ToArray() :

c.IsMethod ? c.AsMethod.MembersUsed.Where(m => m.IsThirdParty && !hashset.Contains(m.FullName)).ToArray() :

new IMember[0] // Here c.IsField and a field is not using anything!

let netStandardElemsUsed =

c.IsType ? c.AsType.TypesUsed.Where (t => t.IsThirdParty && hashset.Contains(t.FullName)).ToArray() :

c.IsMethod ? c.AsMethod.MembersUsed.Where(m => m.IsThirdParty && hashset.Contains(m.FullName)).ToArray() :

new IMember[0]

// Just comment or change this line to explore the compliance and/or non-compliance with netstandard

where nonNetStandardElemsUsed.Any()

select new { c, nonNetStandardElemsUsed, netStandardElemsUsed, loc = c.GetNbLinesOfCode_GuaranteedIfPDBFound() }

The result looks like that and IMHO it is pretty interesting. For example we can see at a glance that NDepend.API is almost full compliant with .NET standard except for the usage of System.Drawing.Image (all the 1 type are the Image type actually) and for the usage of code contracts.

NDepend code base compliance with .NET standard

For a more intuitive assessment of the compliance to .NET Standard we can use the metric view, that highlights the code elements matched by the currently edited code query.

Unsurprisingly NDepend.UI is not compliant at all,
portions of NDepend.Core non compliant to .NET Standard are well defined (and I know it is mostly because of some UI code here too, that we consider Core because it is re-usable in a variety of situations).

With this information it’d be much easier to plan a major refactoring to segregate .NET standard compliant code from the non-compliant one, especially to anticipate hot spots that will be painful to refactor.

The code query to assess compliancy can be refactored at whim. For example I found it interesting to see which non-compliant third-party code elements were the most used. So I refactored the query this way:

// ***** CODE COPY/PASTED FROM THE PREVIOUS QUERY ***********
// asm is a sequence of application assemblies that contains elements to use
// here asm contains only the netstandard assembly
let asm =Application.Assemblies.WithNameIn("netstandard"/*, "anyotherlib1", "anyotherlib2"*/)

// hashset contains all full names of netstandard types/methods/fields 
let hashset = asm.ChildTypesAndMembers().Select(x => x.FullName).ToHashSetEx()
// ***********************************************************
 
from c in ThirdParty.TypesAndMembers
where !hashset.Contains(c.FullName) // We want third-party non compliant code elements
let users = 
    c.IsType ?   c.AsType.TypesUsingMe.Cast<IMember>() :
    c.IsMethod ? c.AsMethod.MethodsCallingMe :
                 c.AsField.MethodsUsingMe
orderby users.Count() descending
select new { c, users }

// ***** CODE COPY/PASTED FROM THE PREVIOUS QUERY ***********

// asm is a sequence of application assemblies that contains elements to use

// here asm contains only the netstandard assembly

let asm =Application.Assemblies.WithNameIn("netstandard"/*, "anyotherlib1", "anyotherlib2"*/)

// hashset contains all full names of netstandard types/methods/fields

let hashset = asm.ChildTypesAndMembers().Select(x => x.FullName).ToHashSetEx()

// ***********************************************************

from c in ThirdParty.TypesAndMembers

where !hashset.Contains(c.FullName) // We want third-party non compliant code elements

let users =

c.IsType ? c.AsType.TypesUsingMe.Cast<IMember>() :

c.IsMethod ? c.AsMethod.MethodsCallingMe :

c.AsField.MethodsUsingMe

orderby users.Count() descending

select new { c, users }

Without surprise UI code that is non .NET Standard compliant popups first:

.NET Standard non-compliant third-party code usage

There is no limit to refactor this query to your own need, like assessing usage of non-compliant code — except UI code– for example, or assessing the usage of code non compliant to ASP.NET Core 2 (by changing the library).

Hope you’ll find this content useful to plan your migration to .NET Core and .NET Standard!

Checking DDD Ubiquitous Language with NDepend

Since NDepend version 2018.1, the tool proposes a default rule to check Domain Driven Design (DDD) Ubiquitous Language validity.

DDD Ubiquitous Language

Let’s quote Martin Fowler on Ubiquitous Language:

Ubiquitous Language is the term Eric Evans uses in Domain Driven Design for the practice of building up a common, rigorous language between developers and users. This language should be based on the Domain Model used in the software – hence the need for it to be rigorous, since software doesn’t cope well with ambiguity.

Evans makes clear that using the ubiquitous language between in conversations with domain experts is an important part of testing it, and hence the domain model. He also stresses that the language (and model) should evolve as the team’s understanding of the domain grows.

–Martin Fowler

Eric Evans coined the term DDD, let’s quote him:

By using the model-based language pervasively and not being satisfied until it flows, we approach a model that is complete and comprehensible, made up of simple elements that combine to express complex ideas.

Domain experts should object to terms or structures that are awkward or inadequate to convey domain understanding; developers should watch for ambiguity or inconsistency that will trip up design.

–Eric Evans

See below a sample of ubiquitous language usage in the real-world. We end up with clean and readable code:

The TrainTrain Code Base

To explain and demonstrate the rule, we’ll conduct our experiment on the TrainTrain code base.

This OSS code base has been developed by Bruno Boucard and Thomas Pierrain from 42Skillz, a French consultancy company specialized in DDD and developers coaching. TrainTrain has been developed in order to illustrate concretely most of DDD concepts (including Ubiquitous Language) in a session named How To Distill The Core Domain From Your Legacy App (Live Coding). In this session, a legacy version of the code is live-refactored to a DDD-compliant version. It has been performed both at Explore DDD 2017 (Denver, Sept 2017) and DDD Europe 2018 (Amsterdam, Jan 2018).

We worked with Bruno and Thomas to develop this first rule related to DDD and we expect that more rules will follow from this collaboration.

The Rule

See below the full source code of the new rule named DDD ubiquitous language check that can be found in the rule group Naming Convention. This rule is disabled by default because before using it, the user must customize both:

The core domain namespace name (by default set to “TrainTrain.Domain”)
The vocabulary list

The idea is to centralize in this rule source code the vocabulary. The rule then checks that all code elements defined in the core domain namespace are named with one or several terms found in the vocabulary list. Code elements checked include classes, enumerations, structures, interfaces, methods, properties and fields. If a term needs to be used both with singular and plural forms, both forms need to be mentioned, like Seat and Seats for example.

// <Name>DDD ubiquitous language check</Name>
warnif count > 0
// Update to your core domain namespace(s)
let coreDomainNamespaces = Application.Namespaces.WithNameLike("TrainTrain.Domain")
// Update your vocabulary list
let vocabulary = new [] {
"Train", "Coach", "Coaches", "Seat", "Seats",
"Reservation", "Fulfilled", "Booking", "Book", "Reserve", "Confirm"
}.ToHashSet()
 

let technicalWords = new [] { "get", "set", "Get", "Set", "Add" }.ToHashSet()
let multiWordsVocabulary = vocabulary.Where(w => w.GetWords().Length >= 2)
 
// Append multi-words words in vocabulary
let multiWordsWords = multiWordsVocabulary.SelectMany(w => w.GetWords())
let vocabulary2 = vocabulary.Concat(multiWordsWords).ToHashSet()
let vocabulary3 = vocabulary2.Concat(technicalWords).ToHashSet()
 
from ce in coreDomainNamespaces.ChildTypesAndMembers()
let tokens = ce.SimpleName.GetWords().Select(w => w.FirstCharToUpper()).ToArray()
 
where !(ce.IsMethod && ce.AsMethod.IsConstructor) && // No vocabulary in ctor
      !(ce.IsField && ce.AsField.IsGeneratedByCompiler) &&  // Remove compiler generated backing fields, their vocabulary is in property
      !(vocabulary3.Any(vocable => tokens.Contains(vocable)))
 
let wordsNotInVocabulary = tokens.Where(w => !(vocabulary2.Contains(w) && string.IsNullOrEmpty(w))).ToArray()
 
select new { ce,
  wordsNotInVocabulary = string.Join(", ",wordsNotInVocabulary)
}

//<Description>
// The language used in identifiers of classes, methods and fields of the **core domain**, 
// should be based on the **Domain Model**.
// This constraint is known as **ubiquitous language** in **Domain Driven Design (DDD)**
// and it reflects the need to be rigorous with naming, 
// since software doesn't cope well with ambiguity.
//
// This rule is disabled per default 
// because its source code needs to be customized to work, 
// both with the **core domain** namespace name 
// (that contains classes and types to be checked),
// and with the list of domain language terms.
//
// If a term needs to be used both with singular and plural forms, 
// both forms need to be mentioned,
// like **Seat** and **Seats** for example. Notice that this default rule is related with
// the other default rule 
// *Properties and fields that represent a collection of items should be named Items* 
// defined in the *Naming Convention* group.
//
// This rule implementation relies on the NDepend API 
// **ExtensionMethodsString.GetWords(this string identifier)** 
// extension method that extracts terms 
// from classes, methods and fields identifiers in a smart way.
//</Description>

//<HowToFix>
// For each violation, this rule provides the list of **words not in vocabulary**.
//
// To fix a violation of this rule, either rename the concerned code element
// or update the domain language terms list defined in this rule source code,
// with the missing term(s).
//</HowToFix>

// <Name>DDD ubiquitous language check</Name>

warnif count > 0

// Update to your core domain namespace(s)

let coreDomainNamespaces = Application.Namespaces.WithNameLike("TrainTrain.Domain")

// Update your vocabulary list

let vocabulary = new [] {

"Train", "Coach", "Coaches", "Seat", "Seats",

"Reservation", "Fulfilled", "Booking", "Book", "Reserve", "Confirm"

}.ToHashSet()

let technicalWords = new [] { "get", "set", "Get", "Set", "Add" }.ToHashSet()

let multiWordsVocabulary = vocabulary.Where(w => w.GetWords().Length >= 2)

// Append multi-words words in vocabulary

let multiWordsWords = multiWordsVocabulary.SelectMany(w => w.GetWords())

let vocabulary2 = vocabulary.Concat(multiWordsWords).ToHashSet()

let vocabulary3 = vocabulary2.Concat(technicalWords).ToHashSet()

from ce in coreDomainNamespaces.ChildTypesAndMembers()

let tokens = ce.SimpleName.GetWords().Select(w => w.FirstCharToUpper()).ToArray()

where !(ce.IsMethod && ce.AsMethod.IsConstructor) && // No vocabulary in ctor

!(ce.IsField && ce.AsField.IsGeneratedByCompiler) && // Remove compiler generated backing fields, their vocabulary is in property

!(vocabulary3.Any(vocable => tokens.Contains(vocable)))

let wordsNotInVocabulary = tokens.Where(w => !(vocabulary2.Contains(w) && string.IsNullOrEmpty(w))).ToArray()

select new { ce,

wordsNotInVocabulary = string.Join(", ",wordsNotInVocabulary)

}

//<Description>

// The language used in identifiers of classes, methods and fields of the **core domain**,

// should be based on the **Domain Model**.

// This constraint is known as **ubiquitous language** in **Domain Driven Design (DDD)**

// and it reflects the need to be rigorous with naming,

// since software doesn't cope well with ambiguity.

// This rule is disabled per default

// because its source code needs to be customized to work,

// both with the **core domain** namespace name

// (that contains classes and types to be checked),

// and with the list of domain language terms.

// If a term needs to be used both with singular and plural forms,

// both forms need to be mentioned,

// like **Seat** and **Seats** for example. Notice that this default rule is related with

// the other default rule

// *Properties and fields that represent a collection of items should be named Items*

// defined in the *Naming Convention* group.

// This rule implementation relies on the NDepend API

// **ExtensionMethodsString.GetWords(this string identifier)**

// extension method that extracts terms

// from classes, methods and fields identifiers in a smart way.

//</Description>

//<HowToFix>

// For each violation, this rule provides the list of **words not in vocabulary**.

// To fix a violation of this rule, either rename the concerned code element

// or update the domain language terms list defined in this rule source code,

// with the missing term(s).

//</HowToFix>

The NDepend rule system makes easy to modify the source code of an existing rule. There is no Visual Studio project to create and store, no NuGet package to reference, no assembly to compile, version and maintain, no integration. Just textual edition with code completion, API documentation and live result while editing, and then Ctrl+S, that’s it. As a consequence, the NDepend rule system is well suited to implement such rule that must be customized with some user data before usage.

Notice that this rule relies on the new NDepend API method ExtensionMethodsString.GetWord(this string identifier). This method extracts words from code identifiers. For example from the field identifier _seatsRequestedCount it extracts the 3 words seats, Requested, Count. To be compliant with the vocabulary list, we then set the first char to upper, for example seats becomes Seats.

Running the Rule

See below a screenshot on running this rule on a TrainTrain version. An issue is spotted on a core domain class named TreasholdCapacity. Both words are reported in the column wordsNotInVocabulary because both words are not in the vocabulary list. Moreover the word Treashold has a typo. At this point, to fix this issue:

either this class should be renamed with existing core domain vocabulary words
either these words should be added to the vocabulary list (with the typo fix)

DDD is nowadays a popular concept. We are proud to innovate with a static analysis code rule related to DDD. We have plans for more DDD related rules and we would like to hear both your feedback on using this rule, and your needs for more DDD related rules.

New .NET Core 2.1 and ASP.NET Core 2.1 APIs

.NET Core 2.1 and ASP.NET Core 2.1 Preview1 have just been released (see here the official announcement) and we are going to explore new APIs in this post. We’ll found out many of the new features announced in the .NET Core 2.1 Roadmap and ASP.NET Core 2.1 Roadmap on the MSDN blog.

We just released NDepend v2018.1 and we took a chance to support analysis of .NET Core 2.1 and ASP.NET Core 2.1 applications. NDepend is often deemed as the Swiss-Army Knife for .NET developers thanks to its code query language (CQLinq). CQLinq can be used to write code rules, quality gates, trend code metrics, explore dependencies or advanced code search. One thing CQLinq excels at is exploring the diff between two snapshots of a code base. Exploring new APIs is a sub-task of exploring what was changed. Let’s harness this capability to explore new .NET Core 2.1 APIs.

New .NET Core 2.1 Preview1 APIs

We could have downloaded sources files of both .NET Core 2.1.0 Preview1 and 2.0.0, recompile and then do the diff. Instead, since NDepend can analyze raw assemblies even without sources available, we compared assemblies in these two folders:

C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.1.0-preview1-26216-03
C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.5

Here is the CQLinq code query that lists all new public classes and types. It is also refined to match public members (methods and fields) of each new type in the result.

// <Name>New .NET Core 2.1 API Types</Name>
from t in Application.Types 
where t.IsPubliclyVisible // we want only public API
   && t.WasAdded() // added since baseline (which is .NET Core 2.0.5)
select new {
      t,
      publicMembers = t.Members.Where(m => m.IsPubliclyVisible),
      t.NbILInstructions
}

// <Name>New .NET Core 2.1 API Types</Name>

from t in Application.Types

where t.IsPubliclyVisible // we want only public API

&& t.WasAdded() // added since baseline (which is .NET Core 2.0.5)

select new {

publicMembers = t.Members.Where(m => m.IsPubliclyVisible),

t.NbILInstructions

}

Find the whole list here .NET Core 2.1 new public classes. Here is a first glimpse in the screenshot below. We highlighted the new great Span<T> capability.

Not only new public classes list is interesting, but also new public methods added on existing public classes. This query does list these 1.500 methods:

// <Name>New .NET Core 2.1 public methods in existing types</Name>
from m in Application.Methods
where m.IsPubliclyVisible // we want only public API
   && m.WasAdded() // added since baseline (which is .NET Core 2.0.5)
   && !m.ParentType.WasAdded() // in existing type
select new {
       m,
       m.NbILInstructions
}

// <Name>New .NET Core 2.1 public methods in existing types</Name>

from m in Application.Methods

where m.IsPubliclyVisible // we want only public API

&& m.WasAdded() // added since baseline (which is .NET Core 2.0.5)

&& !m.ParentType.WasAdded() // in existing type

select new {

m.NbILInstructions

}

Here also find a screenshot below and the whole list here: .NET Core 2.1 new public methods on existing public classes. For this screenshot we used the new Dark theme support of NDepend v2018.1.

Interestingly enough let’s list new namespaces that contain at least one public type:

// <Name>New .NET Core 2.1 API Namespaces</Name>
from n in Application.Namespaces
where n.IsPublic    // We want namespaces that contain at least one public type
   && n.WasAdded()  // added since baseline (which is .NET Core 2.0.5)
select new { 
   n,
   publicTypes = n.ChildTypes.Where(t => t.IsPublic), 
   n.NbILInstructions
}

// <Name>New .NET Core 2.1 API Namespaces</Name>

from n in Application.Namespaces

where n.IsPublic // We want namespaces that contain at least one public type

&& n.WasAdded() // added since baseline (which is .NET Core 2.0.5)

select new {

publicTypes = n.ChildTypes.Where(t => t.IsPublic),

n.NbILInstructions

}

New ASP.NET Core 2.1 Preview1 APIs

To analyze ASP.NET Core assemblies it was a bit more difficult than just comparing assemblies in 2 folders. ASP.NET Core assemblies are stored in NuGet packages so we did explore assemblies in the folder C:\Program Files\dotnet\sdk\NuGetFallbackFolder and then tinker a bit to get the wanted versions in both 2.1 and 2.0 cases.

Let’s use the same code query to match ASP.NET Core 2.1 new public classes :

The same way here is the ASP.NET Core 2.1 new public methods on existing public classes :

ASP.NET Core 2.1 new public methods in existing public classes

And finally, here are the new ASP.NET Core 2.1 namespaces that contain at least one public classes.

A problem with extension methods

We like extension methods. When named accordingly they can both make the caller code clearer, and isolate static methods from classes on which they operate.

But when using extension methods, breaking change can happen, and this risk is very concrete, it actually just happened to us.

Since 2012, NDepend.API proposes a generic Append() extension:

namespace NDepend.Helpers {
   ///<summary>
   ///Provides a set of extension methods dedicated to enumerables. 
   ///</summary>
   public static class ExtensionMethodsEnumerable {
      ///<summary>
      ///Append <paramref name="element"/> at the end of <paramref name="seq"/>.
      ///</summary>
      ///<typeparam name="T">The element type.</typeparam>
      ///<param name="seq">A sequence of elements.</param>
      ///<param name="element">The element to append.</param>
      ///<remarks>This extension method has a <i>constant</i> time complexity.</remarks>
      public static IEnumerable<T> Append<T>(this IEnumerable<T> seq, T element) {
         ...

namespace NDepend.Helpers {

///<summary>

///Provides a set of extension methods dedicated to enumerables.

///</summary>

public static class ExtensionMethodsEnumerable {

///<summary>

///Append <paramref name="element"/> at the end of <paramref name="seq"/>.

///</summary>

///<typeparam name="T">The element type.</typeparam>

///<param name="seq">A sequence of elements.</param>

///<param name="element">The element to append.</param>

///<remarks>This extension method has a <i>constant</i> time complexity.</remarks>

public static IEnumerable<T> Append<T>(this IEnumerable<T> seq, T element) {

...

Two default rules use this extension method: Avoid namespaces dependency cycles and Avoid types initialization cycles

Last month, on Oct 17th 2017, Microsoft released .NET Framework v4.7.1 that implements .NET Standard 2.0. Around 200 .NET Standard 2.0 were missing in .NET Framewok v4.6.1, and one of those missing API is:

System.Linq.Enumerable.Append<TSource>(this System.Collections.Generic.IEnumerable<TSource>, TSource)

1	System.Linq.Enumerable.Append<TSource>(this System.Collections.Generic.IEnumerable<TSource>, TSource)

Within NDepend, rules, quality gates, trend metrics … basically everything, is a C# LINQ query stored as textual and compiled and executed on-the-fly. Since the compilation environment uses both namespaces NDepend.Helpers and System.Linq, when running NDepend on top of the .NET Framework v4.7.1, both Append() extension methods are visible. As a consequence, for each query calling the Append() method, the compiler fails with:

error CS0121: The call is ambiguous between the following methods or properties: 
'NDepend.Helpers.ExtensionMethodsEnumerable.Append<NDepend.CodeModel.IType>(System.Collections.Generic.IEnumerable<NDepend.CodeModel.IType>, NDepend.CodeModel.IType)' 
and 
'System.Linq.Enumerable.Append<NDepend.CodeModel.IType>(System.Collections.Generic.IEnumerable<NDepend.CodeModel.IType>, NDepend.CodeModel.IType)'

error CS0121: The call is ambiguous between the following methods or properties:

'NDepend.Helpers.ExtensionMethodsEnumerable.Append<NDepend.CodeModel.IType>(System.Collections.Generic.IEnumerable<NDepend.CodeModel.IType>, NDepend.CodeModel.IType)'

and

'System.Linq.Enumerable.Append<NDepend.CodeModel.IType>(System.Collections.Generic.IEnumerable<NDepend.CodeModel.IType>, NDepend.CodeModel.IType)'

Hopefully a user notified us with this problem that we didn’t catch yet and we just released NDepend v2017.3.2 that fixes this problem Only one clean fix is possible to make it compatible with all .NET Framework versions: refactor all calls to the Append() extension method, into a classic static method invocation, with an explanatory comment:

   // v2017.3.2: don't call Append() as an extension method else ambiguous syntax error 
   //            with the new extension method in .NET Fx v4.7.1 / .NET Standard 2.0: System.Linq.Enumerable.Append()
   let cycle = ExtensionMethodsEnumerable.Append(usersAndUsed,suspect)

// v2017.3.2: don't call Append() as an extension method else ambiguous syntax error

// with the new extension method in .NET Fx v4.7.1 / .NET Standard 2.0: System.Linq.Enumerable.Append()

let cycle = ExtensionMethodsEnumerable.Append(usersAndUsed,suspect)

We expect support on this within the next weeks and months when more and more users will run the .NET Fx v4.7.1 while not changing their rules-set. There is no lesson learnt, this situation can happen and it happens rarely, this shouldn’t prevent you from declaring and calling extension methods. The more mature the frameworks you are relying on, the less likely it’ll happen.

Static analysis of .NET Core 2.0 applications

NDepend v2017.3 has just been released with major improvements. One of the most requested features, now available, is the support for analyzing .NET Core 2.0 and .NET Standard 2.0 projects. .NET Core and its main flavor, ASP.NET Core, represents a major evolution for the .NET platform. Let’s have a look at how NDepend is analyzing .NET Core code.

Resolving .NET Core third party assemblies

In this post I’ll analyze the OSS application ASP.NET Core / EntityFramework MusicStore hosted on github. From the Visual Studio solution file, NDepend is resolving the application assembly MusicStore.dll and also two test assemblies that we won’t analyze here. In the screenshot below, we can see that:

NDepend recognizes the .NET profile, .NET Core 2.0, for this application.
It resolves several folders on the machine that are related to .NET Core, especially NuGet package folders.
It resolves all 77 third-party assemblies referenced by MusicStore.dll. This is important since many code rules and other NDepend features take into account what the application code is using.

It is worth noticing that the .NET Core platform assemblies have high granularity. A simple website like MusicStore references no fewer than 77 assemblies. This is because the .NET Core framework is implemented through a few NuGet packages that each contain many assemblies. The idea is to release the application only with needed assemblies, in order to reduce the memory footprint.

NDepend v2017.3 has a new heuristic to resolve .NET Core assemblies. This heuristic is based on .deps.json files that contain the names of the NuGet packages referenced. Here we can see that 3 NuGet packages are referenced by MusicStore. From these package names, the heuristic will resolve third-party assemblies (in the NuGet store) referenced by the application assemblies (MusicStore.dll in our case).

Analyzing .NET Standard assemblies

Let’s be clear that NDepend v2017.3 can also analyze .NET Standard assemblies. Interestingly enough, since .NET Standard 2.0, .NET Standard assemblies reference a unique assembly named netstandard.dll and found in C:\Users\[user]\.nuget\packages\NETStandard.Library\2.0.0\build\netstandard2.0\ref\netstandard.dll.

By decompiling this assembly, we can see that it doesn’t contain any implementation, but it does contain all types that are part of .NET Standard 2.0. This makes sense if we remember that .NET Standard is not an implementation, but is a set of APIs implemented by various .NET profiles, including .NET Core 2.0, the .NET Framework v4.6.1, Mono 5.4 and more.

Browsing how the application is using .NET Core

Let’s come back to the MusicStore application that references 77 assemblies. This assembly granularity makes it impractical to browse dependencies with the dependency graph, since this generates dozens of items. We can see that NDepend suggests viewing this graph as a dependency matrix instead.

The NDepend dependency matrix can scale seamlessly on a large number of items. The numbers in the cells also provide a good hint about the represented coupling. For example, here we can see that 22 members of the assembly Microsoft.EntityFrameworkCore.dll are used by 32 methods of the assembly MusicStore.dll, and a menu lets us dig into this coupling.

Clicking the menu item Open this dependency shows a new dependency matrix where only members involved are kept (the 32 elements in column are using the 22 elements in rows). This way you can easily dig into which part of the application is using what.

All NDepend features now work when analyzing .NET Core

We saw how to browse the structure of a .NET Core application, but let’s underline that all NDepend features now work when analyzing .NET Core applications. On the Dashboard we can see code quality metrics related to Quality Gates, Code Rules, Issues and Technical Debt.

Also, most of the default code rules have been improved to avoid reporting false positives on .NET Core projects.

We hope you’ll enjoy using all your favorite NDepend features on your .NET Core projects!

Migrating from HTTP to HTTPS in a IIS / ASP.NET environment

Google is urging more and more webmasters to move their sites to HTTPS for security reasons. We did this move last week for our IIS / ASP.NET website https://www.NDepend.com and we learned a few tricks along the way. Once you’ve done it once it becomes pretty straightforward, but getting the big picture and handling every detail well is not trivial. So I hope this post will be useful.

HTTPS and Google Analytics Referrals

One reason for moving to HTTPS is that Google Analytics referrals don’t work when the user comes from a HTTPS website. And since most of your referrers websites are likely to be already HTTPS, if you keep up with HTTP, your GAnalytics becomes blind.

Notice that once you’ve moved to HTTPS, you still won’t be able to track referrers that come from an HTTP url, which is annoying since most of the time you don’t have edit-access to these urls.

Getting the Certificate

You can get free certificates from LetsEncrypt.com, but they have a 3 month lease. The renewal process can certainly be automated, but instead we ordered a 2 year certificate from gandi.net for only 20 EUR for the two years. For that price you’ll get the minimum and won’t obtain a certificate with the Green Address Bar, which costs around 240 EUR / year.

When ordering the certificate, a CSR (Certificate Sign Request) will be requested. The CRS can be obtained from IIS as explained here for example, through the menu Generate Certificate Request. A few questions about who you are will be asked, the most important being the Common Name, which will be typically www.yourdomain.com (or, better, use a wildcard, as in *.yourdomain.com). If the Common Name doesn’t match the web site domain, the user will get a warning at browsing time, so this is a sensitive step.

Installing the Certificate in IIS

Once you’ve ordered the certificate, the certificate shop will provide you with a .crt or .cer crypted content. This is the certificate. But IIS doesn’t deal with the .crt nor .cer formats, it asks for a .pfx file! This is misleading and the number one explanation on the web is this one on the Michael Richardson blog. Basically you’ll use the IIS menu Complete Certificate Request (that follows the first Generate Certificate Request). Now restart IIS or the server to make sure it’ll take care of the certificate.

Binding the Certificate to the website 443 Port in IIS

At that point the certificate is installed on the server. The certificate needs to be bound with your website port 443. First make sure that the port 443 is opened on your server, and second, use the binding IIS menu on your website. A binding entry will have to be added as shown in the picture below.

Once added just restart the website. Normally, you can now access your website through HTTPS urls. If not, you may have to tweak the DNS pointers somehow, but I cannot comment since we didn’t have a problem with that.

At that point, both HTTPS and HTTP are browsable. HTTP requests need to be redirected to HTTPS to complete the migration.

301 redirection with Web.Config and IIS UrlRewriter

HTTP to HTTPS redirection can be achieved by modifying the Web.Config file of your ASP.NET website, to tell the IIS Url rewriter how to redirect. After a few attempts based on googling, our redirection rules look like:

  <system.webServer>
    <rewrite>
      <rules>
        <clear />
        <rule name="Redirect to https" stopProcessing="true">
          <match url=".*" />
          <conditions>
            <add input="{HTTPS}" pattern="off" ignoreCase="true" />
            <add input="{URL}" pattern="(.*)XYZ" negate="true" ignoreCase="true"/>             
            <add input="{HTTP_HOST}" matchType="Pattern" pattern="^localhost(:\d+)?$" negate="true" />
          </conditions>
          <action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Permanent" appendQueryString="false" />
        </rule>
        <rule name="redirect ndepend.com to www.ndepend.com">
          <match url=".*"/>
          <conditions logicalGrouping="MatchAll">
            <add input="{HTTP_HOST}" pattern="^www.*" negate="true"/>
            <add input="{HTTP_HOST}" pattern="localhost" negate="true"/>
          </conditions>
          <action type="Redirect" url="http://www.ndepend.com/{R:0}"/>
        </rule>
      </rules>
    </rewrite>
  </system.webServer>

<system.webServer>

<rules>

</conditions>

</rule>

</conditions>

</rule>

</rules>

</rewrite>

</system.webServer>

If you believe this can be improved, please let me know. At least it works 🙂

<add input=”{HTTPS}” pattern=”off” ignoreCase=”true” /> is the main redirection rule that redirects HTTP requests to HTTPS (this is called 301 redirection). You’ll find many sites on the web to test that your 301 redirection works fine.
Make sure to double check that urls with GET params are redirected well. On our side, url=“https://{HTTP_HOST}{REQUEST_URI}” processes GET params seamlessly
<add input=”{URL}” pattern=”(.*)XYZ” negate=”true” ignoreCase=”true”/> is important to avoid HTTP to HTTPS redirection for a page named XYZ. Typically, if you have special pages with POST requests, they might be broken with the HTTPS redirection, and thus the redirection needs to be discarded for those.
<add input=”{HTTP_HOST}” matchType=”Pattern” pattern=”^localhost(:\d+)?$” negate=”true” /> avoid the HTTPS redirection when testing on localhost.
<add input=”{HTTP_HOST}” pattern=”^www.*” negate=”true”/> just transforms ndepend.com requests into www.ndepend.com,
and <add input=”{HTTP_HOST}” pattern=”localhost” negate=”true”/> avoids this WWW redirection on localhost.

Eliminate Mixed Content

At this point you are almost done. Yet depending on the topology of your web site(s) and resources, it is possible that some pages generate a mixed content warning. Mixed content means that some resources (like images or scripts) of an HTTPS web page are served through HTTP. When mixed content is detected, most browsers show a warning to users about a not fully secured page.

You’ll find tools to search for mixed content on your web site, but you can also crawl the site yourself and use the Chrome console to get details about mixed content found.

Update Google SiteMap and Analytics

Finally make sure that your Google sitemap now references HTTPS urls, and update your Google Analytics for HTTPS:

I hope this content saves a few headaches. I am certainly not a SSL nor an IIS expert, so once again, if some part of this tutorial can be improved, feel free to comment!

Our experience with using third-party libraries

NDepend is a tool that helps .NET developers write beautiful code. The project was started in April 2004. It is now used by more than 6 000 companies worldwide.

In more than a decade, many decisions were made, each with important consequences on the code base evolution process, sometime good consequences, sometime less good. Relentlessly dog-fooding (i.e using NDepend to analyze and improve the NDepend code base) helped us a lot to obtain more maintainable code, less bugs, and to improve the tool usability and features.

When it comes to working on and maintaining a large code base for several years, some of the most important decisions made are related to relying (or not) on some third-party libraries. Choosing whether or not to rely on a library is a double-edged sword decision that can, over time, bring a lot of value or cause a lot of friction. Ultimately users won’t make a difference between your bugs and third-party libraries bugs, their problems become your problems. Consider this:

Sometimes the team just needs a fraction of a library and it may be more cost-effective, and more maintainable with time, to develop your own.
Sometimes the licensing of a free or commercial library will prevent you from achieving your goals.
Sometimes the library looks bright and shiny but becomes an obsolete project a few months later and precious resources will have to be spent maintaining others code, or migrating toward a trendy new library.
Sometimes the library code and/or authors are so fascinating that you’ll be proud to contribute and be part of it.

Of course we all hope for the last case, and we had the chance to experience this a few times for real. Here are some libraries we’ve had great success with:

Mono.Cecil (OSS)

Mono.Cecil is an open source project developed by Jean-Baptiste Evain that can read and write data nested in .NET assemblies, including compiled IL code. NDepend has relied on Cecil for almost a decade to read IL code and other data. Both the library and the support provided are outstanding. The performance of the library is near optimal and all bugs reported were fixed in a matter of days or even hours. For our usage, the library is actually close to bug free. If only all libraries had this level of excellence…

DevExpress WinForm (Commercial)

NDepend has also relied on DevExpress WinForm for almost a decade to improve the UI look and feel. NDepend is a Visual Studio extension and DevExpress WinForm makes smooth visual integration with Visual Studio. Concretely, thanks to this library we achieved the exact same Visual Studio theming and skinning, docking controls a la Visual Studio, menus, bars and special controls like BreadCrumb to explore directories. We have never been disappointed with DevExpress WinForm. The bugs we reported were fixed quickly, it supports high DPI ratio and it is rock solid in production.

Microsoft Automatic Graph Layout MSAGL (OSS)

NDepend has relied on MSAGL for several years to draw all sorts of graphs of dependencies between code elements including Call Graphs, Class Inheritance Graphs, Coupling Graphs, Path and Cycle Graphs… This library used to be commercial but nowadays OSS. Here also the bugs we reported were fixed quickly, it supports high DPI ratio and it is perfectly stable in production.

NRefactory (OSS)

NDepend used to have a C# Code Query LINQ editor in 2012, a few years before Roslyn became RTM. We wanted to offer users a great editing experience with code completion and documentation tooltips on mouse-hovering. At that time NRefactory was the best choice and it proved with the years to be stable in production. Nowadays Roslyn would certainly be a better choice, but since our initial investment NRefactory still does the job well, we didn’t feel the need (yet) to move to Roslyn.

Here are a few things we prefer to keep in-house:

Licensing

While there are libraries for licensing, these are vital, sensitive topics that require a lot of flexibility with time, and we preferred to avoid delegating it. This came at the cost of plenty of development/support and significant levels of acquired expertise. Even taking into account that these efforts could have been spent on product features, we still don’t regret our choice.

The licensing layer is a cornerstone in our relation with our users community and it cannot suffer from any compromise. As a side remark, several times I observed that the cost of developing a solid licensing layer postponed promising projects to become commercial for a while.

Persistence

As most of application, NDepend persists and restores a lot of data, especially the large amount of data in analysis results. We could have used relational or object databases, but for a UI tool embedded in VS, the worst thing would be to slow down the UI and make the user wait. We decided only optimal performance is acceptable for our users, and optimal performance in persistence means using custom streams of bytes. The consequence of this decision is less flexibility: each time our data schema evolves, we need to put in extra effort to keep ascendant compatibility.

I underline that most of the time it is not a good idea to develop a custom persistence layer because of the amount of work and expertise required. But taken account our particular needs and goals, I think we took the right decision.

Production Logs

I explained here about our production logs system. We consider it an essential component to making NDepend a super-stable product. Here also, we could have used a third-party library. We capitalize on our own logging system because, year after year, we customized it with a plethora of production information, which was required to help fix our very own problems. We kept the system lightweight and flexible, and it still helps us improve the overall stability and correctness of our products.

Dependency Matrix and Treemap UI Components

These UI components were developed years ago and are still up to date. Both then and now, I believe there is no good third-party alternative that meets all our requirements in terms of layout and performance. A few times, we received propositions to buy those components, but we are not a component provider and don’t have plans for that.

In this post I unveiled a few core choices we made over the years. We hope this information will be useful for other teams.