Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

FileVersion GetContent Using Invalid URL

See original GitHub issue

Describe the bug

Right now, FileVersion is using $"{PnPContext.Uri}/_layouts/15/download.aspx?SourceUrl={Url}";, which may work great for a file that is NOT a FileVersion, but if the URL is _vti_history/512/MyDocLib/wordTest.docx, you actually get this from SharePoint:

Proposed Resolution

@jansenbe - If you have no issues with it, I’d rather use the OpenBinaryStream function. If you’re good with this, feel free to assign this to me, as I need to get this fixed ASAP for our team.

Side Question

What kind of download size limitations are we going to hit?

Issue Analytics

State:
Created 2 years ago
Comments:6 (6 by maintainers)

Top GitHub Comments

1reaction

jansenbecommented, Jun 10, 2021

OK, that clarifies… Don’t have a specific preference given the “regular” download will not be updated. You might want to test with some larger files, but assume both approaches will work

1reaction

DaleyKDcommented, Jun 10, 2021

Well, no. I don’t. PnP.Core still has a bug.

My bug is still accurate. You can’t use IFileVersion.GetContentAsync(). If you look at GetFileVersionContentAsyncTest-2-00003.response, you’ll see that it’s the HTML markup for the Error page in my screenshot above. IOW, download.aspx does not work for use with the _vti_history URLs.

It seems that the proper use to get these binaries is to either:

Replace the code in IFileVersion.GetContentAsync() to use the OpenBinaryStream function that is on the REST IFileVersion
Replace the code in IFileVersion.GetContentAsync() to literally just do a GET on $"{PnPContext.Uri}/_vti_history/512/MyDocLib/wordTest.docx