Diagnosing “Restore failed” with ASP.NET 5 on Mac

Sun, 09 Aug 2015 20:57:02 +0000

Following along with Steve Smith’s “Your First ASP.NET 5 Application on a Mac”, I found myself frustrated that, despite all my efforts, the simple little sample project I was trying to get running just wouldn’t work due to a problem with restoring the project’s dependencies.

Retracing my steps

I got ASP.NET installed on my Mac, and I even got a cool little template going using Yeoman.

I opened up my scaffolded project using Visual Studio Code, and began the dependency restore process. But it failed. So I troubleshooted (troubleshot?), and it failed some more.

“Restore failed Unknown header: 3208085783”.

I found David Fowler’s “Diagnosing Dependency Issues with ASP.NET 5”, but none of the things he mentioned helped resolve my exact issue. But something he said, caused me to think:

Make sure your DNX and packages are on the same version “train”

My issue wasn’t with DNX, but with Mono.

Mis-matched Mono versions

When I followed the instructions for installing ASP.NET, I distinctly remember installing Mono using the installer package available at their website.

What I failed to realize, however, was that a while back (long enough ago to where it didn’t hit me until just a few minutes ago), I installed Mono using Homebrew.

So despite my efforts to install Mono using the installer package, the Mono that everything in my system was using was the one installed by Homebrew, which was version 3.10.

Resolved

To resolve the issue, I went ahead and just ran brew upgrade mono.

Verifying that Mono was successfully upgraded via a mono --version command, I retried the dependency restoration in my scaffolded ASP.NET 5 application.

The result?

dnu restore produced a wonderfully green, “Restore complete”!

DotNetZip – Solving Mac Decompression Issues

Sat, 28 Dec 2013 20:55:27 +0000

As part of a ASP.Net Web API service that I’m co-developing, I have gotten familiar with the DotNetZip Library. It’s fantastic. We’re using it to gather up a set of requested files from network storage, package them in a zip archive, and stream them back to a client via a web application.

During testing, things worked great on Windows machines, but the moment we tested using a Mac, we ran into issues.

Synopsis:

Problem: On a Mac, a zip file would be downloaded, but it could not be extracted. Double-clicking the zip file resulted in the creation of a .cpgz file.

Solution: In ASP.Net code, change

HttpContext.Current.Response.ContentType = “application/zip”

HttpContext.Current.Response.ContentType = “application/octet-stream”

Problem Details:

A zip archive would download as normal, but as things were wrapping up, Safari would try to decompress the file and it would fail.

Error from Safari’s download manager area:

Furthermore, when attempting to simply extract the files directly using the built in Mac Archive Utility (by double-clicking the zip file), the utility would actually re-archive the file, rather than extract it. The end result was the creation of a .cpgz file. Attempting to decompress that file would result in creating another .zip file, which, when double-clicked, created another .cpgz file, and so on, and so on.

Archive Utility re-archiving the zip file when double-clicked (rather than un-archiving it)

Creation of .cpgz file:

Needless to say, the solution to this problem, though somewhat mysterious, was quite simple for me.

In my ASP.Net code, I was writing the zip file to the Response OutputStream. I had added a content type of “application/zip” to the response. This is what was breaking the zip files on a Mac. Buried in the DotNetZip Library’s forum was a post recommending changing the content type to “application/octet-stream” instead. That single changed fixed the issue for standard zip files!

Solution Details:

Change