If a dependency contains spaces in its path it is treated as an external request and cannot be resolved during composite file processing

[braydie]

As part of the building the encoded request for dependencies, if a file path contains a space it is encoded as %20 and stored. This means that when it comes to resolving files to combine, the framework is unable to process this file as a local file because the call to File.Exists(...) will fail and the dependency is excluded from the output.

As part of debugging it locally I was able to fix the issue by updating BaseCompositeFileProcessingProviders WritePathToStream method on line 137 to include path = path.Replace("%20", " ");. Obviously this will not work going forward as having %20 in your filename is valid (but maybe weird), but fixes it in my case.

Is there a better place for this fix to be applied? I'm not massively familiar with the inner workings of CDF and maybe wondered if there was something to be done in the BaseFileMapProvider?

Any advice is greatly appreciated

[braydie]

I've worked around this in a better way - rather than changing the underlying source I've implemented by own Composite File Processing Provider:

public class FixWhitespaceInPathCompositeFileProcessingProvider : CompositeFileProcessingProvider
    {        
        public override byte[] CombineFiles(string[] FilePaths, HttpContextBase Context, ClientDependencyType Type, out List<CompositeFileDefinition> FileDefs)
        {
            FilePaths = FilePaths.Select(s => s.Replace("%20", " ")).ToArray();
            return base.CombineFiles(FilePaths, Context, Type, out FileDefs);
        }     
    }

This is a better solution longer term I guess