0

I have a simple ASP.NET Core 6 MVC web app to test viewing various files. The tests were performed in Visual Studio 2022 on localhost.

The test steps include:

  1. Using a sample file example03.docx and save it in .htm format.
  2. It created 2 items example03.htm and a folder example03_files
  3. Copied the file and folder to /wwwroot/files folder
  4. In the app, in the HomeController, add an action method ViewWordFile (see CODE #1)
  5. Created a view ViewWordFile.cshtml (see CODE #2)
  6. Test the code and everything worked as expected

I encountered problems after trying to compress the example03.htm and related folder into example03.zip file. I then tried to unzip that file in a ViewWordFile action method (see details in problem description section below)

CODE #1:

public IActionResult ViewWordFile()
{
    return View();
}

CODE #2:

@{
    ViewData["Title"] = "View Office File";
}

<div class="container">
    <h3>View MS Word Document</h3>
    <p>
    <div class="row text-center">
        <iframe src='https://localhost:7131/files/example03.htm' width='100%' height='650px' frameborder='0'></iframe>
    </div>
    </p>
</div>

Problem description:

  1. Added 2 subfolders /wwwroot/files/zipped and /wwwroot/files/unzip
  2. Manually created zip file example03.zip and copied it to the /files/zipped folder
  3. In order to decompress the zip file, I added a method unpackFile in the HomeController (see CODE #3)
  4. Modify the ViewWordFile action method (see CODE 4)
  5. When trace the code during execution, the unzip worked fine and unzipped files were placed in the /files/unzip folder
  6. After these changes, the ViewWordFile action stopped working. During tracking, I could see the view was activated, when I put a breakpoint in the code block at the top. But, nothing was displayed. It looked like it was still at home page.
  7. I thought it might be a file permission issue. I removed code calling UnpackFile in ViewWordFile action (as in CODE #3) and keep using files in /unzip folder. The page started working again. It showed file permission was not the actual problem.
  8. I suspect there was something with calling ZipFile.ExtractToDirectory. I changed code to call this method inside of ViewWordFile action (see CODE #5). The problem happened again and page stopped working.

It seemed that the ZipFile method interfered with the view. But I was unable to figure out the actual reason.

Any help or suggestions for troubleshooting will be greatly appreciated.

CODE #3

private bool UnpackFile (string zipFile, string unzipDir)
{
    bool isOk = false;

    if (System.IO.File.Exists(zipFile))
    {
        ZipFile.ExtractToDirectory(zipFile, unzipDir, true);
        isOk = true;
    }

    return true;
}

CODE #4

public IActionResult ViewWordFile()
{
    string zipFile = Path.Combine(_hostEnv.WebRootPath, "files/zipped", "example03.zip");
    string unzipDir = Path.Combine(_hostEnv.WebRootPath, "files/unzip");
    UnpackFile(zipFile, unzipDir);

    return View();
}

CODE #5

public IActionResult ViewWordFile()
{
    string zipFile = Path.Combine(_hostEnv.WebRootPath, "files/zipped", "example03.zip");
    string unzipDir = Path.Combine(_hostEnv.WebRootPath, "files/unzip");
    ZipFile.ExtractToDirectory(zipFile, unzipDir, true);

    return View();
}
marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
bedrock
  • 263
  • 1
  • 2
  • 15
  • If you directly access the page inside the browser, will it work? – Brando Zhang Apr 25 '23 at 08:24
  • Yes. the decompressed file does work when accessing the page directly from the browser. – bedrock Apr 26 '23 at 17:08
  • Could you please tell me what's the status codes inside the browser's F12 network trace? – Brando Zhang Apr 28 '23 at 07:17
  • I started web app in Chrome and opened "develop tools" and "network" tab. When I tested of viewing the unzipped file, the last 2 entires in listed info under network tab showed the status code 101. I am not sure whether this is the correct way of checking the status code. If not, please let me know how to do it correctly. – bedrock Apr 29 '23 at 17:17
  • 101 normally means the websocket upgrade. If possible could you please share the network trace? – Brando Zhang May 01 '23 at 02:08
  • I have captured the network track in a .HAR file. But, I am unable to attached the file to this post. I also tried to save Console log. It did not have tracing data. Please let me know what I should do in order to share the network trace. Thanks. – bedrock May 02 '23 at 13:51
  • You capture the image for that html file's status codes or response details. – Brando Zhang May 03 '23 at 05:20
  • Request URL: ws://localhost:51568/WebViewer/ HTTP Version: HTTP/1.1 Request method: GET Headers: Accept-Encoding gzip, deflate, br Accept-Language en-US,en;q=0.9 Cache-Control no-cache Connection Upgrade Host localhost:51568 Origin https://localhost:7131 Pragma no-cache Sec-WebSocket-Extensions permessage-deflate; client_max_window_bits Sec-WebSocket-Key 7tefxGAIcHonWVyCbS3pSA== Sec-WebSocket-Protocol ....... Sec-WebSocket-Version 13 Upgrade websocket User-Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36 – bedrock May 04 '23 at 20:16
  • I just pasted the details of last entry with 101 status code in last comment. I got the info using Google .HAR analyzer to view the .HAR file I created. I am not sure whether it contains any usefule info. – bedrock May 04 '23 at 20:19

0 Answers0