Add the ability to browse text files in a package without download the package

[analogrelay]

Basically, this is "Package Explorer in the Cloud" but with a clearer and more focused goal. This is NOT something we've decided to do yet, but there was enough discussion about this that I wanted to create a hub for comments on it. Please post here with comments.

(And list the contents of the file)

[TimLovellSmith]

Sounds fine. Even resurrecting package explorer sounds good as long as we do it right.
I think implementing this should involve having a worker task to extract package contents to separate blobs. We should sensibly limit the amount of blob storage we use, so we can't be put over budget by giant packages.

[analogrelay]

👍 to worker doing the work. Especially if we can make it recoverable so that if a package causes us to crash, we can simply skip it. I see the worker marking when it starts and completes processing of a package and when it starts, it checks to see if any packages were left unprocessed and flags them to be skipped (and Admins can come along and check flagged packages). That protects us, somewhat, from things that cause crashes.

[analogrelay]

This could tie in well to #804

[analogrelay]

Steps/Priority of "Sub Features":

1. Make sure it works for PowerShell/Web.Config/Props/Targets/Readme (things that change your project). Add a notice to the package page saying "This package uses PowerShell to configure itself, click here to view it"
2. Show a list of NuGet "Features" used by the package (Install.ps1, Init.ps1, config transforms, etc.). With links to view the contents of those components.
3. All Content Files
4. Xml IntelliSense Files? In a fancy view?

Of course, all three steps may be implemented together, but that's a priority break-down.

[oising]

No movement on this? I'd love to see an API that can enumerate the contents of packages (e.g. structure and filenames) at a minimum. Reading text from files, a bonus.

[maartenba]

It is on our backlog but not immediate future.