I'm using DD4T.Web.Binaries.BinaryDistributionModule to serve binaries from the broker database.

I have multiple instances of a single DD4T web app, each hosted as a separate virtual application under a master physical IIS site, where a Publication maps to a virtual app (as each locale will exist under a subdirectory; e.g. "mysite.com/fr"). My Publication config looks like this (for example):

Publication Path: \corporate

Publication URL: /

Images Path: \corporate\Images

Images URL: /corporate/Images

This all works fine for serving up content, linking etc. However, all requests for images fail, with the following error:

The virtual path '/BinaryData/corporate/Images/x.png' maps to another application, which is not allowed.

Looking at the source for the binary distribution module, it seems as though it is explicitly using the physical application path when constructing the image URL:

string realPath = request.PhysicalApplicationPath +
                  "BinaryData" + request.Path.Replace("/", "\\");

Obviously, this is no good, as the resulting URL no longer maps to the "corporate" application. I can't remove "corporate" from the "Images" path, however, as then the request won't reach my DD4T app at all.

Has anybody come up against this before? Is there some configuration I'm missing?

1 Answer 1


You have run into the limits of the BinaryDistributionModule I'm afraid. It currently does not support your scenario, where the different country/language sites run in separate vdirs.

The more common solution is to host all country/language sites in a single web application (mapped to /). By using a PublicationResolver you can make sure the requests are all mapped to the correct Tridion publication.

  • Welcome to the good old days of CWA publication Id resolving :). What people seem to know little about is how this functionality is now part of the core CD API. CD Dynamic contains it. I'll need to blog about it :) Commented Feb 3, 2014 at 20:17
  • Thanks Quirijn, I have already written a custom publication resolver containing the logic we require but there's some internal hesitation on serving requests for all locales under a single IIS app pool. I'll have to raise the question again.
    – Ant P
    Commented Feb 4, 2014 at 9:47
  • We've decided to give this a whirl pending some load testing. Kind of glad this limitation exists as this'll certainly streamline deployments! Thanks again.
    – Ant P
    Commented Feb 4, 2014 at 20:09
  • @MihaiCădariu The problem lies not in the publication resolving itself, but in the fact that the DD4T module caches files locally in /BinaryData and then forwards the request.
    – Quirijn
    Commented Feb 4, 2014 at 20:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.