3 ms·

> The deployment story is non-existent Wrong! it is as simple as executing `dotnet publish`, zipping up the output folder and sending that package somewhere us

> The deployment story is non-existent Wrong! it is as simple as executing `dotnet publish`, zipping up the output folder and sending that package somewhere using whichever protocol and shell utility you like. > monitoring, tracing, alarming is barely there Also wrong. OpenTelemetry is fully supported by first-class packages and the dotnet runtime itself exposes a lot of counters. There are a lot of tools to monitor and collect traces of running dotnet processes [1] > You have to work with MS libraries that are on life-support with glaring bugs still present You don't have to. Every Microsoft.* library follows strict semantic versioning and is clearly labeled when it is deprecated. If you don't have a plan in place on how to manage your dependencies then this is on you. [1] https://learn.microsoft.com/en-us/dotnet/core/diagnostics/tools-overview https://learn.microsoft.com/en-us/dotnet/core/diagnostics/to...

cyberax 1y ago
> Wrong! it is as simple as executing `dotnet publish` Yeah. And now add a C/C++ component there. Or maybe a neural network in Python? In my case, it was a ray tracer that used a GPU. "Just zip it", yea sure.
- mrcsharp 1y ago
  > Yeah. And now add a C/C++ component there. Or maybe a neural network in Python? How do you compile and package those components up? Answer that and you have your answer for this scenario. >"Just zip it", yea sure. I don't understand this. You can zip it. You can XCopy it. You can RSync it. Doesn't matter. What's your objection to that statement?
  - cyberax 1y ago
    > How do you compile and package those components up? Answer that and you have your answer for this scenario. I have a Dockerfile that contains the build instructions? How would I do that with MSVS? > I don't understand this. You can zip it. Yes, and then my Linux machine that runs the server will happily run a Windows application. With all the dependencies, including the GPU toolkits. But even if we stay _within_ the MS ecosystem, the "just copy it" deployment doesn't cover everything. E.g. it can't change the settings of the "App Service Logs" from within the app itself. Of course you can also use Terraform for the infra, but at this point you're way off the "just copy a folder". MSVS also supports containers, but if you do that it just becomes a UI for their configuration, not really any different from JetBrains.
    - mrcsharp 1y ago
      > I have a Dockerfile that contains the build instructions So what's stopping you from doing this with dotnet? Going by your logic, no other programming language reaches your ideal "deployment story" the moment you reach for docker. > Yes, and then my Linux machine that runs the server will happily run a Windows application. With all the dependencies, including the GPU toolkits. Dotnet is cross platform. If you are targeting Linux then you can give that information using `dotnet build --os linux` and nuget packages that have platform-specific binaries would then supply the build with the correct binary. > But even if we stay _within_ the MS ecosystem, the "just copy it" deployment doesn't cover everything. E.g. it can't change the settings of the "App Service Logs" from within the app itself. Of course you can also use Terraform for the infra, but at this point you're way off the "just copy a folder". That's because it is not the job of any programming language compiler to make changes to cloud infrastructure. You know single responsibility and all that.
      - cyberax 1y ago
        > So what's stopping you from doing this with dotnet? Nothing. But then it's not any different from JS+NPM, Python+uv, etc. > Going by your logic, no other programming language reaches your ideal "deployment story" the moment you reach for docker. Pretty much. I guess the only real contender is Go. It can easily produce single-binary self-contained executables that can contain other assets, and it supports seamless cross-compilation. > Dotnet is cross platform. If you are targeting Linux then you can give that information using `dotnet build --os linux` and nuget packages that have platform-specific binaries would then supply the build with the correct binary. Now do that with Python libraries that do the neural network thingie. > That's because it is not the job of any programming language compiler to make changes to cloud infrastructure. You know single responsibility and all that. The brag here was that Dotnet has "just copy it" deployment. And I'm showing that it's not the case, it's "click like a madman for 15 minutes to set it up and then you can copy deployments as long as they don't have anything but .NET code that can work on the target machine".

cyberax 1y ago

> Wrong! it is as simple as executing `dotnet publish` Yeah. And now add a C/C++ component there. Or maybe a neural network in Python? In my case, it was a ray tracer that used a GPU. "Just zip it", yea sure.

mrcsharp 1y ago
> Yeah. And now add a C/C++ component there. Or maybe a neural network in Python? How do you compile and package those components up? Answer that and you have your answer for this scenario. >"Just zip it", yea sure. I don't understand this. You can zip it. You can XCopy it. You can RSync it. Doesn't matter. What's your objection to that statement?
- cyberax 1y ago
  > How do you compile and package those components up? Answer that and you have your answer for this scenario. I have a Dockerfile that contains the build instructions? How would I do that with MSVS? > I don't understand this. You can zip it. Yes, and then my Linux machine that runs the server will happily run a Windows application. With all the dependencies, including the GPU toolkits. But even if we stay _within_ the MS ecosystem, the "just copy it" deployment doesn't cover everything. E.g. it can't change the settings of the "App Service Logs" from within the app itself. Of course you can also use Terraform for the infra, but at this point you're way off the "just copy a folder". MSVS also supports containers, but if you do that it just becomes a UI for their configuration, not really any different from JetBrains.
  - mrcsharp 1y ago
    > I have a Dockerfile that contains the build instructions So what's stopping you from doing this with dotnet? Going by your logic, no other programming language reaches your ideal "deployment story" the moment you reach for docker. > Yes, and then my Linux machine that runs the server will happily run a Windows application. With all the dependencies, including the GPU toolkits. Dotnet is cross platform. If you are targeting Linux then you can give that information using `dotnet build --os linux` and nuget packages that have platform-specific binaries would then supply the build with the correct binary. > But even if we stay _within_ the MS ecosystem, the "just copy it" deployment doesn't cover everything. E.g. it can't change the settings of the "App Service Logs" from within the app itself. Of course you can also use Terraform for the infra, but at this point you're way off the "just copy a folder". That's because it is not the job of any programming language compiler to make changes to cloud infrastructure. You know single responsibility and all that.
    - cyberax 1y ago
      > So what's stopping you from doing this with dotnet? Nothing. But then it's not any different from JS+NPM, Python+uv, etc. > Going by your logic, no other programming language reaches your ideal "deployment story" the moment you reach for docker. Pretty much. I guess the only real contender is Go. It can easily produce single-binary self-contained executables that can contain other assets, and it supports seamless cross-compilation. > Dotnet is cross platform. If you are targeting Linux then you can give that information using `dotnet build --os linux` and nuget packages that have platform-specific binaries would then supply the build with the correct binary. Now do that with Python libraries that do the neural network thingie. > That's because it is not the job of any programming language compiler to make changes to cloud infrastructure. You know single responsibility and all that. The brag here was that Dotnet has "just copy it" deployment. And I'm showing that it's not the case, it's "click like a madman for 15 minutes to set it up and then you can copy deployments as long as they don't have anything but .NET code that can work on the target machine".