Support for .Net Core 2.0?

Kef's Avatar

Kef

10 Sep, 2017 08:04 PM

Does AppHarbor support .Net Core 2.0 yet? If no, do you have an ETA of when it will happen?
Thank you in advance!

  1. Support Staff 1 Posted by rune on 13 Sep, 2017 05:34 AM

    rune's Avatar

    Hi,

    We just rolled out support for .NET Core 2.0 earlier today, so this should actually work now. Note that you'll have to make a couple of small changes to your project file as described in this comment.

    I hope this helps and let me know if you experience any issues!

    Best,
    Rune

  2. rune closed this discussion on 13 Sep, 2017 05:34 AM.

  3. Kef re-opened this discussion on 13 Sep, 2017 03:54 PM

  4. 2 Posted by Kef on 13 Sep, 2017 03:54 PM

    Kef's Avatar

    Does the same work for background worker apps? So far the changes describe ASP.Net Core only!

  5. 3 Posted by Kef on 18 Oct, 2017 09:50 PM

    Kef's Avatar

    I still didn't get a reply, rune! The file edits only work for ASP.Net Core projects, so only web workers not background workers! I'd really appreciate your reply.

  6. Support Staff 4 Posted by rune on 19 Oct, 2017 03:22 AM

    rune's Avatar

    Hi,

    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.

    Best,
    Rune

  7. 5 Posted by Kef on 19 Oct, 2017 04:07 AM

    Kef's Avatar

    Thanks for your reply.
    What should be added in RuntimeIdentifiers for AppHarbor though?

  8. 6 Posted by Kef on 19 Oct, 2017 04:21 AM

    Kef's Avatar

    Basically this is my .csproj file:

    <Project Sdk="Microsoft.NET.Sdk">
      <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>netcoreapp2.0</TargetFramework>
        <RuntimeIdentifiers>win10-x64</RuntimeIdentifiers>
      </PropertyGroup>
    </Project>
    
    Still deploys a web worker for some reason!

    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.

  9. Support Staff 7 Posted by rune on 19 Oct, 2017 06:59 AM

    rune's Avatar

    Hi,

    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:

    <PublishDir>$(OutDir)_PublishedWebsites\NetCoreWebApp\</PublishDir>
    

    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 hope this helps -- know how it works out!

    Best,
    Rune

  10. 8 Posted by Kef on 19 Oct, 2017 12:48 PM

    Kef's Avatar

    I didn't realize I had to change workers manually after they were assigned. Thank you.

    But now another problem arises. I really have no idea what's causing it, but you can check my test project's logs. Says it's missing an assembly.

    Thank you in advance!

  11. 9 Posted by Kef on 19 Oct, 2017 01:08 PM

    Kef's Avatar

    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:

    <Project Sdk="Microsoft.NET.Sdk" DefaultTargets="Publish">
      <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>netcoreapp2.0</TargetFramework>
        <RuntimeIdentifier>win10-x64</RuntimeIdentifier>
        <PublishDir>$(OutDir)</PublishDir>
      </PropertyGroup>
    </Project>
    
    Thank you for your help. I really appreciate it!
  12. 10 Posted by Pete on 24 Oct, 2017 12:10 AM

    Pete's Avatar

    Hi Rune,

    I appreciate the explanation provided to configure net core 2.0 apps - It's been a relatively painless process.

    Is there any support for detecting and running tests from a second project which contains xUnit tests?

    I have a webapp that publishes perfectly fine and the tests are also correctly built. However AH doesn't detect/run the tests and skips straight to deployment.

    Regards,
    Pete

  13. 11 Posted by Pete on 24 Oct, 2017 06:07 PM

    Pete's Avatar

    To elaborate a bit on what I'm attempting to achieve above in my web app (and likely profess my naivety with NET Core), my AH output is similar to:

    output/
    .. _PublishedWebsites/web/
    .. .. .. web.dll
    .. web.Tests.dll
    .. xunit.runner.dll

    Again, build + deploy is great, but the xunit tests aren't [detected/ran](https://support.appharbor.com/kb/getting-started/running-unit-tests-after-build). My question: Is this a known shortcoming support-wise for NET Core 2.0 or a configuration issue on my end?

  14. Support Staff 12 Posted by rune on 25 Oct, 2017 09:19 AM

    rune's Avatar

    Hi Pete,

    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.

    Best,
    Rune

Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:

»

Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac