Hacker News new | ask | show | jobs
by cm2187 3535 days ago
That's one thing I don't understand with .net core. You deploy the whole .net framework along your code which then becomes static. And this is targeted at web applications primarily.

What about security vulnerabilities? Unless the developers redeploy the application we will be left with an unpatched .net stack and unpatched web server?

How is that a good idea? In an ideal world there would be an active dev team busy redeploying and patching every day behind each website. But people who think we live in this world haven't really followed the pretty much constant stream of news about major breaches because of unpatched versions of software being used everywhere.

Or am I missing something?

3 comments

Bundling the runtime/core framework isn't required. .NET Core applications can be deployed as portable or standalone.

Portable: runtime must be installed on target machine Standalone: runtime bundled with application

Portable is how non-Core .NET apps have always been, and I believe all the templates in the Visual Studio preview tooling are setup as portable apps.

The docs have a good explanation of the differences, and how to configure a project to support either deployment strategy:

https://docs.microsoft.com/en-us/dotnet/articles/core/deploy...

My dotnet core containers are rebuilt from scratch and redeployed every 20 minutes or so. If there's a security bug in the base OS layer of my container or in the .NET runtime, I'll have it in less than a half hour.

Not too hard, if you have some standard practices in place.

I always enjoy wondering what sort of person downvotes a comment like this. I can't help but feel it's someone with shame/guilt for not having CI/CD in place.

But yeah, if that's too much to ask for, just don't ship the framework in your project. You can still have it installed as a system package. But to be frank, it's nearly the same problem, just in a different spot.

The .net framework of the OS gets updated with Windows Update automatically. It is not the same problem at all.

I obviously didn't downvote but I do understand the downvotes: it is unrealistic to expect every website to be actively maintained forever. I am sure he deploys a new version every 20 minutes of his current project. I would be curious to know how many versions a year he deploys of the projects on which he worked 5 or 7 years ago and from which he moved on.

The world is filled with legacy applications, libraries and websites. Pretending that the code we write today will always be actively maintained and supported is just unrealistic.

Probably not a good idea to update the framework without the application knowing. This could cause bugs and unspecified behavior. It's best to test your application against new versions and then deploy a new version of the app.
The .net framework is pretty much always 100% backward compatible. Again not a problem if you will have an active team maintaining the code. But can you even count how many dead applications and websites you have encountered in your career? At least if the OS gets updated, the application benefits from security patches.