I'll throw out a random number, 3 years. The ASP.NET Team doesn't own the Odata integration, the odata team does so I cant answer for them. As for SignalR, I think it would be possible to target ASP.NET Core 1.x.
The problem I see is that each person has a different set of "missing dependencies" which makes it impossible to reason about when it's even "ok" to drop .NET Framework support for everyone. It's also likely that some of those dependencies may never be ported (like CSOM).
Of course being on the 1.x train you'll get bug fixes and minor features but the bulk of the work would still be happening in the latest major of ASP.NET Core.
Also none of this prevents you from using .NET Core 2.0 or .NET Standard 2.0 with ASP.NET Core 1.x. I just want to make sure everyone is aware of that because this threads constant conflates ASP.NET Core with .NET Core (which is one of the reasons we want to target .NET Core only).

The problem I see is that each person has a different set of "missing dependencies" which makes it impossible to reason about when it's even "ok" to drop .NET Framework support for everyone.

Engage the eco system to find out what the list is (no, this issue is not the place to do it). If it's a Microsoft owned dependency, port it. If it's not, engage with the owner to inform them of the plans and assist with a migration guide (if they don't do anything, not Microsoft's fault). In the time it takes to go through this process, support ASP.net core 1.x. I can't see any other way to achieve your goals without upsetting lots of folks. This is a big thing being proposed that needs a high level of care and attention to do right.

Personally, I think there is far more confusion around .NET Framework vs .NET Standard vs .NET Core. When I saw I could target .NET Framework I never said, "but this is ASP.NET Core so why can I use .NET Framework". The distinctions between the above are far more confusing for must of your customer base. I love everything ASP.NET Core is doing. Also love the direction with .NET regarding platform independence. I just think the domain of confusion is incorrectly stated. I'd say the majority of your user base is going to have some amount of code that isn't portable due to the nature of what it is doing and the APIs it is targeting within the Framework.
My preference would be to work toward API parity within .NET Core and .NET Standard and .NET Framework. Also, figure out which is the one people should strive to target. As I believe was stated earlier, perhaps in a slightly different way, .NET Standard feels like a bandaid. Eventually, I'd expect .NET Core to be the only "framework" option and when that happens .NET Framework and .NET Standard go by the wayside. Myself, and I think with most whom have spoken up since the announcement, would like to be able to continue to benefit from the work you are doing on the ASP.NET Core side without having the freedom of what they are executing their code on top of being removed.
I think the cases being considered as exceptional, like mine where I have a dependency on things like WMI are not as exceptional as the team may think. Again, I'll do the research and see what is missing (though the post earlier giving incorrect portability results has me a little concerned over the accuracy) and I will gladly report that to you in a more private medium.
Bottom line, we're passionate about this because we want to use it.

Personally, I think there is far more confusion around .NET Framework vs .NET Standard vs .NET Core. When I saw I could target .NET Framework I never said, "but this is ASP.NET Core so why can I use .NET Framework". The distinctions between the above are far more confusing for most of your customer base. I love everything ASP.NET Core is doing. Also love the direction with .NET regarding platform independence. I just think the domain of confusion is incorrectly stated. I'd say the majority of your user base is going to have some amount of code that isn't portable due to the nature of what it is doing and the APIs it is targeting within the Framework.

We have lots of customers and we have new developers that have never seen .NET in their life. We need to cater to everyone because that's what we try to do as Microsoft. People running on .NET Framework know, love and understand it works so sure you understand that ASP.NET Core runs on .NET Framework but as a new developer approaching the platform, I would hope to never mention that as it muddies the story compared to something like go or node (which have pretty much 0 legacy at this point).

My preference would be to work toward API parity within .NET Core and .NET Standard and .NET Framework. Also, figure out which is the one people should strive to target. As I believe was stated earlier, perhaps in a slightly different way, .NET Standard feels like a bandaid. Eventually, I'd expect .NET Core to be the only "framework" option and when that happens .NET Framework and .NET Standard go by the wayside. Myself, and I think with most whom have spoken up since the announcement, would like to be able to continue to benefit from the work you are doing on the ASP.NET Core side without having the freedom of what they are executing their code on top of being removed.

These things all happen in parallel. ASP.NET Core doesn't stop working on features until "everything" is ported over to .NET Core from .NET Framework. ASP.NET will continue to innovate and take advantage of APIs that are available on .NET Core since we ship as part of the same box.

I see a few trending ideas on this thread from:

I want you to support .NET Framework forever.
I want to you support .NET Framework until the dependencies I need for my application are ported.
I just need 1 more year, that will be enough time for me to drop .NET Framework support (ASP.NET Core 3.x).

