Using NDepend, how can we removed Cycle Dependencies generated by the compiler due to Tasks (TPL) from the Dependency Matrix?

Question

Using NDepend, how can we removed Cycle Dependencies generated by the compiler due to Tasks (TPL) from the Dependency Matrix.

If we cannot remove them, then how can we easily differentiate them from important cycle dependencies that need our attention.

Are there any best practices around dealing with compiler generated cycle dependencies?

Edit:

The compiler generated dependency cycle can be observed in the top left of the diagram

Code that generates a Dependency Cycle (Compiles in .Net 4.0)

*logger is a field in my class

  private void WriteJsonFileToDiskAsync(string filePath, string json)
    {
        Task.Factory.StartNew(() => WriteJsonFileToDisk(filePath, json))
            .ContinueWith(HandleWriteException);
    }

    private void WriteJsonFileToDisk(string filePath, string json)
    {
        Stream fileStream = null;
        try
        {
            fileStream = File.Create(filePath);
            using (var writer = new StreamWriter(fileStream))
            {
                fileStream = null;
                writer.Write(json);
            }

            logger.InfoIfDebuggerIsAttached(string.Format(CultureInfo.InvariantCulture, "Persisted file: {0}", filePath));
        }
        finally
        {
            if (fileStream != null)
                fileStream.Dispose();
        }
    }

    private static void HandleWriteException(Task task)
    {
        if (task.IsFaulted)
        {
            //TODO: Handle Exception
        }
    }

Answer 1

Alexandre, after compiling your source code, I obtain the following dependency Matrix:

We can see that the compiler generated a sub type declared inside Program from you. This generated type, named Program+<>c__DisplayClass1 is just compiler gymnastic, it is not part of your source code. This is not a problem that both these types are mutually dependent and you cannot do much about it.

To discard generated type you can write a query like...

from t in Application.Types
where !t.IsGeneratedByCompiler
select t

...and then export part of the result to the Matrix:

Finally, I'd like to add that types being mutually dependent is not a problem in the general case. Most of well-known GoF design patterns require mutually dependent types.

The problem is when you have mutually dependent components, especially if these components are namespaces. There are two white-books about this topic available publicly on the NDepend web-site.

One of the case where types being mutually dependent is a problem is when base class is using derivatives (there is a default CQLinq rule Base class should not use derivatives for that)