rune on 19 Oct, 2017 03:22 AM
Oops sorry about that -- have you by any chance tried to just deploy the background worker (I'm assuming a console project?) by building it as standalone app? I'm pretty sure that'd work as it produces an *.exe which is already supported by the process manager for background workers. This will likely just require you to define the OutputType and RuntimeIdentifiers as described in this article.
EDIT: I also should mention that building the project on my computer did not generate a .exe file whatsoever.
EDIT2: Using RuntimeIdentifier (without s at the end) works on my pc, but on AppHarbor the logs say Subscription has web workers, but no website was found in build. I can see the exe file being generated though.
rune on 19 Oct, 2017 06:59 AM
Ok so it looks like the project may have been configured to published to the _PublishedWebsites directory? If so that explains why it's deployed as web worker for a new app as AppHarbor will prefer assigning a web worker over a background worker if both are present in the directory.
I took a look at the build artifact and you should actually be able to deploy the application as a background worker. You can just set the web worker count to 0 and the background worker count to 1 to deploy the artifact as a background worker instead. However, by default all executables in the build will be started by the background worker process manager, so that's probably not the most desirable solution. Currently there are two test.exe since the build copies the stand-alone app to the defined publish directory in addition to the base output directory.
There are a couple of ways you can explicitly define what executables to run under the background worker. However I think the best solution in this case would be to simply eliminate the duplication of the executable and avoid confusing the worker type by removing the PublishDir property in your .csproj, e.g. this line:
This should cause the worker for a newly created app to assign a background worker rather than a web worker as the build no longer contains what appears to be a web project. However for an existing app you'd need to change the subscription manually.
I managed to fix it. I had to add <PublishDir>$(OutDir)</PublishDir> to the csproj file because for some reason multiple .exe files were generated and it was running the wrong one(?) I don't know for sure. But this is what my csproj file ended up being like:
rune on 25 Oct, 2017 09:19 AM
Yes automatic test discovery and execution is not currently supported by AppHarbor's test runner, so that's why no tests show up during the test step. I'd currently expect this to be supported within 3-4 weeks for at least xUnit and MSTest-based unit tests.
In the meantime you could also configure the test execution in project files, but unless this is important (e.g. for a production app) you might want to wait until it's supported by AppHarbor. Adding a test execution step in your project files now won't break when AppHarbor adds support, but might cause unit tests to be executed twice as the test runner will be invoked after the build step is completed.