Today a new version of CG4T is released: version 1.4! CG4T now supports DXA ViewModel class generation:

You can find the new version in the Visual Studio gallery: https://marketplace.visualstudio.com/items?itemName=vs-publisher-740338.CodeGenerator4Tridion#overview
Or you can simply install within Visual Studio 2015 or 2017:

Happy new year to everyone!
Below a story about non-working decaching after upgrading to SDL Web 8.5 CMS.
Project setup
The project I work on has this environment configuration:
- SDL Web 8 CMS (with update SP1 and Cache Channel Service)
- DD4T 2.1 based .NET web application
- ApacheMQ as JMS solution
- We use DD4T.Caching.ApacheMQ NuGet package
- Hosted in Azure cloud
Given this setup, everything is configured to flush the Application cache when a Content Manager publishes a Page, Dynamic Component Presentation or Taxonomy from the CMS. This works really well and we achieve the two most important goals: High-performance websites + No outdated content.
Upgrade to Web 8.5 problem
But then we decided to upgrade to SDL Web 8.5 (with a new server). The upgrade process itself is not as painful as it was in the past, but we had an issue: de-caching mechanism did not work anymore. We did the most obvious checks:
- Check config settings of microservices
- Firewall settings (ports open?)
- MQ dashboard (publishers, subscribers, and messages)
- Check log files for exceptions
- Review the Topology Management config (java -jar .\discovery-registration.jar read)
Mysteriously, everything was fine. After some WebApp debugging sessions I found the issue. The JMS messages were changed and the TCM URI is now prefixed with '1:'. Maybe SDL decided to include the CacheEventTypeId? Examples:
- SDL Web 8 sends 17:3565 for pages.
- SDL Web 8.5 sends 1:17:3565 for pages.
- SDL Web 8 sends 17:52916:154 for DCPs.
- SDL Web 8.5 sends 1:17:52916:154 for DCPs
RCA and solving the issue
This causes a lookup issue when looking for depending cache items to flush within the TridionBackedCacheAgent. The agent stores pages in cache with 17:3565 and CCS tries to flush the cache with 1:17:3565. Since we have a custom implementation of the CacheAgent (for either reasons) we could fix it easily by using this code fragment in the CacheAgent:
private Regex RemoveFirstElemWhenWeb85 = new Regex("^(1:)(.*)");
private string GetDependencyCacheKey(string tcmUri)
{
return "Dependencies:" + this.RemoveFirstElemWhenWeb85.Replace(tcmUri, "$2");
}
This code backward compatible with older version of Web/Tridion as long as you do not have a publication with the ID of 1 :-)
DXA, what is it?
DXA is a reference implementation from SDL to use with SDL Web (formerly known as SDL Tridion) content management system. It uses DD4T and implements best practices on how to setup a site in SDL Web.
Great, but what is it for?
DXA stands for Digital eXperience Accelerator and is developed/supported by SDL. Its goal is to speed up CDS implementations by standardizing solutions and showing best-practices. DXA is an Open Source project which utilizes either .NET MVC or Spring MVC to provide dynamic content delivery on the CDS, depending of your technology stack.
DXA is open sourced on github and DXA documentation is available online.
Works best for new implementations.
The CMS installer adds a default blueprint structure to separate concerns. Each publication contains the necessary building blocks required for content assembly: structure groups, schemas, folders, components, and pages.
When you publish you get the sample site that showcases the DXA’s "out of the box" functionalities with dummy content and white label HTML design. This could be the starting point for further development.
What are the benefits?
Depends on how you look at it. There are benefits for business people (a.k.a. as the client) and benefits for developers. Also, there are some things to think about if DXA really supports your case. I explain more on this topic on my employer blog: http://blog.tahzoo.com/sdl-dxa-what-is-it-and-why-should-i-care/