Frequently Asked Questions
Please see the getting started guide for info on how to deploy your first app and the How it Works page if you're curious about how AppHarbor works. You can also review and search support discussions on AppHarbor.
return code 22 fatal: git-http-push
- Please verify that you've setup your Git repository as described in the Getting Started Guide and that you're using a recent version of Git.
- Make sure that your Git username and email address contains only ASCII characters.
- The AppHarbor Git repository implementation can be finicky, consider waiting a few minutes, then push again.
- Consider taking advantage of the AppHarbor Bitbucket support or GitHub support.
- Inspect the build log to determine the cause of the error and try to fix it.
- If you're committing the contents of your
debugfolders, that might trip up the AppHarbor build process. Use a .gitignore file (or the equivalent for other versioning systems) and untrack any dll's in your build output folders.
- If there are
missing referenceerrors, you should ensure that your app does not rely on non-standard dll's being present in the GAC or other places outside what you commit in your repository. Using NuGet and pushing the
packagesfolder is a great way to manage dependencies.
- If you don't want to include the NuGet packages in your repository you can enable NuGet package restore.
- If you get
Could not resolve this referenceerrors, you should ensure that all references required to build you code are either available as NuGet packages above or are placed in a
\libfolder (or similar) and your projects references the dll's placed in that folder.
- If you get problems with paths in web site projects, you can
replicate the AppHarbor build on your local machine by running this
command in a Visual Studio command prompt:
msbuild solution.sln /p:Configuration=Release /property:OutDir=C:\temp. If you also want to debug the precompile step, you should attempt to run the
aspnet_compiler.exeon the build output of the site you're deploying.
- If you get problems with paths in web site projects, you can replicate the AppHarbor build on your local machine by running this command in a Visual Studio command prompt:
- AppHarbor uses Gallio to run tests, use that to reproduce and fix any problems with your unit tests.
- Configuration variables from add-ons (including database connectionstrings) are NOT available in the application configuration file while tests are executed. Generally, your tests should not depend on external services, consider mocking out relevant dependencies.
I.e. you're getting HTTP 500, 502 or 403 access denied once your application is deployed on AppHarbor.
- Check the root content that AppHarbor retrieves after deployment for any problems. It's available in the build log for the currently deployed build.
- Set Custom
Errors to off in
web.configto see what you application is doing.
- Check the AppHarbor Errors interface to see if we have logged any errors for you application.
- You can log your own messages to the error log for debugging.
- Download the build output from the build page on AppHarbor and verify that AppHarbor has built what you expect.
- If the
_PublishedWebsitesdirectory contains multiple subdirectories, AppHarbor will deploy the first one. Check out the AppHarbor solution file convention for help on how to control what projects get built and deployed.
- If enabling Custom Errors doesn't produce a stacktrace, then that's indicative of a configuration problem that prevents the ASP.NET runtime from initializing. You can debug such problems by deploying your app (either built locally or build output downloaded from AppHarbor) to a full IIS running on your local machine. You must configure the application pool to run in Integrated Pipeline mode to properly replicate AppHarbor's environment.
- If you're getting 502, that suggests that your code is somehow killing the process hosting your app. Download the build output from AppHarbor and deploy it to a full local IIS to reproduce the problem.
- Verify that you have added the hostname in the AppHarbor interface.
I.e. you get 404 responses for images or other files.
- Verify that the files are included in your project or are
marked as Build Action
Content(right-click the file in question in Visual Studio and choose "Build Action").
- Verify that the files are committed to your repository.
- IIS will recycle application pools after 20 minutes of inactivity. The first request once app pool restarts takes longer than usual
- Add Glimpse to your app to get information on what parts of your app are slow
- Add the New Relic to get detailed performance reports
- By default, applications deployed on AppHarbor can only write
- You can enable write access to the entire application directory application settings.
- Note that changes (both to
App_Dataand the rest of the application directory) are not persisted between deploys and you should only use it for caching and other temporary uses.
- If you're using Code First, use migrations, configure automatic migrations or use this NuGet package. If you don't, Entity Framework will drop your database and you have to delete the add-on and re-add it.
- If you want to use connection string-replacement, you must use provide metadata for AppHarbor to insert, details here.
- You generally shouldn't use SQL Server Compact for applications running on AppHarbor because the instance filesystems are not persisted nor synced between instances. Use Sequelizer instead. You can use SQL Server Compact Edition for unit tests and we provide a sample.
- This is most likely because you're behind a firewall that
blocks access on port 1433 (eg. at Starbucks or similar).
- It could also be because Entity Framework (in all its wisdom) decided to drop your database. In that case, you'll have to delete the sequelizer add-on and add it anew. See the Entity Framework section for tips on how to avoid this.
- Also check this article if you can't connect.
- If you have suggestions on how to improve AppHarbor, feel free to add them on the https://appharbor.com/feedback.