Changes in the Workspaces releases area

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 (4)
  1. 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]…

  2. Omar Shahine says:

    Dude, the recent checkins feature is sweet! With XML feed too! No more need for checkin mail! wohoo.

  3. Matt Johnson says:

    Could you perhaps explain how you worked around 308090? It is being a pain for me and nobody seems to have a good answer.

  4. Andy Oakley says:

    We ended up creating an implementation of IHttpHandler.

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


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


    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/ say) and use context.Request.PathInfo.Split to extract the parts you need (abc, for the Workspace, 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.

Comments are closed.

Skip to main content