Cache files are not created in correct location when using network path


Network payth:\U0101485-TPL-D\mygj

File location \U0101485-TPL-D\mygj\009\14\PreviewDocExport

Cache location network path\U0101485-TPL-D\mygj\009\14\PreviewOtherExports\PreviewingDocumentXmlCache

var storagePath="\U0101485-TPL-D\mygj\009\14\PreviewOtherExports\PreviewingDocumentXmlCache";
var config = new ViewerConfig
StoragePath = storagePath,
CachePath = Path.Combine(storagePath, “PreviewingDocumentXmlCache”),
CacheFolderName = “PreviewingDocumentHtmlCache”,
UseCache = true


This put cache file in


I was expecting cache file in


Cache file is put in right location if i dont use network path and put like in c:\temp



Thanks for using GroupDocs.Viewer and sharing your concerns with us. Would you please tell us the version of GroupDocs.Viewer you are using?


version is for groupdocs.viewer

Let me know if my above example make sense.Network path put cache file in wrong location but functionality is working fine.But if i use local path,all looks fine

if you need my group doc order id let me know



Thanks for providing the details. First of all please note that when ViewerConfig.CachePath property is set, ViewerConfig.CacheFolderName property will be ignored. Therefore, in your case, CachePath property will be used as the cache directory.

Secondly, ViewerConfig.StoragePath acts as the base path of the input file. If you do not provide the complete path of the file in GetPages function and instead, you only provide the file name i.e. sample.txt, then the StoragePath property is used as the base path of the file. However, if you provide the complete path of the file (same as in your code), the StoragePath property is ignored.

After investigating the issue using your code, we observed that when rendering file from the network path, the API is not generating cache files in the predefined cache folder. However, it works fine when rendering file from the local folder. We have logged this issue in our issue tracking system (with ID: VIEWERNET-1474) for further investigation. We’ll keep you informed about the outcomes.



The issue you have found earlier (filed as VIEWERNET-1474) has been fixed in this update.