C#: `new Foo(...)` produces no edge, so message publishers and locally built types look unused

[durmazoguzhan]

A type that a C# method only constructs gets no edge. new Foo(...) parses as object_creation_expression, and the C# config lists only invocation_expression in call_types, so the construction site is never dispatched in walk_calls.

Java has treated new Foo(...) as a call since #1373, and TypeScript got new_expression extraction in #708. C# never caught up.

Which positions currently emit an edge

I probed one class with the same type used in seven positions (graphify 0.9.48):

public class AsParameter { }
public class AsField { }
public class AsReturn { }
public class AsProperty { }
public class AsLocalDeclared { }
public class AsNewInVar { }
public class AsNewInArg { }

public class Probe
{
    private AsField _field;
    public AsProperty Prop { get; set; }

    public AsReturn Get() => null;
    public void Take(AsParameter p) { }

    public void Body()
    {
        AsLocalDeclared a = null;
        var b = new AsNewInVar();
        Consume(new AsNewInArg());
    }

    private void Consume(object o) { }
}

position	edge
parameter type	.Take() references AsParameter
field type	Probe references AsField
return type	.Get() references AsReturn
property type	Probe references AsProperty
local declaration	none
var x = new Foo()	none
Consume(new Foo())	none

The last three classes are in the graph as nodes. Nothing points at them.

The same code in Java

class Worker { void run() { } }
public class Caller {
    public void go() {
        Worker w = new Worker();
        w.run();
    }
}

.go() -> Worker  [calls]  EXTRACTED
.go() -> .run()  [calls]  INFERRED

The C# translation of that file produces only the second edge.

Where it hurts

I ran graphify over a private .NET 8 codebase that moves work between services over MassTransit and RabbitMQ. Producers and consumers do not reference each other, so the only thing that can join them in the graph is the message class: the consumer implements IConsumer<T> and the producer hands a T to the bus.

That works when the producer takes the message as a parameter. Two of the three hops in one chain resolved that way, and both endpoints landed on the same message node. The third hop publishes like this:

var events = models.Select(m => new ProductUpsertRequested { Id = m.Id });
await endpoint.Send(new ProductUpsertRequested { Id = id });

The message type never appears in a declared position there, so the producer side of that node had only a contains edge from its own file. The consumer sat in another service with no path to it. A graphify path between the two ends of the chain returns nothing, and the hop looks like dead code.

The pattern is not specific to a bus. Anything a method builds and hands off has the same shape: a request object passed to a client, a config object passed to a factory, a DTO built for a mapper.

The type is already resolved

This is not a request for new inference. The extractor already types locals well enough to resolve member calls on them:

public class Worker { public void Run() { } }
public class Caller {
    public void Go()
    {
        Worker w = new Worker();
        w.Run();
    }
}

.Go() -> .Run()  [calls]  INFERRED

w is known to be a Worker there. Worker itself is simply never named as a target.

Ambiguity is also already handled. With two classes called Cache in different namespaces, the construction site resolves to neither, which is the behaviour #437 asks for.

Scope

Two things nearby that I would leave alone:

• Target-typed new() parses as implicit_object_creation_expression and carries no type node. Naming it needs the declared type of the assignment target.
• A local declared without a constructor (AsLocalDeclared a = null;) still emits nothing. That is a references-from-local-declarations question, separate from this one.

Related

• Java Records and constructor call relationships not recognized #1373 gave Java the same fix, and [TypeScript] Add interface, enum, type alias, const literal, new_expression extraction #708 gave TypeScript new_expression.
• C#: primary-constructor parameters are never walked, so constructor-injected dependencies produce no edges #2829 and fix(csharp): walk primary-constructor parameters for references and calls #2836 walked C# primary-constructor parameters, which is the injected-dependency half of the same problem.
• Cross-file inference creates false edges via common .NET method names #437 is the false-edge risk this touches. The ambiguity guard above is why I think it does not apply.
• Feature: literal/identifier usage index for string-coupling navigation #1220 would cover the other half of bus wiring, the queue name string itself. Message types alone got me far enough that I did not need the literal index.
• C#: generic type arguments are dropped in field and call-site position (captured in property/return/parameter) #2911, Fill four .NET (C# + Razor) extraction gaps #1869 and fix(csharp): emit type references for properties #1591 are the other open C# emission gaps.

I have a patch with tests and will open a PR against v8.

[safishamsi]

Fixed in v0.9.49: https://github.com/Graphify-Labs/graphify/releases/tag/v0.9.49. Closing as resolved.