There's also the fact that we didn't write an announcement (which is our fault) but one is coming (I promise, I blame the weekend).
I also don't know what API parity looks like for most people here, my guess is it's different  for different people. .NET Framework is a 15+ year old solid, reliable, enterprise technology tied to Windows.
.NET Core was made to write modern light weight cross-platform micro services and has slowly been evolving to be more compatible so that porting libraries was easier. That said, I don't know what it means to approach .NET Framework in terms of compatibility or if that's even a goal (it wasn't originally). At some point you will not be able to use ASP.NET Core on top of .NET Framework and there will be some dependency that can't be rewritten that isn't compatible with .NET Core. Applications will need to account for that when being designed with ASP.NET Core in mind (in some near future).

With respect to the projects I work on, a much-longer period of support for 1.1 would be a decent mitigation. It's unlikely we could drop netfx dependencies in 1 year but far more likely with the +3 years you suggested as a strawman. It'd be really nice to have a release where everything comes together at the 2.0 level first though - that's the point where everything was supposed to become easier to port! I'm only speaking for one organisation but "2.0 will be a LTS release; 3.0 will drop netfx" would basically be business as usual for us instead of a cause for FUD.
I'd also like to echo what @PureKrome said about appreciating this engagement, it has been a very informative discussion.

On the topic of parity - I had previously assumed that .net core would not ever approach .net framework levels of compatibility, but that this was fine because asp.net core would continue to support both.
I think that as a community we basically use .net core in order to use asp.net core, not for its own merits. Like you said, they're one product, and I'd thought of the core clr as an optional part of that product with benefits and drawbacks if chosen.

After sleeping over it for a night -
I personally think it is a good idea to leave the old .net framework behind and write the best possible web framework for the modern runtime.
But you know that it is definitely risky and you might lose some of your customers here along the way (I hope not - but I do a lot of consulting - and .NET Core is for many companies out of reach right now - let's hope 2.0 changes that).
..and yea - communication around this was (as usual) something you can improve (most polite version of this sentence for a German) ;)

+1

I personally think it is a good idea to leave the old .net framework behind and write the best possible web framework for the modern runtime.

I agree strongly. My hope was that this wold have been a gradual change, e.g. Kestrel dropping support first for perf (http.sys based hosting remaining), then mvc/* following for API and functionality improvements while porting / compatibility testing efforts for netstandard2.0 begin.

Excellent. In that case, as long as Microsoft ensures that 1.x is supported (all kinds of bug fixes and >operational support) until it offers customers a proper 2.x migration path (e.g. SignalR), then I am >comfortable biding my time until we need asp.net core 2.

+1

able to port to .NET Core only (maybe during the development of ASP.NET Core on full framework you took some new dependencies that will never be ported as an example).

Totally agree.
Right now I think that is good decision. I think in ideal scenarios we need more than 1 year support, I dont known maybe 2-3 year, and information about what will be ported, for confidence of the community.
No .net 461 support.

@dasMulli

I agree strongly. My hope was that this wold have been a gradual change, e.g. Kestrel dropping support first for perf (http.sys based hosting remaining), then mvc/* following for API and functionality improvements while porting / compatibility testing efforts for netstandard2.0 begin.

We don't even run performance tests on .NET Framework... Porting testing and improvements to .NET Core and .NET Standard will happen anyways, that IMO has no bearing on whether .NET Framework support is dropped or not. If anything, it makes us laser focus on those scenarios because it the only target.

@gulbanana

It'd be really nice to have a release where everything comes together at the 2.0 level first though - that's the point where everything was supposed to become easier to port! I'm only speaking for one organisation but "2.0 will be a LTS release; 3.0 will drop netfx" would basically be business as usual for us instead of a cause for FUD.

Why do you need ASP.NET Core 2.0 (forget .NET Standard and .NET Core 2.0)?

We don't particularly need the features in asp.net core 2.0. I would very much like to have the simpler build processes and interop that comes with the 2.0 wave.. will asp.net core 1.1, if running on netcoreapp2.0, be able to use netstandard2.0 libraries? Would that be considered a 'standard' and supported scenario rather than something which nobody tests or pays attention to?

Basically if 1.1 became LTS I wouldn't want issues to be closed two years from now with 'well, you can do this using the 2.0 apis'..

We don't particularly need the features in asp.net core 2.0. I would very much like to have the simpler build processes and interop that comes with the 2.0 wave.. will asp.net core 1.1, if running on netcoreapp2.0, be able to use netstandard2.0 libraries? Would that be considered a 'standard' and supported scenario rather than something which nobody tests or pays attention to?

Of course that would work. As I've been saying all along the 3 things are completely decoupled today. Here's a sample project running ASP.NET Core 1.1 on .NET Core 2.0 using a version of System.Configuration APIs that have been ported to a .NET Standard 2.0 package:
https://github.com/davidfowl/AspNetCore1OnNetCore2

I'd be happier to accept this if there was an automatic interop layer between .NET Core and .NET Framework (not the current one that can throw exceptions at runtime, and not self-made internal WebAPI calls) - some kind of a wrapper ("WowNET"?) that would force us to keep 4.6-dependent code in separate .dlls but allow to run legacy at the cost of performance (which in case of LOB apps is not the main concern). Do you think this would be technically possible?
I'm also wondering if this change means that full framework itself is approaching end of life and won't perform any other significant role than being a legacy component once most APIs are moved over to .NET Standard.

Basically if 1.1 became LTS I worry about issues being closed eighteen months from now with 'well, you can do this using the 2.0 apis'..

That's always a concern. The answer is always "it depends". Bug fixes are weighed accordingly and big features are likely to fall into that bucket more often than not.

@rohatsu

I'd be happier to accept this if there was an automatic interop layer between .NET Core and .NET Framework (not the current one that can throw exceptions at runtime, and not self-made internal WebAPI calls) - some kind of a wrapper ("WowNET"?) that would force us to keep 4.6-dependent code in separate .dlls but allow to run legacy at the cost of performance (which in case of LOB apps is not the main concern). Do you think this would be technically possible?

Kinda like this https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-root but for .NET Core and .NET Framework. We did something very similar when we ASP.NET supported Helios, a .NET Framework shim that was used to boostrap coreclr. The hacks to make it work were pretty ugly though it was a mix of COM and passing structures to the Main method via string[] args. All technically feasible though. I'm not sure what sort of fidelity you'd expect, as they aren't the same runtime and you can't pass objects back and forth. You'd also be running 2 GCs, 2 Jits tons more dlls in the same process and I'm not sure what you're gaining over doing something out of proc.

I'm also wondering if this change means that full framework itself is approaching end of life and won't perform any other significant role than being a legacy component once most APIs are moved over to .NET Standard.

Far from. .NET Framework evolves and ships at the pace of windows as it is a windows component. We just released .NET Framework 4.7 (https://blogs.msdn.microsoft.com/dotnet/2017/04/05/announcing-the-net-framework-4-7/) as well with a bunch of new features. The fact is that .NET Core can and will ship faster because it isn't tied to anything else, so APIs, runtime features, etc will appear there first. It doesn't mean things won't eventually make their way to .NET Standard and .NET Framework. It'll just take longer to get there. The fact that .NET Framework updates in-place is the reason we're so careful when porting changes. Any change can break any application when an update is auto pushed to a billion machines 😉 . With .NET Core, the framework is side by side so applications need to opt in to the newer version to get newer features or fixes. There's just a lot more freedom there.

Just to weigh in with the net4x libraries we currently today in ASP.NET Core 1.x, but wouldn't work in 2.0: EntityFramework 6. EFCore just has to many missing features we use missing (for example interception). So we're stuck on EF6 for a while.
And according to @PinpointTownes 's post, EF6 does not work with the current (in development) version of ASP.NET Core 2.x.

@nphmuller then you'd keep using ASP.NET Core 1.x until more dependencies moved (I don't know how many things you require from EF Core and what the status is).

@davidfowl Sure, if the support window from ASP.NET Core 1.x does not pass during that time.
The main feature is interception. Other missing features can be worked around. Interception is in their backlog, but not tied to a release. And my gut tells me it won't be implemented for a while.

@gulbanana: I think that as a community we basically use .net core in order to use asp.net core, not for its own merits.

Speak for yourself. There are a number of us for whom the primary benefit of .NET Core is getting off of Windows on the server.

Speak for yourself, some of us aren't hippies ;P
But yes, escaping Windows (or really, IIS and http.sys) is what I want .NET Core for along side xcopy deployment, perf, etc.
Isolating old code in separate services or porting to ASP.NET Core does pay off for reasons other than new and shiny.

@PinpointTownes is a reference error, what happens if you reference System.Configuration as per https://github.com/aspnet/Home/issues/2022#issuecomment-299810945? EF6 says it has no dependencies due to everything being in ye'olde GAC/Full Framework bundle

@benaadams and @PinpointTownes the reason its failing is because System.Configuration.ConfigurationManager isn't the DLL name that .NET Framework expects. I'm not sure if the port of System.Configuration is valid.
      "system.configuration.configurationmanager/4.4.0-preview2-25308-01": {
        "dependencies": {
          "System.Security.Cryptography.ProtectedData": "4.4.0-preview2-25308-01"
        },
        "runtime": {
          "lib/netstandard2.0/System.Configuration.ConfigurationManager.dll": {}
        },
        "compile": {
          "ref/netstandard2.0/System.Configuration.ConfigurationManager.dll": {}
        }

Well mono 5 will run both netcoreapp* and net* apps and works on windows, so.. 😄

yes, being able to run non-windows servers is great and a big draw.. but without asp.net core what would you run on them?
even Nancy relies on asp.net core via kestrel, UseOwin(), etc.

I've created several microservices that don't use ASP.NET Core.  They're stuff like worker processes that poll a queue to do it's work.

This is not fair, we follow roadmaps, and you didn't say anything about that before !!
If you said that before, we will not use ASP.NET Core in our project because we need .NET 4.x Libs.
Our planning includes updating our projects to ASP.NET Core 2 because of needed new functionalities.
We need ASP.NET Core 2 to target .NET 4.x too. if not possible, what about the support of ASP.NET Core 1.x, are you planning to add all new functionalities to it too or just fixing bugs.

Our planning includes updating our projects to ASP.NET Core 2 because of needed new functionalities.

Which ones?

@PinpointTownes is a reference error, what happens if you reference System.Configuration as per #2022 (comment)?

Adding <Reference Include="System.Configuration" /> has no effect (i.e the same exception is thrown), as it seems it can't be resolved from the GAC (not sure it's really surprising, tho'):

I'm not sure if the port of System.Configuration is valid.

So the official conclusion is... you can't use a library written for .NET Framework 4.x on .NET Core if it uses System.Configuration?

@PinpointTownes I'm not even sure that version of System.Configuration is shipping (the one in the package). Maybe it is, maybe it isn't (that's a discussion to start on corefx). I'm just telling you why your sample broke the way it did.

Adding  has no effect (i.e the same exception is thrown), as it seems it can't be resolved from the GAC (not sure it's really surprising, tho'):

AFAIK, there's no default support for the GAC in SDK projects. See https://github.com/dotnet/sdk/issues/987#issuecomment-286307697 to see how to enable it.

So the official conclusion is... you can't use a library written for .NET Framework 4.x on .NET Core if it uses System.Configuration?

My conclusion is that you should open an issue on CoreFX with the sample your provided above.

@davidfowl
Some needed features and helpers on EF Core are planned in 2.0 especially for mapping data (Self-contained type mappings)...
Anyway, I need just to have an clear idea about the roadmap of ASP.NET Core 1.x, our team is confused and worried.

One thing I'm personally struggling with is the "stable platform" vs "new features" thing. On one hand, we want the platform to be stable and reliable and compatible, on the other hand nobody wants to stay on 1.x because it's doesn't have 2.x features. Are there super compelling features in ASP.NET Core 2.x that are pulling people in that direction or is it just the fact that we have more features than we had in 1.x (because it's new and shiny)?

@davidfowl I do think signlarR is one such feature, it would have been in my previous project atleast. However I also think a lot of the concern is due to the relatively short support windows for 1.1 (2018?) if people were assured they could run on asp.net 1.1 until they are ready to switch to core, meaning potentially, years,  and also be covered for patches that would calm people down a bit

I've been following this since the first day and even after all of these discussion and clarifications ( thanks @davidfowl ) I feel a lot of us are being thrown under the bus.
I understand the reasoning for cutting loose from Full/desktop .NET framework. Hell, I even agree that's the way to empower ASP.NET, BUT I fail to see how this is being decided now instead of from the beginning.
Of course we customers would seriously complain in both scenarios, but I'd rather be in the "I can't use the new shiny thing" than bet on "I can use it, invest in slowly migrate and replace when possible" and just find out that's false.

I fail to see how this is being decided now instead of from the beginning.

At a guess:
On .NET Core 1.x you couldn't run Full framework libraries, so it would have been a complete break.
On .NET Core 2.x you can mostly run Full framework and can run .NET Standard 1.x - 2.0 libraries, so it isn't a major break.
Any issues with running Full framework libraries on .NET Core 2.0, should probably be filed in dotnet/corefx

It's clear that the main scenario is "modern web apps on the cloud", which often don't have many third party dependencies ( or are "just code" ones ).
Most of the discussion so far has been focused on BCL availability, but many of us depend on third party components( low level Video, Audio... ) that are often lagging on the .NET landscape and almost always rely on lower level technologies that probably don't end up being supported.
With ASP.NET Core 1, we are developing our modern services, targeting .NET standard for Libs and choosing to deploy on Full .NET or .NET Core per services dependencies.
I could bet on this because in the case of finding unsupported features/components, we could easily target Full .NET. And the bet was on the long term platform, as staying on Full .NET looks like a decision to avoid in a few years.

On .NET Core 2.x you can mostly run Full framework and can run .NET Standard 1.x - 2.0 libraries, so it isn't a major break.
@benaadams  There is a big difference between being able to use most of the BCL and being able to use libraries that have been built for Full .NET ( and internally could use unsupported features in .NET Standard 2.0 / type unification).

I guess this decision has no impact on easing the migration to ASP.NET Core 2.0 from ASP.NET 4?
Quite a few applications I manage could really profit from an update to ASP.NET Core 2.0, but since there is no OWIN/Katana Support for ASP.NET Core I guess I need to migrate manually and that is atm too much work. @damianh suggested similar in https://github.com/aspnet/AspNetKatana/issues/27

We are running on the full framework because we need EF6 (for spatial) and directory services and we are waiting on SignalR proper (currently using an unsupported version but it works). I havent checked any other blockers in a while but probably there are more.
As i understand it we'll now be blocked from moving to asp.net core 2.0 and getting signalr when it comes out.
We've been along for the ride since dnx, RC1 to RC2 and project json to csproj and finally it felt like we were out of the woods... now not so much.
I can understand this change coming eventually but is this really the time to do it when asp.net core is trying to gain traction? Also, my gut tells me EF Core isnt mature enough yet (and certainly not for spatial) and anyone betting on support in core is taking on more risk with regards to porting of libs.... waiting out another version for this transition seems like it would give some stability and a chance for EF Core and other ports to catch up not to mention signal r on the full framework.
I bet most of the enterprise is running asp.net core (which is great by the way) on the full framework and could well be in a similar position to us.

Given this move to the fast train for ASP.NET Core, does that mean you'll introduce an LTS and Current version, and what will the support length be on this instances?
I guess I'm in the lucky instance where I am working on a greenfield solution that has had no requirements to run on netfx, but it was always a nice to have if it could. The only thing that would be a blocker for me would be windows services which I am targeting netfx, but there is a plan for that.

I feel this change is going in the wrong direction. I understand some features are core exclusive until netstandard catches up. But going this core-only route is a slippery slope into creating a fractured ecosystem.
This change makes a statement that I'm not sure I like: It's OK to only target netcoreapp.

I also wanted to write my opinion.
I believe that it's too early to drop .net framework. I don't know what's the problem of supporting .net framework + .net core together, but I believe this decision will make to migrate to AspNet Core a little harder. Because some companies think that: "Let's start AspNet Core with .net core.. if we have serious problems (like a must-need library does not support it in the future) we can always turn back to .net framework". But now that will not be possible anymore and companies will hesitate to start with AspNet Core. Also, this decision may make lower the value of .netstandard.

@hikalkan

Because some companies think that: "Let's start AspNet Core with .net core.. if we have serious problems (like a must-need library does not support it in the future) we can always turn back to .net framework".

You can always use ASP.NET Core 1.1 though right?

Also, this decision may make lower the value of .netstandard.

I don't see why that would be the case. As I said before, our cross cutting libraries still target .NET Core as well as APIs that need to work across all of the .NET implementations.

Sure, they can use asp.net core 1.1. But it's not nice to say: "ASP.NET Core's latest version is 2.x but you should use ASP.NET Core 1.x if you want to target .net framework". That's not much different than saying "use MVC 5.x" :)
I believe .net core is the future (not future, even it's now!), but it's eary to drop .net framework (this decision will be understood by the community like .net framework is being obsolete).

You can always use ASP.NET Core 1.1 though right?
there is not a clear benefit. First it is not mature yet, so it is a bet.
Second, developers in ASP.Net Core  will not want to write in old tools and stay behind.
I am interested about few things.

We work already in greenfield project  fully in ASP.Net Core, Dapper, etc.
But in other projects, our business logic is in 4.6 assemblies. As I did read above, we should not have problem to reference them. I hope, I understood well about.
SignalR . DirectoryServices,  MS Orleans, Azure.
maybe irrelevant with the conversation above, but I want madly to host locally an ASP.Net Core with Kestrel or other HttpListener  as a UWP desktop application or  as  desktop bridge in UWP.

Gotta say I'm pretty disappointed on the communication on this. I think we can live with the decision but it came out of no-where.
In July my team is starting work on a greenfield 12-18 month project that's going to run on ASP.NET Core 2.0 only with all the cool stuff that we've been reading about for years in .NET Core.
However in the mean-time we've got a ASP.NET MVC Core 1.0 app that is the center of our legacy product that essentially serves as a wrapper to call .NET Framework libraries.
We had two plans for the legacy app that we were working on:

Keep the app as is for the next two years but swap out the .NET Framework libraries with their .NET Core equivalent when done. This would keep our business logic etc shared between the two apps.
We can't do this as July 2018 is the deadline for ASP.NET MVC Core 1.0 support.

Upgrade the app to ASP.NET MVC Core 2.0 and have it become part of the new app as we swap out the .NET Framework components.
We can't do this either, as Core 2.0 doesn't support the .NET Framework so it's all or nothing.

Just before I run my opinion, I would just like clarity on one part.
Would I be correct in making the assumption that if we want to continue using ASP.NET Core,
we will not be able to reference dll's that target .Net 4.5 or greater and have them work as they currently do?

@louislewis2 No, that's not correct. You will be able to use net45-net461 libraries, so long as they stay within the supported API space for netstandard2.0. You will not need to recompile those libraries.

@bradwilson Thanks for the clarification. That will surely make me sleep better tonight.
Many of the libraries are not in our control, so that would have been a huge issue.
Very relieved now :)

@shanselman @DamianEdwards @davidfowl  For your list of items that we use which have not yet been ported, would be items in the system.management dll. We make use of the hardware identifiers specifically , this is used for automatic link generation for Azure Service Bus and our entire licensing server and client package. I imagine that with them not being the api currently, would cause us some serious issues?
https://github.com/dotnet/corefx/issues/3324
https://github.com/dotnet/corefx/issues/14762
This is our biggest holdup that keeps us running a few of our apps on the full framework.

This puts us in an awkward situation.
I'm in the middle of porting our microservices from ASP.Net 4.5 self-hosted in-process on top of Kestrel (legacy compat reasons), to full self-hosted ASP.Net Core 1.x. However, we need to run these things on full framework, for now. And there are good reasons for that.
We have a number of hard Windows dependencies that are already part of our infrastructure and aren't subject to change. That includes NTLM auth, Event Log logging, etc. If ASP.Net Core 2.x are bailing out of netstandard support, then I may as well not do it at all. The problem is, there isn't any actively developed full framework alternative. Katana is dead and slow (by comparison).
If somebody could point me to a HTTP server that's as fast as Kestrel for .Net Framework, then sure. But that doesn't exist. So I just have to accept that ASP.Net is leaving actual production customers like me behind with this change.
If the stack needs all the new goodies, like Pipelines and Span, then those should be provided as netstandard libs. What APIs is ASP.Net Core 2.x using that are in netcoreapp2.0 that aren't in netstandard2.0, and why can't those APIs be made netstandard2.0 libs?

Are we seriously saying that MS spent 2 years working on a (net) standard across all of their frameworks only to turn around and release a flagship product that doesn't use this standard?

I think that GitHub Team will add Pagination feature for issues section because of this issue.

I'm in the middle of porting our microservices from ASP.Net 4.5 self-hosted in-process on top of Kestrel (legacy compat reasons), to full self-hosted ASP.Net Core 1.x. However, we need to run these things on full framework, for now. And there are good reasons for that.

You can keep using ASP.NET Core 1.x right?

If the stack needs all the new goodies, like Pipelines and Span, then those should be provided as netstandard libs. What APIs is ASP.Net Core 2.x using that are in netcoreapp2.0 that aren't in netstandard2.0, and why can't those APIs be made netstandard2.0 extension libs in the meantime?

When APIs appear in .NET Standard that aren't in .NET Framework how are you going to use them?

@stefan2410
You can use ASP.NET Core 1.x for that right? Which ASP.NET Core 2.0 features do you need? Is it just SignalR?

Keep the app as is for the next two years but swap out the .NET Framework libraries with their .NET Core equivalent when done. This would keep our business logic etc shared between the two apps.
We can't do this as July 2018 is the deadline for ASP.NET MVC Core 1.0 support.

Once again, in my hypothetical world, we extend the lifetime of 1.x

When APIs appear in .NET Standard that aren't in .NET Framework how are you going to use them?

Our plan was: wait until they are in it. You said earlier that's just a matter of time, right? Lagging the bleeding edge by some fixed amount for the sake of stability would've been fine. Much better than falling permanently behind, at least.

@davidfowl
I will move in ASP.Net core 2.0.  I don't have other solution. I can't say to the team to stay behind the evolution, we waited long time the ASP.Net Core.
As far as we don't have problems with 4.6 assemblies references.
I need SignalR,  DirectoryServices, not problems with Azure/Amazon libraries, MS Orleans. RabbitMQ.
Also maybe it is irrelevant with the conversation above, but I want for a desktop app to host locally an ASP.Net Core with Kestrel / HttpListener as a UWP desktop application or as desktop bridge in UWP.
We can't rewrite the code for  XAML   and I would not like to use Electron.

You can keep using ASP.NET Core 1.x right?

For what timeframe? I can't see something like Event Log making it to netstandard.

When APIs appear in .NET Standard that aren't in .NET Framework how are you going to use them?

Is this a thing? netstandard20 appears to still run on net461 according to the docs. Are you saying that the API under netstandard20 is not complete enough to implement the new goodies? Or, is there some plan to move netstandard beyond framework that is not yet divulged?

Our plan was: wait until they are in it. You said earlier that's just a matter of time, right? Lagging the bleeding edge by some fixed amount for the sake of stability would've been fine. Much better than falling permanently behind, at least.

Libraries can be written on top of the standard. When things in the standard itself need to change it will take a lot longer to be adopted in all implementations of .NET and that includes .NET Framework. It can mean a couple of things:

.NET Standard will evolve at the rate of the slowest implementation
.NET Standard will evolve at some other pace and .NET Framework will be the last to catch up.

Of course it doesn't mean that libraries can't be written against it, it just means those caveats need to be taken into consideration when picking the version of .NET Standard you want to support.

Also maybe it is irrelevant with the conversation above, but I want for a desktop app to host locally an ASP.Net Core with Kestrel / HttpListener as a UWP desktop application or as desktop bridge in UWP.

ASP.NET Core on UWP isn't currently on any roadmap so I can't really say what's going to happen here. HttpListener is part of .NET Standard 2.0 though so maybe there's a chance that will work.

I want to take a moment to thank everybody for their comments and feedback here. We really do appreciate it as well as your patience while we figure out the path forward. Please know that we didn't intend for this change to be so hard, so late, and without warning. Hindsight is 20/20 and if we knew what we knew now we would have communicated things earlier. We'll try harder moving forward.
We have a plan based on the feedback we've received here that I want to share with you before we post it as an announcement later this week with the 2.0.0-preview1 release. When that happens, we'll open a new issue to facilitate discussion around that plan, but for now go ahead and continue to share your thoughts and feedback here:

Support for ASP.NET Core 1.x on .NET Framework will be extended for at least another year (until July 2019). We will reassess this annually and commit to providing 12 months notice before ending support of ASP.NET Core 1.x (so by July 2018 we’d announce whether we’re extending for another 12 months to July 2020) (Side note: is anybody else freaked out by the fact we're talking about 2020 already? No? Ok, just me.)
The new SignalR will target and be fully supported on ASP.NET Core 1.x (coming later this year)
We’ll continue to update ASP.NET Core 1.x to support new language versions, etc. like we do for System.Web
ASP.NET Core 1.x running on .NET Core 1.x will be supported until July 2018 (no change)
ASP.NET Core 1.x running on .NET Core 2+ will be supported as long as ASP.NET Core 1.x on .NET Framework is supported

This is to ensure there is always an overlap of a supported ASP.NET Core on a supported .NET Core while we support running on .NET Framework, allowing customers to port over time while staying on supported bits

.NET Core 1.x support (as a runtime) doesn’t change. Ends in July 2018. Customers running ASP.NET Core 1.x need to move to .NET Core 2.0 or be on .NET Framework at that point (or move to ASP.NET Core 2.0 on .NET Core 2.0)
We will port System.DirectoryServices and System.Drawing to .NET Core this year (fully supported, cross-platform, preview for at least Windows in Summer)
The list of things to port to .NET Core after that currently includes ServiceBase (to support .NET Core Windows Services). No timeline yet other than it’s next (timelines obviously get more concrete as we work down the list). We’ll build on this list as we go based on customer feedback.
We have no plan currently to port System.ServiceModel (server-side WCF) to .NET Core. The WCF for .NET Core may continue to be enhanced and have features added based on feedback, e.g. HTTP message encryption.

@DamianEdwards @davidfowl a large part of the issue is that it can takes months of planning and dev effort whilst sacrificing a huge opportunity cost to commit to moving to ASP.NET Core where a lot of organizations wont to be able to move off from on .NET 4.x as it's the only platform they can be assured will be able to run all of their systems dependencies.
Up to this point MS has been marketing .NET Core aggressively as the future of ASP.NET where it's unclear whether development of ASP.NET 4.x has halted and if all future dev efforts are going to be invested in ASP.NET Core so there are going to be a lot of migrations underway to keep their systems current. A lot of people are going to feel like they've been thrown under a bus if that at the end result of all their efforts they've effectively migrated to an EOL'ed platform. This will hurt both organizations as well as the devs/consultants that were the biggest champions for initiating the move to .NET Core. They may not need anything from ASP.NET Core 2.0 now but they're definitely going to want have some headroom for their systems and be able to access some new features for all their efforts.
I also don't get why existing "legacy" code is considered a liability when IMO it should be considered one of .NET's greatest assets, .NET Core would be nowhere near as appealing if it wasn't able to run existing .NET libraries. Java is still so strong because of JVM's massive and ecosystem which is more important than the inherent weakness in the language itself.
I don't think MS has even begun to feel the backlash from dropping .NET 4.x support which wont be broadly known until it's announced, I'd expect most devs here actively following development on GitHub are more interested in seeing new features then they are in interoperability and ensuring there's a smooth migration path for their existing code bases. I'd be surprised, but if you don't get any heat from this decision after it's announced than it might be the right one as maybe there aren't going to be that many people hurt by it.
Would it be too much effort to focus on a ASP.NET Core 2.0 stable/compatible release, then announce the .NET Core-only future for subsequent versions? Just seems like it's the fair thing to do in this situation given it was completely unforeseen.

@DamianEdwards thanks for the update and a clear plan. I don't agree with it, but I still appreciate you laying it out.
There's still a huge fundamental gap here. The port to 1.x is almost entirely a lateral one, there are few features in it for us. 2.x is where some worthwhile upgrades are and we still have no guarantee we can ever make that move. There's a large chance that we spend a significant amount of time, money, and effort porting to 1.x only to be stranded there because of full framework dependencies. I will not make that gamble with our company. We may well end up with less support than we have on ASP.NET 4.x now.
Unless that changes, our apps will not be making the trip to ASP.NET Core, and all of our libraries will be far worse off for lack of dogfooding on it.
I sincerely hope you reconsider this decision. I hope one day we can make Stack Overflow take advantage of the thousands of personal hours we have devoted to help develop the .NET Core platform.

@NickCraver

There's a large chance that we spend a significant amount of time, money, and effort porting to 1.x only to be stranded there because of full framework dependencies.

Throughout this thread, you called out System.DirectoryServices as one of the core things. I assume  you have some dependencies that you think will take a long time to get ported or ones that will never get ported. If 2.0 supported .NET Framework would those dependencies move in a year?

2.x is where some worthwhile upgrades are and we still have no guarantee we can ever make that move.

Which ones? It would be good to know because we were discussing back porting some high importance things back to ASP.NET Core 1.1 to ease the transition.

Unless that changes, our apps will not be making the trip to ASP.NET Core, and all of our libraries will be far worse off for lack of dogfooding on it.

I don't know anything about stackoverflow.com but is it possible to break pieces off (I don't want to say "micro services") so that ASP.NET Core could be used for some parts?

@mythz

This will hurt both organizations as well as the devs/consultants that were the biggest champions for initiating the move to .NET Core

Did you mean ASP.NET Core? Or .NET Core?

@davidfowl I meant ASP.NET Core, but it also affects devs who plan on a staged migration from ASP.NET Core .NET 4.x first then .NET Core later.

Speaking of which, I've noticed that there's no libraries on ASP.NET Core/.NET Core for handling SAML. I have a requirement to handle SSO via a third party IdP, but I don't know if that'll be possible.

@davidfowl I meant ASP.NET Core, but it also affects devs who plan on a staged migration from ASP.NET Core .NET 4.x first then .NET Core later.

I don't see why that would be the case.

I think that plan would probably be juuust enough for my org to avoid moving off the platform. The main thing is having a longer period with support (=security patches) during which remaining netfx deps can be rewritten or otherwise eliminated. It's all still kind of dicey and conceptually weird, though. What happens if three years from now we want to build a website which can ingest Excel documents or to embed a webserver in an app? What happens to other frameworks like Orleans building on top of the standard instead of netcoreapp?
I seriously do not understand why so much work was done on netstandard2.0 if it wasn't ever going to be good enough for ASP.NET Core to actually use it.

What happens if three years from now we want to build a website which can ingest Excel documents

Hard to say. I can't speak for the teams that own that but maybe it'll get ported to .NET Core and will work cross platform.

or to embed a webserver in an app?

HttpListener is part of netstandard 2.0.

What happens to other frameworks like Orleans building on top of the standard instead of netcoreapp?

It's up to frameworks to decide if they want to run on .NET Framework, UWP, .NET Core, mono etc. It's a choice. Orleans doesn't ship with .NET Core. ASP.NET Core does. Those products are one and the same.

What'll be a tough decision for us (and our clients) isn't about the libraries I have today, but the libraries I don't know if I'll need 6 months from now. There's a long tail of libraries and frameworks that don't support netstandard yet. For example, a month in to a project we realized that we needed a few features in NHibernate that weren't even close to there in EF6, let alone EF Core. So what would be my option there - target ASP.NET Core 1.x on full .NET?
Looks like I have some ApiPort in my future.

So what would be my option there - target ASP.NET Core 1.x on full .NET?

Yes.

Hard to say. I can't speak for the teams that own that but maybe it'll get ported to .NET Core and will work cross platform.

Right, but surely it's within the purview of the asp.net team to decide whether it's worth providing access to that ecosystem of maybe-not-ported libraries.

Right, but surely it's within the purview of the asp.net team to decide whether it's worth providing access to that ecosystem of maybe-not-ported libraries.

.NET is big and old, there's no way you can expect the ASP.NET team to speak to the breath of libraries that exist in the .NET ecosystem. It's unrealistic. I just learnt what CSOM (https://msdn.microsoft.com/en-us/library/office/jj163123.aspx) was as part of this thread and I doubt it'll be ported but I couldn't say that for sure.
Extending support for ASP.NET 1.1 on .NET Framework helps mitigate this a bit but I think it also helps because dependencies need to be isolated to properly move to ASP.NET Core on .NET Core (which is the intended future).

I will leave aside the libraries aside as that point has been discussed at length already. In our case the third party tooling is already a showstopper, we can't even run ASP.NET Core on the full framework at the time being. I acknowledge this doesn't sound like a legitimate reason, but its a constraint we have to deal with.
We could, in theory, replace those tools (i.e. profilers, monitoring, build servers, etc) with alternatives supporting .NET Core but that's a couple months of work I'd rather spend on solving more pressing issues. We'll make the migration eventually to .NET Core, but right now it's quite a moving target.

Up until this point the expectation was created that ASP.NET Core would be able to keep running on desktop framework, and thus speak to the breadth of etc etc. I don't know what kind of tea leaves we were supposed to read to know that that was unrealistic :/

.NET is big and old, there's no way you can expect the ASP.NET team to speak to the breath of libraries that exist in the .NET ecosystem. It's unrealistic

Isn't that a good reason to keep supporting .NET 4.x? The burden of compatibility/interoperability can be contained to .NET 4.x platform which can be a working solution that could relieve .NET Core from needing to interoperate with older libs and relieve pressure to port existing popular .NET libraries to .NET Core (for MS and external authors).

@mythz

Isn't that a good reason to keep supporting .NET 4.x? The burden of compatibility/interoperability can be contained to .NET 4.x platform which can be a working solution that could relieve .NET Core from needing to interoperate with older libs and relieve pressure to port existing popular .NET libraries to .NET Core (for MS and external authors).

That's why  ASP.NET Core on 1.1 's lifetime has been extended (though not permanently). We're going to make sure that SignalR works because that was stated as one major reason for using ASP.NET Core 2.0. At the same time, it's not where ASP.NET Core wants to be in the long run. The intent was always to ship as part of a unified .NET Core platform.
@gulbanana

Up until this point the expectation was created that ASP.NET Core would be able to keep running on desktop framework, and thus speak to the breadth of etc etc. I don't know what kind of tea leaves we were supposed to read to know that that was unrealistic :/

ASP.NET Core on .NET Framework was unfortunately never communicated as a stop gap solution to ease porting (that's something we messaged very poorly). It was never intended to as a supported platform forever which is the logical conclusion if you were to assume that some dependencies will just never be ported.

That's why ASP.NET Core on 1.1 's lifetime has been extended (though not permanently).

The issue is whether or not that's enough, the current version has basically been EOL'ed before a compatible/stable release has even been delivered.
I don't believe the value of existing investments is being considered, who is going to want to go through all the effort to migrate to an EOL platform? Devs will be working on their existing brownfield systems indefinitely, they're basically being told their current ASP.NET v4.x skills are going to become obsolete and they're not able to migrate to the new ASP.NET Core development model because .NET 4.x support is being dropped and it would be irresponsible for them to consider or recommend migrating to a dead-end platform.

@davidfowl

ASP.NET Core on .NET Framework was unfortunately never communicated as a stop gap solution to ease porting (that's something we messaged very poorly). It was never intended to as a supported platform forever which is the logical conclusion if you were to assume that some dependencies will just never be ported.

Mistakes happen, that's fine. The problem now is that many people made this assumption and so are only using ASP.NET Core because of their logical but erroneous conclusion. We'll see just how many, I guess :/

I waiting asp.net core 2/ .net core 2 so long, but the result is so depressed.

@mythz

I don't believe the value of existing investments is being considered, who is going to want to go through all the effort to migrate to an EOL platform?

Can't the same argument be made about ASP.NET Core 2.0 being EOL on .NET Framework next year when 3.0 comes out? If you're saying a year isn't enough on ASP.NET Core 1.1 why would you suggest a year is ok on ASP.NET Core 2.0?

Devs will be working on their existing brownfield systems indefinitely, they're basically being told their current ASP.NET v4.x skills are going to become obsolete and they're not able to migrate to the new ASP.NET Core development model because .NET 4.x support is being dropped and it would be irresponsible for them to consider or recommend migrating to a dead-end platform.

Who got told that ASP.NET 4.x skills are going to become obsolete? If anything we're hoping they aren't. MVC in particular touts concept compatibility with a few new features. ASP.NET Core looks alot like katana (and that's not by mistake). If you're talking about webforms then what about MVC ?
I don't have any experience consulting but I would agree that if the dependencies aren't available then I would agree. Either that or the application needs to be re-designed to take this into account.

@xyting can you clarify?

@davidfowl

Can't the same argument be made about ASP.NET Core 2.0 being EOL on .NET Framework next year when 3.0 comes out? If you're saying a year isn't enough on ASP.NET Core 1.1 why would you suggest a year is ok on ASP.NET Core 2.0?

I was under the long-time assumption that ASP.NET Core 1.1 was just a stop-gap solution to ASP.NET Core 2.0 and .NET Standard 2.0 which would be the compatibility focused and stable LTS release that will bridge the gap with most of the core functionality missing from .NET 4.x - up until this thread basically destroyed that assumption. Keeping .NET 4.x compatibility up to ASP.NET Core 2.0 isn't ideal, but it's a lot better than terminating it at the current release which no-one expected.

Who got told that ASP.NET 4.x skills are going to become obsolete? If anything we're hoping they aren't.

MS does with all their aggressive marketing on .NET Core with all new announcements and features seemingly being ASP.NET Core focused. Is old ASP.NET WebForms/MVC even being developed in the open? What proportion of dev effort is being invested on old ASP.NET WebForms/MVC vs .NET Core? I've no idea, everything I've seen recently, all weekly standups, video tutorials seems solely focused on ASP.NET Core. I know I definitely wouldn't feel comfortable starting new greenfield projects using old ASP.NET WebForms or MVC technology.
If you're hoping they aren't MS should definitely communicate that better with clear roadmaps. Given how volatile ASP.NET has been in the last few years (this issue being a perfect example), it's impossible to know what the future is without an official commitment and announcement.

Does anyone else feel that it would have been better if version 1 never ran on full framework? I didn't expect it to because of the naming. Now that it does and I've had a taste I'm disappointed to lose it.
I do get where you're coming from on this, you want to iterate the whole stack as fast as possible. You're competing with a whole bunch of green fields web frameworks that control the whole stack and have no baggage to drag along. Hell dropping the baggage of System.Web is one of the main reasons ASP.NET Core is so exciting.
Having slept on it I can say our usage will be fine, the dependencies we need should all work on 2.0.

At the same time, it's not where ASP.NET Core wants to be in the long run. The intent was always to ship as part of a unified .NET Core platform.

While it doesn't take a psychic to figure out that .NET Core is the platform of .NET's future... if the intent from the beginning (or as you put it "always") was to couple ASP.NET Core with .NET core, that was definitely not communicated in any medium I've ever seen.
I've literally seen every single minute of every single ASP.NET standup (including Hanselman and Glenn troubleshooting Docker for 3 hours... because I have no life), I read the blogs, I'm always on Twitter, I go to 2+ conferences a year, attend user groups, etc. and I've never once heard that communicated as the intent of ASP.NET Core.  Instead, I've heard over and over and over "it runs on both platforms" and, rightfully, people feel like someone pulled the chair out from under them.  I've even given talks about ASP.NET Core and said that myself, and now I feel guilty for anyone I've led down this path.  I would say the people ITT are likely to be on the bleeding edge and would be the most accepting of this kind of news, and there's a lot of backlash here.  This seems like it's only going to get worse as this news trickles down to the developers and their managers who aren't as plugged in, and are likely more conservative than those ITT.
Besides the lack of communication and the lack of support for some scenarios, I think a lot of the backlash is just due to the timing of this announcement.  .NET Core 2 isn't even RTM'd yet and it's already been deemed the only long term path forward, and there's essentially been a ticking time bomb put on Full Framework for ASP.NET Core.  I think a lot of our fears could be cleared up once we have something tangible to play with besides nightlies.
I really do think there needs to be a better tooling experience than "run it and see if it works" when referencing net461+ libs from .NET Core 2+ in VS, because I can already see that message of "we can likely run most of your 461+ assemblies too!" will be marketed to death.  Something that could analyze missing API's of what we referenced, providing compile-time errors, ideally even suggesting compat nupkgs if they exist (like System.Configuration in the EF6 example above... and have it work :smile:).  Obviously, not everything can be analyzed at compile time (the distributed transaction scenario mentioned above comes to mind as something tough to anlayze ahead of time), but the more that can the better.  Something kind of like what Immo did here for PlatformNotSupportedException and the missing net461 APIs for netstandard2 would be nice.
Just my 2 cents.  I hope I'm just overreacting.  Ultimately, a lot of us are just disappointed, because we love ASP.NET Core, and we don't want anything standing in our way of using it. ❤

Joining my voice to the concerns already listed, we are starting  a new ASP.NET MVC project next month and it  will be plain .NET Framework with  ASP.NET MVC, because the customer doesn't trust Microsoft doing the right thing in regards to long term planning.
The customer organization is still using Windows 7 deployments and this project is an exception, because the majority of their web projects is actually done on UNIX with Java, with .NET being mostly used on desktop applications.
This type of uncertainty just piles up to the broken history that Windows 8 .NET stack and UWP were, increasing the interest of the organization CTO to look for more stable alternatives to .NET future.
If you are forcing these type of organizations to write modules from scratch to work on ASP.NET Core, I can as well advise our customers to adopt something with more stable roadmaps,instead of losing face about issues I cannot control.

@davidfowl It might be that this change will workout fine for 99% of the projects. But it was sold as "it runs on both platforms" and "you can use it with full framework if you have too". Everyone knew that the full framework version of asp.net core was for the projects that could't migrate, and that was fine. And people planned with that in mind.
 And it will not be about the code, it will about what was promised. And the promise was "run net or core, and netstandard to combine them all".

@DamianEdwards @davidfowl Thanks for sharing the plan.
SignalR on 1.x is a big relief to replace our unsupported version and also the news that ServiceBase is next on the list next as we are currently using that also!
We are heavily reliant on EF6 and spatial though so we'll be stuck on 1.x until that has the feature set we need....
On a semi-amusing side note however, this may finally force a more microservice deployment for this. I wont be looking forward to explaining why our LOB customers need to have several more api's installed on IIS to just to get our products working though....
I really wish this could be held back as just seems to be too soon and as several people have mentioned this will generate a significant backlash when the blog post drops.
Also i must say i feel a bit sold-down-the-river when from the start the sentiment has been this will run on the full framework and have been preaching the same thing to colleagues. Explains the confusing naming choice of asp.net core though.

@shanselman @davidfowl My biggest pain point is NHibernate. Even after the EF Core release, it's still the only most advanced full featured O/R mapper.

@shanselman @DamianEdwards I am in the process starting to think about upgrading a site from ASP.NET MVC 4 to  whatever the latest version is (I'm confused whether it's 5 or one).  I still need to run the full .net framework because I am referencing both SyncFusion and Telerik libraries. SyncFusion to display PDF files and Telerik to generate word .docx files.  As others have pointed out it's simply not reasonable for Microsoft's  strategy for dealing with this to be "try it and see if it works".  I can't guarantee that and production everything is going to work because it is such a large code base of third-party code.
While SyncFusion support is generally very good Telerik's support is not and I'd be surprised if they can make it work with .net core.  I have no idea what Apis they might be using that are not supported in .net core - and as an end user that's the whole point of the third-party product, I just plug it in and it does what it needs to do.
Frankly for a customer who doesn't deal in the stuff very frequently (I mostly do WPF) this is all extraordinarily confusing. There are too many different versions, with various incompatibilities. As someone has pointed out it's a bit like UWP XAML - simliar but completely incompatible with WPF XAML.
Not good for developers and just another thing that causes developers to lose trust in Microsoft (one of many over the last few years). It would seem to me that ASP.NET should definitely run on the full .net framework, because there is such a big library of tools that people may need to use on their server. In my case I can easily update to a later version of the .net framework if I need to in order to use latest ASP.net stuff if an update was required for the new ASP.net functionality.
Whatever messaging goes to developers needs to be much clearer, before people just jump ship completely.
...Stefan

ASP.NET Core on .NET Framework was unfortunately never communicated as a stop gap solution to ease porting (that's something we messaged very poorly). It was never intended to as a supported platform forever which is the logical conclusion if you were to assume that some dependencies will just never be ported.

I personally don't have a problem with the changes listed in this issue, I understand the reasoning and they make sense, now that I've read through a lot of responses here. However, what you've just said highlights what's ultimately the crux of the issue - poor communication from Microsoft.
Maybe I'm missing something, but there's more to "developing in the open" than just having the code on github for everyone to poke through and play with. This very issue was created because a change appeared in the code one day that took people by surprise, but obviously yourself and everyone on the .net team knew about it and understood it - so it was a long time coming. The problem is that the rest of us mere mortals were completely blind-sided by it.
Worse still, I suspect the majority of developers don't pay too much attention to github to get their knowledge and information - so this change is going to surprise a lot more people than are already commenting here. I only discovered this issue myself because it appeared on my RSS feed of hackernews - which is not what I'd call my top source for news and information.
Anyone following along from the blog posts on MSDN will know that 2.0 is coming and they'll see it as the holy grail of bridging the gap between asp.net core and everything it was "missing" previously, but they're completely unaware of what is essentially a breaking change for certain workflows. There's been very little details on what's really happening with the design of asp.net core 2.0. I suspect more details will come later this week at Build? One can only hope.
The .net slack is another resource for information, but it's a little bit noisy to be kept up to date with what's really going on. It's great for developer involvement and asking questions, but it's hardly a news source.
Twitter and social media is another source of information, but again a bit like this github issue by the time it appears there, it's usually because someone has raised concerns with a decision that's already been made and caught people by surprise.
This isn't the first time we've had this exact problem, either. Remember the fiasco caused by changing back to csproj? I don't want to get into the debates over that change, but it's another example of a change that happened to people's surprise, that was so poorly communicated that to this day, many people simply don't realise that it's not the same csproj from the "bad old days".
I'm not completely sure what I'm trying to suggest here, but there is definitely something "missing" from the open development of .net. Microsoft does a great job of providing resources and documentation for developers, but only for finished products and things that have shipped. The roadmap, the planning meetings, everything that gets to decide the design and direction of the frameworks seems to be done behind closed doors, with the occasional mention of "select partners" and the like. I'm not saying that every meeting should be streamed and broadcast worldwide, but there could definitely be a better middle-ground whereby decisions that are made and the rationales behind them are communicated as early as possible to the community, in a way that's easy for those of us who really want to follow along to digest and keep on top of. Perhaps a dedicated blog on MSDN (or elsewhere) that's updated regularly when those decisions are made.

One of my biggest issues with this is that on almost every conference the last year that ASP.NET Core has been presented, you have presented it with a slide that shows asp.net core running on both .net framework and .net core, just have a look at this: Explore web development with Microsoft ASP.NET Core 1.0 from Ignite last year. At about 7.50, you will see the slide.
The biggest showstoppers for me are System.DirectoryServices, ServiceBase, EF6 (EF Core is not ready), ClosedXML (for creating excel sheets).

Support for ASP.NET Core 1.x on .NET Framework will be extended for at least another year (until July 2019). We will reassess this annually and commit to providing 12 months notice before ending support of ASP.NET Core 1.x (so by July 2018 we’d announce whether we’re extending for another 12 months to July 2020) (Side note: is anybody else freaked out by the fact we're talking about 2020 already? No? Ok, just me.)

@DamianEdwards Thank you for the announcement.
At the moment our company is developing enterprise applications for several clients using ASP.NET Core 1.1 on .NET Framework 4.6.2. Hearing that the support for that framework combo is supported until at least 2019, and possibly extended 2020 is a huge relief.

We will port System.DirectoryServices and System.Drawing to .NET Core this year (fully supported, cross-platform, preview for at least Windows in Summer)

These are the two only reasons we're targeting .NET Framework right now. If these are fully ported to the .NET Core 2, I'm sure that we can port our applications to ASP.NET Core 2 safely next year.

Seems like alot of ppl have broken the cardinal rule of being a MS developer - dont commit to any product/fork until atleast the V2.
but yeh, talk about alienating your enterprise clients! the whole reason they use MS is for backwards compatibility.
The majority of ppl who run ASP.NET do NOT CARE if it runs on linux. And if they saw a blog post, with a speed comparision with ASPNET Core, they wouldnt even both reading past cross-platform if they saw it didnt support legacy .NET.
lolcats

I think there is value in having ASP.NET Core 2.0 fully run on net46x for the sake of giving lots of folks a smooth migration path to the new world. I think many people were waiting for ASP.NET Core 2.0 and .NET Core 2.0 with the hope that it will close many of today's gaps and allow a migration. If ASP.NET Core 2.0 will require everything to be ported to netcoreapp2.0, then it will be a massive slowdown for teams and perhaps even jeopardise feasibility.
However, that doesn't mean that there cannot be an ASP.NET Core 3.0 shortly after which will only target netcoreapp2.0 for all the people who work on all the new shiny greenfield stuff which doesn't have any legacy bits.
Having two versions of ASP.NET Core (2.0 and 3.0) side by side could really be a good thing. That could allow MSFT to quicker phase out the current MVC 5 stack, because the new version of MVC would essentailly be ASP.NET Core MVC 2.0, which would run on full .NET as well.

I think there is value in having ASP.NET Core 2.0 fully run on net46x for the sake of giving lots of folks a smooth migration path to the new world

What would make it smoother than porting from ASP.NET Core 1.x?

I think many people were waiting for ASP.NET Core 2.0 and .NET Core 2.0 with the hope that it will close many of today's gaps and allow a migration.

The bulk of the work done to make things compatible was done in .NET Core 2.0 and .NET Standard 2.0. ASP.NET Core 2.0 honestly doesn't have that many new features. We're said we're going to backport SignalR to ASP.NET Core 1.x (which is post 2.0 anyways). Is it just a perception thing?

Having two versions of ASP.NET Core (2.0 and 3.0) side by side could really be a good thing.

This is what we're doing with 1.1 and 2.0 (just flip the numbers).

That could allow MSFT to quicker phase out the current MVC 5 stack, because the new version of MVC would essentailly be ASP.NET Core MVC 2.0, which would run on full .NET as well.

MVC 5 will never go away, we don't deprecate anything. It'll be supported as long as .NET Framework exists. You still can't run ASP.NET Core projects inside of the IIS integrated pipeline (on System.Web) and it doesn't do all of the same things as MVC 5 on System.Web so it's really not a replacement for certain scenarios.

@davidfowl Will I be able to create an ASP.NET Core 1.x app, which targets full .NET and netcoreapp2.0 so that I can migrate a current legacy app to ASP.NET Core first with all dependencies being net46x and slowly migrate one dependency after another to target netstandard2.0 until everything is on netstandard2.0 which then would allow me to upgrade the ASP.NET Core 1.x app to 2.x?
If yes, then I think I misunderstood the thread. I think this is really what most people are after here.

@dustinmoris yes you can do that. The main concern people are having is what happens if they don't get migrated to ASP.NET Core 2.x before support ends on ASP.NET Core 1.x, if it is possible for them to migrate at all.

@alexwiese ah ok well that is great, then really what are we discussing here now? Rather than discussing what framework to target we should be discussing the support period of ASP.NET Core 1.x, which is something that MSFT could easily change if they wanted :)

I've read every post in this thread. Still one question is unanswered: why is this decision made? I can only conclude it was needed due to a technical issue. If 'confusion' of the naming is the issue, Microsoft should hire a better PR person and stop stirring the shit like the team is doing in this thread.
So what is the technical issue that blocked ASP.NET core 2.0 on netstandard2.0? Nothing is impossible in software land, so it can't be you couldn't come up with a solution that isn't doable on .NET full (and thus can't be included in netstandard20). Yes that takes time and effort, but I have the feeling you all didn't really realize the side effects of this decision for your users, what the amount of time / effort they have to invest because of this.
This decision has another downside: ASP.NET Core isn't a consumer of netstandard and therefore isn't a driver of it. It makes the netstandard a follower and as ASP.NET core doesn't depend on it, a follower with little meaning: .net core 2.0+'s API is the surface to target, as ASP.NET core is targeting that surface, not netstandard2.0.
And, sorry @davidfowl, I know you mean well, but suggesting ASP.NET core 1.x to people over and over shows you really have no clue what the situation is for the people you suggest that to: the people can't migrate to ASP.NET core 1.x because they don't know if there is a smooth path off of it without a firm deadline: it might be they need to stay on that platform for longer than they currently think (dependencies needed to be ported etc.). That alone makes the decision to move to ASP.NET core 1.x a decision based on nothing else than a 'promise' from Microsoft. It's an API meant for internet facing code. They need to know whether they can run an app built today also within 3 years time because Microsoft will fix security flaws in it (to give an example).
Frankly, I don't get the urge to start yet another chaos cluster within the .NET ecosystem: we need stability, dependability, reliability: "my code written today will run in 5 years time as-is". yes, I know that sounds silly to some people, but that's reality: there are already more software packages on this planet than there are developers to maintain them and the gap is only widening. You can't simply assume that an organization will decide to  use ASP.NET Core as their webstack and hope code written using it will run within 5 years time, organizations don't do that anymore: they know there are stacks out there which are reliable and give them that: they know they might not be able to rewrite the entire app within that timeframe so they need that assurance.
Microsoft has shown with this thread and, sorry, their terrible PR around this issue, they can't give that assurance. And no matter how much spin you try to give that in the coming days at \build, we on the other side of the fence have learned that Microsoft Marketing != assurance things will work tomorrow.

@FransBouma I don't think it was that there was a technical issue, it sounds like the motivation to only target netcoreapp2.0 is because this is the only track that MSFT can move as quickly as they like, which is good for us after all, because it means that ASP.NET Core 2.x can move much faster than other web stacks in the .NET world before. If you cannot commit to this fast train, then you can stay on ASP.NET Core 1.x for longer (currently supported till 2019)


ARROW-16790: [Go][Parquet] Avoid unnecessary memory allocations for skipping rows

CC @mdepero to take a look as the original reporter

CC @mdepero to take a look as the original reporter

FWIW all our tests covering previous issues were green after this PR, thanks for the fix! @zeroshade


macos/ios support ?

Thank you very much for your excellent work on this project; the results are impressive. I am curious if there are any plans to adapt the project for macOS/iOS platforms, possibly utilizing MoltenVK. Additionally, I encountered some configuration issues on an AMD GPU. Is this algorithm universally adaptable across different platforms, including those with AMD GPUs? Any guidance or information regarding this would be greatly appreciated.

Hey!

I am curious if there are any plans to adapt the project for macOS/iOS platforms, possibly utilizing MoltenVK

I haven't pushed any improvement to this project in a while, but I think adding support for building with MoltenVK (at least when installed as part of the VulkanSDK on MacOS) would make a lot of sense. I actually might look into that and some other improvements in the next few days

Additionally, I encountered some configuration issues on an AMD GPU. Is this algorithm universally adaptable across different platforms, including those with AMD GPUs?

Assuming your GPU support Vulkan you should be able to use this library without too much trouble. But of course there's a limited set of hardware I could try it on and some devices may show new errors so any feedback and error you can report would help!

Thank you very much for your support! I am currently looking to evaluate the performance of different feature extraction methods on various platforms such as iPhones, Android devices, and FPGAs. While ORB features are fast, their robustness is limited, and while methods like SuperPoint offer better results, they don't meet real-time requirements. The feature extraction performance on the computer side, as you presented, is very impressive. I'm interested in leveraging your project to experiment with SIFT feature extraction on mobile devices.
Do you think your project could support platforms like iPhones? Compared to other more established SIFT extraction methods, integrating your solution could introduce some unique advantages, potentially broadening the application scope and garnering more attention.
Thank you again for your support!

I added the support for MoltenVK in 7c01bd9 so you should be able to get it running on MacOS easily with the Vulkan SDK installed.

Do you think your project could support platforms like iPhones?

With this addition the current code should support iOS but I won't be able to support that myself since I don't have a personal hardware to test that on a real device. Apart from build system issues the main source of trouble is probably going to be the packaging MoltenVK within the iOS application, the MoltenVK documentation has some information on how to do that with XCode: https://github.com/KhronosGroup/MoltenVK/blob/main/Docs/MoltenVK_Runtime_UserGuide.md#install-moltenvk-as-a-dynamic-library

I'm immensely grateful for your work. The latest version has been successfully deployed on a Mac mini (M2), demonstrating rapid image processing capabilities. For a 640x480 image with rich texture, it impressively extracts over 2000 points in about 11.5ms, and for less textured images, around 700 points in roughly 8ms. With minor modifications, this was also adapted to run on iOS, specifically tested on an iPhone 11 (A13 GPU), where the respective processing times were 46.0ms and 40.3ms. I deeply appreciate your efforts; they are truly remarkable.
In practical usage, the algorithm autonomously extracts features from an input image, but the specific number of features varies. Is there a way to manually set a limit on the number of extracted points, for instance, capping it to the top 500 features? I haven’t found any specific parameter settings for this. Does our system support such customization?

When comparing the SIFT feature extraction (extracting 800 points) in OpenCV, it's noted that on the Mac platform, OpenCV typically takes around 24ms, whereas on the iOS platform, it averages about 47.6ms. This suggests a significant speed increase of nearly double on the Mac platform, while the performance on iOS remains relatively unchanged. Intuitively, one might expect that using the GPU on iOS would be faster than the CPU. Possible reasons for this could include differences in hardware optimization, the efficiency of the GPU utilization in the algorithm, or the specific architectural features of the iOS devices. Further investigation into these aspects might provide more clarity.

I'm glad you got it working on iOS!

Is there a way to manually set a limit on the number of extracted points, for instance, capping it to the top 500 features? I haven’t found any specific parameter settings for this. Does our system support such customization?

VulkanSift doesn't really support that. You can only set max_nb_sift_per_buffer in the vksift_Config to limit the number of features extracted but I wouldn't recomment to use that.
If you want the get the N best features I would recommend to sort the features yourself on the CPU after getting the detection results, you could do something similar to what OpenCV is doing and sort them using the absolute DoG image intensity at the feature position (you have that in vksift_Feature::intensity)

Closing this issue since the initial problem (MacOS/iOS support) appears to be solved. Feel free to open a new ones as needed!


Homebridge version 1.6.1 dependency error

I am running Homebridge 1.6.1 on a docker hosted by Synology NAS and homebridge-nb v1.4.8 installed and configured and properly working but HB log shows this error message
The plugin "homebridge-nb" requires a Homebridge version of ^1.6.1 which does not satisfy the current Homebridge version of 1.6.0. You may need to update this plugin (or Homebridge) to a newer version. You may face unexpected issues or stability problems running this plugin.

Check for multiple Homebridge installations.
I list the version I use for development and testing; other versions might work… or not.  I simply don’t have the bandwidth to test them.

@ebaauw thanks for the response
But why does this error message come even though my HB version (1.6.1) meets your plugin requirements

You probably have Homebridge installed in multiple locations.  The message is from Homebridge itself, and it clearly thinks it's version 1.6.0.  What Homebridge version does Homebridge NB report on startup (right after the "Initializing NB platform..." message from Homebridge).  And what version does Homebridge report right after the QR code?


[jpa][tck] missing requirements on test prerequisites

For example
org.osgi.test.cases.jpa.junit.JPAService_1_1_TestCase.testUseStandardDataSourceConfig()
seem to require the h2 jdbc bundle because it uses an url of jdbc:h2:mem: but the test bundle has no requirement on this, therefore the TCK happily starts (and fails) in such a case.
https://github.com/osgi/osgi/blob/3bf23c2548cc13c144b7254d1dee7655262b25cf/org.osgi.test.cases.jpa/src/org/osgi/test/cases/jpa/junit/JPAService_1_1_TestCase.java#L67

this could use
@Referenced(org.h2.Driver.class)


Fix demo page performance issue

The "Ok" button had 164 identical click handlers attached to it, and they all were called on every click on the button.
Moved the click handler out of the for loop.

Sorry, I might be blind, but I'm not seeing any difference between the code that's there and the code you submitted, other then line-breaks.

@ilyavolodin the code was moved after the closing curly brace

@ilyavolodin, @btmills is right, I placed the code after the body of the for (var rule in rules) loop (after the curly brace on line 169/149 https://github.com/eslint/eslint.github.io/pull/76/files?diff=unified#diff-d494bd0caf730ff97f134507d6d3965cR149 ).

Was there a measurable performance problem that this addresses? Was it slow for you?

@nzakas yes, it executed 164 times slower before the fix. It took about 3 seconds, now it takes 16ms.

Ahh.. I see now. Sorry, git compare made it pretty hard to notice. Yeah, looks like a valid fix. Having 164 handlers on a single button is not a good idea:-)

@EvgenyOrekhov thanks. In the future, please be sure to mention such details when reporting perf problems, it helps a lot.


[language] reject zero-sized struct declarations in bytecode verifier

Zero-sized structs present problems for serialization and deserialization. They are sometimes convenient for the programmer, but not expressive given that you can always use a dummy field.
This PR tweaks the bytecode verifier to reject structs with zero fields. The only use of this pattern in production code was LibraCoin.MintCapability. I added a dummy boolean field to let this continue working.
Almost all of the changes here are silly ones in tests that used zero-sized structs.

Motivation
See above
Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
Tweaked existing tests for zero-sized structs to match new semantics.

Approving as the changes look good, but should probably discuss with others (particularly @shazqadeer  and @dariorussi) before landing

Looks fine to me.

:umbrella: The latest upstream changes (presumably 81ee8a7b5e07141ce5739fc5f17536889494f8bd) made this pull request unmergeable. Please resolve the merge conflicts.

@bors-libra r=tnowacki

:pushpin: Commit b88641e has been approved by tnowacki

:hourglass: Testing commit b88641e3bf76d2a2d22b571098cb5dd1aef5f789 with merge 6c042078d70e22b503ebeda06ee05cd68325d947...

:sunny: Test successful - checks-circle_commit_workflow
Approved by: tnowacki
Pushing 6c042078d70e22b503ebeda06ee05cd68325d947 to master...


Add utility for getting authentication environment variables

When working with multiple machines, it's often easier to set authentication environment variables than it is to ship a .netrc file around. This PR adds a small utility for programmatically retrieving EARTHDATA_USERNAME and EARTHDATA_PASSWORD

Thinking out loud: I think in this case, the envvar names make sense because Earthdata credentials are likely the same regardless of which application uses them, but I have a habit of namespacing my envvars by prefixing them with an application name, e.g. EARTHACCESS_EDL_USERNAME or something.
This is different than the case of an envvar like PORT which unequivocally should be MY_SERVICE_PORT instead, because many applications need different ports set; I'm not suggesting we do this, just looking for others' thoughts on the interface.

Looks neat, how is this different from what earthaccess.login() does? the first thing this method does is trying to authenticate with environment variables. If we are using a cluster and we send the __store__ instance, it's already authenticated no?

Looks neat, how is this different from what earthaccess.login() does?

This utility is for, after a Python session is already authenticated, easily grabbing environment variables needed to authenticate other machines. For example, if I have a .netrc file locally, then earthaccess.login() works great.  Often you can pretty easily set environment variables when provisioning remote machines, so having a little utility for getting the necessary env vars earthaccess needs can be useful.
Here's a specific example of how I'd like to use this with Coiled (though the code being added here isn't Coiled-specific, it could be used by any other library):
import tempfile
import earthaccess
import coiled

# I have a `~/.netrc` file locally on my laptop where this code is running
earthaccess.login()

@coiled.function(
    region="us-west-2",
    environ=earthaccess.auth_environ(),  # This makes sure the remove VMs being spun up here have the right `EARTHDATA_*` variables set
)
def process(granule):
    with tempfile.TemporaryDirectory() as tmpdir:
        files = earthaccess.download(granule, tmpdir)
        ... # Do things with these files

granules = earthaccess.search_data(...)
results = process.map(granules)

If we are using a cluster and we send the store instance, it's already authenticated no?

That's correct, we just don't do that in all cases (e.g. calling earthaccess.download on a list of granules doesn't result in us sending the __store__ instance)

Ooops I merged in the wrong order @jrbourbeau

No worries -- just resolved the merge conflict

I think we should merge this one, what do you think @MattF-NSIDC?

:rocket:


aligator-next: new (parallel, block-sparse) Riccati solvers, CHOLMOD integration, split first- and second- order derivatives

This PR:

Splits first- and second- order derivatives (Resolves #144, @fabinsch )
Adds tracy as a profiling tool (Resolves #120)
Upgrades the minimum version of C++ to 17 (Resolves #119, @ManifoldFR )
Adds a new sublibrary called gar to factorize LQ subproblems for solvers (Resolves #118, @ManifoldFR )
Adds a parallel, block-sparse factorization for the implicit/proximal Riccati algorithm (Resolves #156, @ManifoldFR )
Integrates the CHOLMOD solver from the SuiteSparse library into gar (Resolves #148)
Upgrades the minimum required version of eigenpy to 3.4
Add a C++ example and benchmark of Talos walking by @edantec
Major rewrite of SolverProxDDP : no longer use QFunction or ValueFunction structs, delegate Riccati recursion to gar solvers
Rewrite the Logger class (rename from BaseLogger)
Merge struct ODEData into ContinousDynamicsData, rename continous-base.hpp header to continuous-dynamics-abstract

I would like to thank the contributors to this PR: @fabinsch, @edantec, @jorisv
Resolves #155

Great achievement @ManifoldFR! Bravo!

Adding this comment here for future reference (it'll be added to the docs)
At time of writing, in the current master branch (3.4.90), the global variable which tracks whether allocations are allowed is thread-safe:
https://gitlab.com/libeigen/eigen/-/blob/master/Eigen/src/Core/util/Memory.h#L96
But on released versions of Eigen it is NOT, hence any check for mallocs when multithreading is enabled will break as on/off switches for the malloc status will create race conditions.

@jorisv @edantec @fabinsch you guys think we can merge this bad boy ?


Modify filter step in 3d flow simulator

Currently, the filtering in the 3D flow simulator applies every time to the vorticity field, even though the numerical problems only originate from the advection + stretching term. We should check if only filtering those parts is numerically stable.

As confirmed by @armantekinalp this way of filtering seems to be unstable. As such I will close this as unplanned and delete the corresponding branch.


AWQ small batches optimization

Motivation
Recently, Tsinghua University proposed a survey related to LLM inference acceleration, comparing TensorRT LLM and LMDeploy under AWQ. From the results, LMDeploy has a higher speed-ups for large batches, while TensorRT LLM has a higher speed-ups for small batches. Previously, LMDeploy had been optimizing throughput and internet companies still pay attention to throughput under limited latency during actual online serving. Therefore, optimizing the latency acceleration ratio for small batches might also be meaningful. If interested, you may take a look. Cheers. @lzhangzz @irexyc  @lvhan028 @grimoire
https://arxiv.org/pdf/2404.14294

Related resources
No response
Additional context
No response

The second iteration of our mixed precision GEMM will be ready soon, stay tuned.

The second iteration of our mixed precision GEMM will be ready soon, stay tuned.

Cheers!

how about suppourt group_size == 64，so can enable awq int4 model TP = 2。

suppourt group_size == 64

This requirement has also been mentioned several times in the discussion of other issues, and @lzhangzz ‘s expectation was to support it around July. Perhaps it could also change, after all, plans cannot keep up with changes, and there are many higher priority matters at hand now.

ref https://github.com/InternLM/lmdeploy/pull/2090


How to modify IRAM memory size.  (IDFGH-6201)

My program doesn't use DRAM very much, but it has speed and performance requirements, so I need to put some data and functions into IRAM, and the result is IRAM overbound.

According to the official data manual, ESP32 DRAM and IRAM share one SRAM1, which is assigned to DRAM by default.

ESP32 Programmers’ Memory Model
So I want to find a way to give SRAM1 to IRAM. No matter how troublesome it is, please tell me how to do it.  I have tried to find several relevant blogs and articles and followed the steps provided. Although the program was compiled, it could not run normally.
Reference :

How to modify IRAM size
ESP32 optimization notes (4) IRAM optimization

I've tried to modify the ld file and configuration file:
components/esp32/ld/esp32.ld File modification, IRAM increase 8K:
/* IRAM for PRO cpu. Not sure if happy with this, this is MMU area... */
iram0_0_seg (RX) :                 org = 0x40080000, len = 0x20000
change into:
iram0_0_seg (RX) :                 org = 0x40080000, len = 0x22000
components/soc/esp32/include/soc/soc.h File modification:
Increase IRAM by 8K:
#define SOC_IRAM_HIGH           0x400A0000
change into:
#define SOC_IRAM_HIGH           0x400A2000
DRAM reduced by 8K:
#define SOC_DIRAM_IRAM_LOW      0x400A0000
change into:
#define SOC_DIRAM_IRAM_LOW      0x400A2000
The program was compiled, but it could not run normally.

@zikalino Hello, could you please reply to me when you are free?

@ShenRen Sorry for the late reply!
Just from a quick test, the following changes seemed to work for me:
iram0_0_seg (RX) :                 org = 0x40080000, len = 0x40000
#define SOC_IRAM_HIGH           0x400C0000
Remove this area from being allocated as heap:
 // { 0x3FFE0000, 0x4000, 1, 0x400BC000}, //pool 9 blk 1
 // { 0x3FFE4000, 0x4000, 1, 0x400B8000}, //pool 9 blk 0
 // { 0x3FFE8000, 0x8000, 1, 0x400B0000}, //pool 8 <- can be remapped to ROM, used for MAC dump
 // { 0x3FFF0000, 0x8000, 1, 0x400A8000}, //pool 7 <- can be used for MAC dump
 // { 0x3FFF8000, 0x4000, 1, 0x400A4000}, //pool 6 blk 1 <- can be used as trace memory
 // { 0x3FFFC000, 0x4000, 1, 0x400A0000}, //pool 6 blk 0 <- can be used as trace memory

I was able to compile and run an app which would overflow the IRAM section without these changes. No guarantees that these changes are comprehensive though, there might be other places which needs to be changed that I overlooked.

Closing this one due to lack of activity, but feel free to reopen if my answer didnt fully solve your issue.

@ESP-Marius Isn't this worth officially adding to IDF?

@ESP-Marius Isn't this worth officially adding to IDF?

I'll bring it up at our next team meeting and see if this is something we wanna officially support or not.
In anycase,  I encourage people to add upvotes/comments here, as any decision we make might be changed if we see there is a big demand for.

Please do.  Today I have been porting an application from v4.4.2 to the v5.0.0-beta to take advantage of the SDMMC improvements, TRIM support, and ESP32-S3 support and found that I can no longer build for our existing ESP32-based product without disabling vital IRAM optimizations for WiFi.  The penalty for disabling these IRAM optimizations is reduction in WiFi throughput by more than 50%.
At this time, my team would prefer to increase IRAM for real-time task optimizations and use our PSRAM for non-real-time tasks.

This would be incredibly useful, I'm already riding 100% iram usage right now and only 58% dram, with still some options I'd love to enable still if only I could reliably increase it.

Added a kconfig option for this in https://github.com/espressif/esp-idf/commit/5cbd311ecf0b381a0711ef8a96980a67b30a135f.

would the same be possible for the RTC_SLOW_MEMORY data segement?

Why  do not add a SLIDER to choose from DRAM to IRAM and match the size needed ? as it is quite simple to adjust in the memory layout, is no the best to do?

Added a kconfig option for this in 5cbd311.

Hi @ESP-Marius
I still cannot see this option in MenuConfig: CONFIG_ESP_SYSTEM_ESP32_SRAM1_REGION_AS_IRAM.
My ESP-IDF version is 6.4, and I'm using the PlatformIO environment.
[env]
platform = espressif32 @ 6.4.0
framework = arduino, espidf


Add ability to patch in user-defined functionality

Description
This PR adds a utility to patch in functionality during the execution of ARMI. Four hooks were added to the codebase to execute user-defined code from an input file. This input file has a required format that is described in the testing script for the module.
This module should allow for testing features without modifying the codebase directly, or modifying plant parameters in scoping studies from a centralized file.

Checklist

[x] The code is understandable and maintainable to people beyond the author.
[x] Tests have been added/updated to verify that the new or changed code works.
[x] There is no commented out code in this PR.
[x] The commit message follows good practices.
[x] All docstrings are still up-to-date with these changes.

If user exposed functionality was added/changed:

[ ] Documentation added/updated in the doc folder.
[ ] New or updated dependencies have been added to setup.py.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.bsculac seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

@bsculac
So, are these files not saved to the database?  Just curious.

@john-science The patch files specified by the user are not, should they be? The idea is that these files are specified on-the-fly by someone running ARMI, I wouldn't think it would make sense to catalog them somewhere. Unless storage in the database is something temporary (I admit ignorance on The Database and its purpose).

Please add a tutorial for this functionality to the Docs.

Closed in favor of implementing a solution using plugins.


Rewrite draw routines to match how Atom's standard status bar elements are displayed.

Before

After

I am fixing this positioning situation, as also notified on #27. I still don't know which is better, to empty the css file or to leave there the minimum configuration to display the clock correctly and leave the code untouched.