Deploying a .net Core app


  • Garbage Person

    0_1495743511331_rps20170525_161802.jpg

    This is the traditional "your web.config is fucked, moron" error.

    Except it's not pointing at anything in the web.config as being wrong. I don't even know how to Google that.

    Fuck IIS so much.


  • FoxDev

    @Weng That can happen with any ASP.NET app, regardless of version. And yes, it's a total bitch to fix, partly as the error may be in applicationHost.config rather than web.config.


  • :belt_onion:

    @Weng said in Deploying a .net Core app:

    0_1495743511331_rps20170525_161802.jpg

    This is the traditional "your web.config is fucked, moron" error.

    Except it's not pointing at anything in the web.config as being wrong. I don't even know how to Google that.

    Fuck IIS so much.

    I particularly like the "Config source: -1: 0:" part


  • Garbage Person

    @RaceProUK
    Digging further into it, it seems the AspNetCore module isn't present.

    Despite the fact that I just fucking clicked through a goddamn MSDN page to the download that said it should have contained it.


  • Garbage Person

    Incidentally, how in the hell is "you're trying to load a module that isn't on this server" a config problem?


  • Garbage Person

    Apparently there's a separate server version of the .Net Core runtime.

    Because packaging all that shit together is way too much work thanks MS!


  • FoxDev

    @Weng All this does is further add to my opinion that .NET Core just isn't production-ready. At all.


  • Impossible Mission - B

    @Weng said in Deploying a .net Core app:

    Incidentally, how in the hell is "you're trying to load a module that isn't on this server" a config problem?

    Because it shows that your server isn't configured with all the needed modules. 🐠


  • FoxDev

    @Weng said in Deploying a .net Core app:

    Incidentally, how in the hell is "you're trying to load a module that isn't on this server" a config problem?

    because it is a configuration problem.

    it's just necessarily not your configuration problem


  • And then the murders began.

    @RaceProUK said in Deploying a .net Core app:

    @Weng All this does is further add to my opinion that .NET Core just isn't production-ready. At all.

    I'm hoping that 2.0 is the new 1.0. But I'm sure not going to bet on it, especially after the infighting over whether or not they can drop full framework support from ASP.NET Core.


  • Discourse touched me in a no-no place

    @Unperverted-Vixen said in Deploying a .net Core app:

    @RaceProUK said in Deploying a .net Core app:

    @Weng All this does is further add to my opinion that .NET Core just isn't production-ready. At all.

    I'm hoping that 2.0 is the new 1.0.

    Sounds like it is the new 0.1… 😒


  • FoxDev

    @Unperverted-Vixen said in Deploying a .net Core app:

    @RaceProUK said in Deploying a .net Core app:

    @Weng All this does is further add to my opinion that .NET Core just isn't production-ready. At all.

    I'm hoping that 2.0 is the new 1.0. But I'm sure not going to bet on it, especially after the infighting over whether or not they can drop full framework support from ASP.NET Core.

    I get the feeling that MS just doesn't know which direction to take all this Core and Standard stuff, given they seem to change their minds about it every 37 seconds.


  • Garbage Person

    @RaceProUK said in Deploying a .net Core app:

    @Weng All this does is further add to my opinion that .NET Core just isn't production-ready. At all.

    Yeah, I'm only sanctioning it's use for extremely lightweight webapi wrappers around heavyweight multiplatform third party commandline applications.

    The truly insane thing is that I have enough dependencies fitting that pattern to have actually settled on a platform and design.



  • @Weng Check scenario 3 here

    There are couples of instances that we have come across where the error code remains 0x8007000d, but the cause of issue was interesting.

    In one scenario, we had a virtual directory pointing to a UNC share content. This same above 500.19 error was caused because of wrong password specified in the “Connect as..” setting. So make sure to provide the right credentials under “Connect as..” .



  • @RaceProUK I find that .NET Standard is the one thing they're doing that does make pretty good sense. Core, not so much. If they deliver what they promised at Build, Standard will be the new PCL.


  • And then the murders began.

    @Magus said in Deploying a .net Core app:

    @RaceProUK I find that .NET Standard is the one thing they're doing that does make pretty good sense. Core, not so much. If they deliver what they promised at Build, Standard will be the new PCL.

    .NET Standard 1.0 - 1.6 were the new PCL. .NET Standard 2.0 is just going to cause frustration.

    My understanding is that since it now exposes the entire .NET 4.6.1 API, you can reference "legacy" assemblies from .NET Standard 2.0 assemblies. But when you try to use them on .NET Core, you're going to get a bunch of PlatformNotSupportedExceptions at runtime (not even at compile time!).

    Did I miss something?



  • @Unperverted-Vixen From what I understood from the presentations, Standard 2.0 is a strict subset of the Framework and Core implementations, and is meant to be compatible with 70% of the things in Nuget currently. I could be wrong about that, but that was what they were saying.


  • Dupa

    @Unperverted-Vixen said in Deploying a .net Core app:

    @Magus said in Deploying a .net Core app:

    @RaceProUK I find that .NET Standard is the one thing they're doing that does make pretty good sense. Core, not so much. If they deliver what they promised at Build, Standard will be the new PCL.

    .NET Standard 1.0 - 1.6 were the new PCL. .NET Standard 2.0 is just going to cause frustration.

    My understanding is that since it now exposes the entire .NET 4.6.1 API, you can reference "legacy" assemblies from .NET Standard 2.0 assemblies. But when you try to use them on .NET Core, you're going to get a bunch of PlatformNotSupportedExceptions at runtime (not even at compile time!).

    Did I miss something?

    Yes, you did. .NET Core 2.0 is supposed to support .NET Standard 2.0.


  • Dupa

    @kt_ said in Deploying a .net Core app:

    @Unperverted-Vixen said in Deploying a .net Core app:

    @Magus said in Deploying a .net Core app:

    @RaceProUK I find that .NET Standard is the one thing they're doing that does make pretty good sense. Core, not so much. If they deliver what they promised at Build, Standard will be the new PCL.

    .NET Standard 1.0 - 1.6 were the new PCL. .NET Standard 2.0 is just going to cause frustration.

    My understanding is that since it now exposes the entire .NET 4.6.1 API, you can reference "legacy" assemblies from .NET Standard 2.0 assemblies. But when you try to use them on .NET Core, you're going to get a bunch of PlatformNotSupportedExceptions at runtime (not even at compile time!).

    Did I miss something?

    Yes, you did. .NET Core 2.0 is supposed to support .NET Standard 2.0.

    OH shoot, I stand corrected:

    Is AppDomain part of .NET Standard?

    The AppDomain type is part of .NET Standard. Not all platforms will support the creation of new app domains, for example, .NET Core will not, so the method AppDomain.CreateDomain while being available in .NET Standard might throw PlatformNotSupportedException.

    The primary reason we expose this type in .NET Standard is because the usage is fairly high and typically not associated with creating new app domains but for interacting with the current app domain, such as registering an unhandled exception handler or asking for the application's base directory.

    From: https://github.com/dotnet/standard/blob/master/docs/faq.md


  • Dupa

    @kt_ said in Deploying a .net Core app:

    @kt_ said in Deploying a .net Core app:

    @Unperverted-Vixen said in Deploying a .net Core app:

    @Magus said in Deploying a .net Core app:

    @RaceProUK I find that .NET Standard is the one thing they're doing that does make pretty good sense. Core, not so much. If they deliver what they promised at Build, Standard will be the new PCL.

    .NET Standard 1.0 - 1.6 were the new PCL. .NET Standard 2.0 is just going to cause frustration.

    My understanding is that since it now exposes the entire .NET 4.6.1 API, you can reference "legacy" assemblies from .NET Standard 2.0 assemblies. But when you try to use them on .NET Core, you're going to get a bunch of PlatformNotSupportedExceptions at runtime (not even at compile time!).

    Did I miss something?

    Yes, you did. .NET Core 2.0 is supposed to support .NET Standard 2.0.

    OH shoot, I stand corrected:

    Is AppDomain part of .NET Standard?

    The AppDomain type is part of .NET Standard. Not all platforms will support the creation of new app domains, for example, .NET Core will not, so the method AppDomain.CreateDomain while being available in .NET Standard might throw PlatformNotSupportedException.

    The primary reason we expose this type in .NET Standard is because the usage is fairly high and typically not associated with creating new app domains but for interacting with the current app domain, such as registering an unhandled exception handler or asking for the application's base directory.

    From: https://github.com/dotnet/standard/blob/master/docs/faq.md

    On the other hand:

    Will there be tooling to highlight APIs that don't work everywhere?

    Our current focus is on providing APIs either as part of .NET Standard or as independent packages that sit on top of .NET Standard. In some cases, certain APIs will not be supported everywhere and throw PlatformNotSupportedException. While that isn't ideal, it's much simpler than the alternatives, which are:

    Using #if, also called cross-compiling
    Write complicated reflection code, also called runtime light-up
    A simple if statement with a platform check is much easier to express. Of course, there are limits to this. Exceptions are only acceptable for corner cases to avoid the complexities above. We will generally not expose large set of APIs that aren't supported.

    In the future, my hope is that we can provide tooling to help you with this, by, for example, providing Roslyn analyzers that can give you squiggles in the IDE.


Log in to reply