Freigeben über

Changes in the Workspaces releases area

  • Artikel

As I mentioned last week, the Workspaces on GotDotNet are going to see a few changes tomorrow. There will be some downtime while the modifications are made across the site but expect all data to remain intact.

Some of the changes on the way in the releases section:

  • Per-release download count. See how many people are downloading your releases.
  • No more zero-byte/corrupt downloads. While 308090 remains, we've changed the download page to work around these problems.
  • No more Passport sign-in for downloads. Get to the bits right away. 
  • Off-site hosting of releases. If you're running up against the release quota limit or need to link to another product primarily hosted elsewhere, try this out.

Comments

  • Anonymous
    March 15, 2004
    Hey, good news about GotDotNet Workspaces again! Changes on the releases section scheduled for tomorrow include: per-release download count (AT LAST!!!), no more zero-byte/corrupt downloads (I hope), no more Passport sign-in for downloads (great), off-site hosting of releases (cool). Really sweet. [Via Andy Oakley]...
  • Anonymous
    March 16, 2004
    Dude, the recent checkins feature is sweet! With XML feed too! No more need for checkin mail! wohoo.
  • Anonymous
    May 31, 2004
    Could you perhaps explain how you worked around 308090? It is being a pain for me and nobody seems to have a good answer.
  • Anonymous
    June 01, 2004
    We ended up creating an implementation of IHttpHandler.

    The handler, located in its own directory, is set to handle all incoming requests:

    <httpHandlers>
    <add verb="*" path="DownloadRelease" type="GotDotNet.Community.Workspace.ReleaseDownloadHandler, ReleaseDownloadHandler" />
    </httpHandlers>

    In the implementation, the ProcessRequest method handles the spitting out of the bytes to context.Response. They key difference in this approach is that you can set the incoming link to a URL that appears to be a ZIP file (.../releases/download/abc/myfile.zip say) and use context.Request.PathInfo.Split to extract the parts you need (abc, for the Workspace, myfile.zip for the file). It's generally the Content-Disposition header part that confuses IE and exacerbates 308090 and this solution hides all of the underlying dynamic generation from the browser.

    Sadly, there remain a few client scenarios where the problem persists even with this approach, but it seems to work for the vast majority.

    Hope that helps.