I’m hoping to get a little more information regarding a new issue we’re seeing related to .msg files in our web app.
We previously had the project configured as a C#/net5.0 SPA that ran our React web app and interfaced with a net5.0 API. Prior to updating to net7.0, we split out that functionality so the front end is just a React app and there’s an API gateway that runs separately that handles the login. I believe it was this change that led to the error we’re seeing now.
We could open message files like the one attached and they’d appear like the first image in the viewer, but now it appears that anything with an image or any sort of complex content, like a picture, item in the signature, etc., comes back like in the second picture, encrypted or mistranslated.
I have a copy of the .msg file from the pictures saved if you have a way to receive it.
I just wanted to know if you’ve seen anything like this and might be able to point me in the right direction. If you need any further information about our implementation, please let me know.
I am a bit confused with the pictures, so I will ask you some questions, please.
The pictures seem to be taken from a different file, which seems like another language more than encrypted.
Are the pictures from different files, and are they just an example?
Does this happen with all file formats?
Could you provide one file where this issue happens that contains no sensible or private information?
This is a more consuming request than a question to determine where the issue may be.
Can you serialize the response from your .NET 7.0 application and save it to disk over the network where your REACT App is? Can you open the file correctly? (open it in the machine via windows explorer, not via any application coded by your team, this is to figure out how the file is arriving.)
Thanks for the response! I was really hoping this would have a simple setting I was overlooking in the documentation, or something like that, but it looks like it’s probably more complicated.
I’ve been trying to figure some more out about this and I have some additional info and created some generic testing docs with no sensitive info per your request. Here’s what I’ve found out so far:
This is only happening when the doc viewer is using an EmailConfig. (.msg and .eml extensions)
In my dev environment, I have to set the timeout very high and allow it to run for a couple of minutes to get the token.
It only happens with larger emails (it seems to happen around >150-200kb).
Both of the original pictures I had included were taken from the same document. I wasn’t very worried about the contents in there, but I have since edited the original and I’m including new documents here.
I’m including two emails in the attached zip file. The smaller one, the “Simple message test.msg” still works as expected, but the “ExampleTest.msg” is showing the issue. The screenshots show the working version from our QA environment. I’m noticing that the response is different between the two versions, so I included that in the screenshot. In the working version it’s:
<?xml version='1.0'?>2,956,1238
The email is two pages on the viewer.
In the new version the response looks like:
<?xml version='1.0'?>200,956,1238
The document is also 200 pages long.
The line it’s hanging on in the dev environment for EmailConfigs is where OpenDocument gets called:
var token = docViewer.OpenDocument(fileCopy.Bytes, fileCopy.Ext, config, documentOptions);
Yes, it does appear to be an issue with the backend specifically. That OpenDocument method seems to take around 60-100 seconds if I view it in Visual Studio Diagnostic Tools, but in real time it’s taking more like 5+ minutes to run if the email is a ‘problem document’, depending on the initial size.
The one I attached usually takes about 7-8 minutes and the diagnostic session was at 1:23 (83s) on the last run.
I am getting the same result on .NET 6.0 as well. I even tried rolling it back to .NET 5.0 with the same result too… I’m a little stumped on this one.
I do not want you to think I have given up on you. I made a demo sample based on our samples. And I managed to make it work with both emails and it took seconds to run on my dev machine with Windows 10.
Here are the samples opened:
So I am guessing it can be 2 things.
The new machine has a problem(I really hope this is not the one)
Is related to the EmailConfig. What are you setting on it?
On mine, I have the default from the demo.
Hi Carlos! Thanks for the response and sorry for the delay! Our EmailConfig is just set up with the EmailEncoding flag:
config = new EmailConfig { EmailEncoding = Encoding.UTF8 };
I will try adding the ConvertHtml = false option in the config. I do have some other things I’ve been working on but I should be able to get back to this by tomorrow morning if everything goes smoothly.
Hey, sorry for the long delay! I want to follow up on this again. I’ve put together a miniature version of our project with the API and React sides separated out like they are in our codebase.
I’m running the API part in Visual Studio according to the launch profile in the launchSettings.json. I omitted the bin folder to save on file size. I also left out a folder from the root path, “Doconut”, which contains the Doconut.Config.dll, Doconut.Formats.dll, and Doconut.Viewer.dll.
The formats file was 80 gigs and went over the limit to attach here. Lastly, I left out the Doconut.lic in the root directory. I don’t want to post that publicly.
The front end I’m running from a terminal/command line using the npm start command. Here, I got rid of the node_modules to save on file size. You should be able to restore them with the npm install command.
This smaller version of the project has the same issue I described last month and closely resembles our implementation.
The issue on screen looks like this (hoping this image attaches correctly, I’m not seeing it in the preview): image.jpg (175.1 KB)
I’m hoping there’s just something wrong with my configuration. I can spend some more time next week going over the examples I have again and seeing if there’s anything different I can try. Otherwise, hopefully this project will allow you to replicate the issue I’m seeing locally. If you’re not able to replicate the issue, maybe I’ve got something from with one of the dll files or the license?
If you have any issues getting this miniature project running or need me to set it up differently in any way let me know. If you’ve got any guesses or when you figure out anything related to why bigger message files aren’t coming back right, I’m struggling for answers here. Thanks.
Reading my last comment back this morning, it looks like it could be confusing. Please let me know if you’d like me to clarify anything in my previous post.
I wanted to see if there’s any way you could share the demo sample that was mentioned on July 24 by uploading a .zip or something similar, like a file upload service link… I know it’s been a while since that demo sample was mentioned, I’m really just looking for any additional resources or examples at the moment. Thank you.
Were you able to replicate the error described, based on the example project in my post from August 25? Is there any additional information I can provide, or do you have any recommendations for an alternate implementation of Doconut based on that sample?
Hello, I’m going to check your example project. Keep in mind .NET 7 and React are not part of the official supported frameworks. Give some time to review the code.
I tested the file with the issue using the example you provided, and it displayed a mistranslation error. Additionally, the viewer is adding extra pages.
However, as indicated by the images below, the file remains intact without any corruption. The examples utilizing Angular and .NET Core demonstrate proper functionality.
The error is occurring because Doconut does not currently support React. I have informed the development team, but as of now, there is no set date for the release of an update to support React.
