Hi,
we use GroupDocs.Annotation 2.1.1 for .NET and are facing unreadable error messages.
Just try to open a PDF file with no content (0 bytes) to get that kind of error message.
You should handle all exceptions and show plain text error messages or at least render the HTML code of IIS error messages to make them readable.
Many thanks in advance and Merry Christmas!
Hi,
We are sorry to hear that you have faced with such issue. Could you please share with us such empty pdf (0 bytes), because even the empty pdf have 1kb size.
Thank you.
Hi Pavel,
sorry, I just meant an invalid PDF file, e.g. an 0-byte PDF.
I attached you an example.
Hi,
Thank you for the pdf example. I have created a ticket for our Product team - they will do error messages more user friendly.
Best regards.
Hi,
Sorry fore the delay. We have fixed the issue, please download fixed library here.
Also please note that soon we will release a next generation Annotation library and will need to migrate on it.
Best regards.
Thank you Pavel!
Do you also have a direct download link for people without a google account?
What about the other unresolved bugs that really hurt?
Regards,
Phil
Hi Phil,
The direct link. As for the other issues - they still in the queue and will be resolved. Then I will notify you.
Best regards.
Hi Pavel,
thanks! The invalid PDF error looks much better now! 
But a new bug came with this version:
The file-sessions.json file holds its file mapping with forced lower case file extensions now. So if you show a file with the name “file.PDF” it’s saved as “file.pdf” in the file.sessions.json file, resulting in an invalid SessionID by FileSessionMapper.Instance[“file.PDF”] (= 0). Only forcing the file extension of the showing file to lower case seems to solve this issue.
Nevertheless the file is shown in the viewer. Just the sessionid mapping is inconsistent.
Regards,
Phil
Hi Phil,
Thank you for the request. You can resolve this issue with such simple workaround:
var documentEvent = (IDocumentProcessingEvent)eventDesc;
string docPath = documentEvent.DocumentPath;
string extToLower = Path.ChangeExtension(docPath, Path.GetExtension(docPath).ToLower());
var testc = FileSessionMapper.Instance[extToLower];
This code will take opened file extension and change it with the lower case analog.
Best regards.
Thanks!
Another issue is, that an existing session is not kept on a GroupDocs version upgrade (2.1.1 to 2.1.2).
The file-sessions.json then looks this way for the same file:
{
“doc.PDF”: 1,
“doc.pdf”: 2
}
Regards,
Phil
Hi Phil,
Thank you for asking. I have tried to reproduce such behavior - unfortunately I can’t, the session data for the document is always contains only one record - with low case file extension.
Could you please share with me example of your project?
Thank you
Hi Pavel,
more precisely:
Opening the file “doc.PDF” with GrouDocs.Annotation 2.1.1 via widget.FilePath(“doc.PDF”) results in the file-sessions.json file
{
“doc.PDF”: 1
}
When you upgrade GroupDocs.Annotation to Version 2.1.2 (keeping Database + file-sessions.json with file ID 1 in App_Data) and open the file again via widget.FilePath(“doc.PDF”) the old entry with ID 1 is kept and the new ID 2 (lower case extension) is added in the file-sessions.json file:
{
“doc.PDF”: 1,
“doc.pdf”: 2
}
If you start with a clean database and file-session.json only the ID 1 is created with lower case extension (I guess that’s what you checked). But normally you keep your database and so all upper case file name extensions will get a new ID with lower case file extension. The old mapping is garbage then.
Regards,
Phil
Hi Phil,
Thank you for the explanation. Yes, you are right. You can delete these junk elemetns manualy or with such code:
string json = File.ReadAllText(Server.MapPath(@"~/App_Data/file-sessions.json"));
string mach = Regex.Replace(json, “(\”[a-zA-Z]+\.[A-Z]{3}\": [0-9]+)", “”);
System.IO.File.WriteAllText(Server.MapPath(@"~/App_Data/file-sessions.json"), mach);
This code will do next: read the json file -> delete all elements with upper case extension -> update the json file
Best regards.
Hi Pavel,
thanks for the steps!
By adapting the regex to match all valid file names and extensions I can work around the first part of the problem.
The major problem is that the annotations of ID 1 do not get mapped to the new ID 2 and thus are orphans now. So all former annotations are lost by this issue.
So I think the best solution is to not workaround the issue, but to fix it.
Regards,
Phil
Hi Phil,
I have notified our Product team about the issue - they will fix it.
Best regards.