Core: Question: Automatic Patch Updates for .NET Core

[Jcouls29]

Automatic Patch Updates for .NET Core

This isn't really an issue so much as a question. Our group here is attempting to start moving to .NET Core for our web applications. However, IT has some concerns about patching and automatic updates to .NET Core over time. The nice thing about the .NET Framework is that new versions are installed via Windows Updates, and for them, we only have to schedule maintenance windows.

We have hundreds of servers, and the concern is that moving to .NET Core will cause a serious bottleneck on resources every time an update is required.

Are there any known mechanisms we can use with Windows 10 / Server 2016+ to get newer versions of .NET Core without human intervention. Even if it means a powershell script during maintenance windows would be better than nothing. However, I'm not sure how we would even accomplish that.

Any thoughts?

[Petermarcu]

@richlander @dleeapho

[jjxtra]

Just throwing my hat in the ring for self-contained deployment. Not sure if this is an option for you, or if your application will get deployed and updated regularly, but it could work. Now if you have dozens or hundreds of .NET core applications on each server, then this will not be size friendly until the corert linker gets fully finished and working.

[Jcouls29]

@jjxtra That's always an option. And I've tossed that around. Obviously, the size issue is concerning, but at least we can patch things. We'd have to set up a better deployment story on our end but it is possible.

Maybe I'm missing something about .NET Core. I know that 1.0, 1.1 are compatible and 2.0+ is. But let's say you have 2.0.0 installed with an application referencing it, if you install 2.0.1, will the application use it? Or does it stay with 2.0.0?

As a design decision, I thought this was the point, unlike the framework. It may be a moot point if an application sits with a version regardless of what is installed .

P.S. I am aware that certain version changes don't move (like 1.1 to 2.0). Those have to be specifically set to use.

[jjxtra]

As far as I am aware it will use highest compatible version unless you
specify an explicit version in the csproj.

-- Jeff

On Fri, Jul 13, 2018 at 8:08 AM Jcouls29 [e-mail] wrote:

@jjxtra https://github.com/jjxtra That's always an option. And I've
tossed that around. Obviously, the size issue is concerning, but at least
we can patch things. We'd have to set up a better deployment story on our
end but it is possible.

Maybe I'm missing something about .NET Core. I know that 1.0, 1.1 are
compatible and 2.0+ is. But let's say you have 2.0.0 installed with an
application referencing it, if you install 2.0.1, will the application use
it? Or does it stay with 2.0.0?

As a design decision, I thought this was the point, unlike the framework.
It may be a moot point if an application sits with a version regardless of
what is installed .

P.S. I am aware that certain version changes don't move (like 1.1 to
2.0). Those have to be specifically set to use.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/core/issues/1781#issuecomment-404844096, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABNoGNE-G3o2J_yRDCURo0eR4WyjcOJQks5uGKn1gaJpZM4VNUIk
.

[dleeapho]

@Jcouls29 have you considered containerizing your apps with Docker (in this case, using containers as a means to ease deployment and update-- not necessarily as microservices)? @richlander recently blogged about it: https://blogs.msdn.microsoft.com/dotnet/2018/06/18/staying-up-to-date-with-net-container-images/

[leecow]

@Jcouls29 - This is a topic we're definitely talking about. Today, you could do work on your side to keep monitor our release metadata file for updates. The current version is here and a draft of a major update (going live with the August release) is here. There's ample data in this file to reason pretty deeply about what an update is about.

[Jcouls29]

@dleeapho I have personally thought about docker (and did some basic prototypes for some of our software), but that's a hard sell to a small enterprise IT group. Too much of a learning curve to do it any time soon. But I will start to introduce it to get feedback. Getting them to consider .NET Core from .NET Framework 4.5 has been a hard sell up to this point...

@leecow This could work, at least from a monitoring standpoint. Will releases.json be consistently available with updates? (Meaning it doesn't move or change names over time?) If so, this might be the best option I have right now.

Thanks for the suggestions!

[leecow]

Hey @Jcouls29 , yes, this file will be regularly maintained. In fact, all of the download and Core versioning information presented on https://www.microsoft.com/net/ is driven from the current version of this file. Also, it will likely become a hub for some update monitoring features we've been thinking about.

[karelz]

Looks like the question was addressed, closing.
@leecow I assume the feature asks for automatic updates are tracked elsewhere - do you have a link that people can follow?

[leecow]

Not yet but probably in the next week or so.

[karelz]

Great. This is also related to #1541

[Jcouls29]

@leecow I have been trying to implement a custom solution to patch automatically for our IT group. However, I wanted to ask a simple question about the releases.json (actually releases-index.json). The url's presented in a number of these json files point to other files in the github repo. When these are downloaded, we will get the github html (which is expected). However, it means that using the json files in the raw is a bit difficult because they don't point to other raw resources.

Do you have any suggestions to tackle this? I'm looking into how to do this through github now, but just wanted to know if this is the intended way these should be used.

[leecow]

Hi @Jcouls29 - the 'raw' files can be found under https://raw.githubusercontent.com (for example).

However, the 'production' files will be hosted in Azure storage and that's the location you should count on. The index available at https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/releases-index.json.

I'll be writing up guidance around the jsons after the first of the year covering details such as this.

[Jcouls29]

@leecow Perfect. I'll use this location instead. I appreciate it.

[SjoerdWesterhof]

@leecow @karelz
Hi Guys. So i got the intention from @leecow answer that MS is working on some automatic update mechanism for .NET core for Patch updates. I can't find a github issue regarding this feature however.

So can i conclude for now that:

• There currently is no automatic update feature for patch versions of the .NET core SDK?
• The best ways around this is some custom parsing of the https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/releases-index.json file

And what is the best github issue for following updates on this features?

[karelz]

I think some of it is covered in #1541 - @dleeapho is driving the effort AFAIK

[leecow]

@SjoerdWesterhof - determining if, how and when to automatically update is an ongoing conversation. As you rightly note, the beginnings are detection and the releases-index.json and releases.json files are ready for use. I have prototyped a cross-plat library or using the data which @dleeapho 's team will be looking at soon-ish to hopefully make something broadly available. This would happen in the 3.0 release time frame.