Error when loading file via guid

[ManuelHaas]

I use CustomFileStorage to load files that are stored in database and identified via guids. So I set the guid as parameter when calling the viewer.:

<a href="/viewer?file=5e3e3078-556f-4ded-a09f-08d8695cbee5">Attachment</a>

But this does not seem to work. I get: [13:55:43 ERR] HTTP POST /viewer-api/loadDocumentDescription responded 500 in 10026.6241 ms The byte array will be returned by ReadFileAsync but in the viewer a popup will be displayed with the text: "File type not supported"

public class CustomFileStorage : IFileStorage
{
    private ApplicationDbContext _db { get; }

    public GroupDocsFileProvider(ApplicationDbContext context)
    {
        _db = context;
    }

    public Task<IEnumerable<FileSystemEntry>> ListDirsAndFilesAsync(string dirPath)
    {
            throw new NotSupportedException();
    }

    public async Task<byte[]> ReadFileAsync(string fileId)
    {
        Guid fileIdGuid = new Guid(fileId);

        if (string.IsNullOrEmpty(fileId))
        {
            throw new ArgumentNullException("FileId not supported");
        }

        var file = await (from f in _db.Files
                          where f.FileId == fileIdGuid && !f.Deleted
                          select new
                          {
                              Content = f.Content,
                          }).SingleOrDefaultAsync();
        if (file == null)
        {
            throw new Exception("File not found");
        }

        return file.Content;
    }

    public Task<string> WriteFileAsync(string fileName, byte[] bytes, bool rewrite)
    {
            throw new NotSupportedException();
    }
}

If I call the viewer with a guid and even try it with a file that previously worked I get the same error:

    public async Task<byte[]> ReadFileAsync(string fileId)
    {
        var bytes = await _fileStorage.ReadFileAsync("sample.docx");
        return bytes;
    }

This also leads to the "File type not supported" error.

Note: The error occurs regardless of whether you work with caching or not.

[vladimir-litvinchik]

@ManuelHaas

Thank you for reporting this issue in a separate thread. The "File type not supported" error appears because Viewer can't detect the type of the selected file. We're looking into this issue and update as soon as we have any new information.

[ManuelHaas]

@vladimir-litvinchik Can you estimate if you can provide a solution to this problem? And if so, by when? If it works, I will buy a developer OEM licence. Maybe this will help ;-) I don't want to be a nuisance but I'm a bit pressed for time and need a solution in time for the next release.

[vladimir-litvinchik]

@ManuelHaas

This issue is in progress. As soon as we have a working solution we'll update you.

[vladimir-litvinchik]

@ManuelHaas

To resolve the issue please update GroupDocs.Viewer.UI.SelfHost.Api to 3.1.14 and add a class that implements IFileTypeResolver interface that declares a single method Task<FileType> ResolveFileTypeAsync(string filePath). Please also check this sample-application.zip for a basic example.

The implemented class should be added as a service

public void ConfigureServices(IServiceCollection services)
{
    services.AddTransient<IFileTypeResolver, MyFileTypeResolver>();
    ...
}

Looking forward to your response.

[ManuelHaas]

@vladimir-litvinchik Thank you very much for providing this quick solution! The documents will be shown now.

But one more question comes up: The methods ReadFileAsync and ResolveFileTypeAsync are called several times for one file that should be displayed. For example: 3 times for a singe page visx 5 times for a 8 pages docx 9 times for a 27 pages docx

This is rather inefficient. Especially since for ReadFileAsync the entire file has to be loaded from the database each time. Have I overlooked something or am I doing something wrong?

[vladimir-litvinchik]

@ManuelHaas

I've reproduced a similar behavior. One issue has been discovered in the client-side logic and one in the server-side code. In combination, these two issues lead to such inefficiency. These issues will be handled in #18.