Accepted, Not Yet Planned

See my comment and our interest in the use cases. There's likely a way to achieve the same goals with another extension point or implementers could try Java.

.NET content deployment module

A .NET content deployment module would be a very welcoming feature. This would have two main benefits.

1. The entire Tridion back-end is .NET. (Here I consider the content deployment module a back-end module) . Consistency in technology makes things easier to work with and to maintain.

2. A .NET content deployment module would invite many more people to build custom content deployment features.

Personally I am a .NET developer. I have always wanted to build custom content deployment extensions. However, with the current Tridion content deployment module I'm forced to use Java to do customization and Java skill is something I don't have, unfortunately. Building a custom deployer is therefore no option for me.

I think there are many who are in the same boat like I am. The number of Tridion .NET vs Java open source, and the questions asked on Tridion Stack Exchange do suggest this.

With a .NET content deployer Tridion would tap into a much bigger development audience, which is a good thing. It would be beneficial to both developers and Tridion. New ideas will emerge from this, no doubt.

Hoang Chu

  • Hi Alvin. This here is so hidden away, it's slipped my attention entirely. Since this idea proposal I've acquired quite a bit of Java knowledge and did some deployer extensions on the side with other non-Tridion Java development. However, I haven't changed my mind. A .NET deployer is the way to go.

    Many Tridion customers I've worked for in the past wanted to use some forms of custom data stores on the delivery side, or at least, they would'd been better off with custom data stores instead of the non-performing one-size-fits-all Broker database.

    Extending the deployer would be a logical option for these customers. But since this requires Java skill, which the majority of Tridion developers don't have, most customers ended up with less obvious alternative solutions that usually lead to unpleasant consequences. A pity.

    If it was .NET instead it would have saved at least a few burnouts.

    And as Albert Romkes mentioned .NET Core is cross-platform. I assumed Tridion at some point will be migrated to .NET Core, and I thought the deployer would be the perfect first candidate, because it is one of the most isolated and self-contained modules of the Tridion suite.

  • This has my vote too. Especially since the release of .NET Core which is cross-platform. It makes it much easier for .NET developers to extend the Content Deployment pipeline like storing some data in an extra database, pushing notifications to external services, etc.

  • Thanks for the suggestion Hoang. The deployer is very likely to stay Java for awhile since it has to support multiple platforms.

    With the Web 8 architectural split to Content Interaction Services (CIS) and Content Interaction Library (CIL) changes and with OData even before that, approaches to "Content Delivery" can be a bit more agnostic. For example, we're already seeing customers and implementers opt for things like client-side templating and personalization. They use a variety of approaches from storage extensions, "OData extensions," or delivery-side "content models" (as seen in DXA and DD4T implementations).

    In the future we'll likely continue to expand these options, but no plans for the deployer for now.

    But what use cases would you be interested in? You're thinking of the ability to extent publishing/deployment in .NET? Would other languages would be interesting for not just deployer extensions, but other parts of Content Delivery like the ADF (JavaScript/TypeScript/other)?