Azure Functions v2 & .NET Framework

[johngrace]

We currently have Azure Functions v1 in production using .NET 4.6.1 which rely on 3rd party dlls which we do not have a .NET Core version yet. It could be 1-2 years before we get the 3rd party dlls to .NET Core, if ever. So some key questionsI think everyone will want to know about upgrades are,

Q1 - Are there any plans to have Azure Functions v2 support the regular .NET Framework in the future to make upgrading our production system possible? If so are there any rough dates of when this might be available?

Q2 - If not then how long can we expect Microsoft to support Azure Functions v1? Is there an official mainstream & extended support schedule of dates like other Microsoft products announcing when you are going to turn off Azure Functions v1 ? I have seen this comment from @jeffhollan on Jan 9th saying a 'considerable period of time' but enterprise customers need specifics

https://github.com/Azure/Azure-Functions/issues/640

The killer issue here being if Microsoft turn off Azure Functions v1 without supporting .NET Framework on Azure Functions v2 there is a good chance we are screwed for our production system right now in the future and need to stop migrating our code base to Azure Functions due to the lack of support.

[jeffhollan]

Q1 answer is not planned currently. For Q2, v1 will be fully supported for at least a year after v2 goes GA. Customers will be given ample notice of any eventual plans to discontinue v1 support. That said future investments will show up in v2 so we do recommend customers move to v2 when it's ready for production usage, but understand dependencies you are dealing with now.

Hope that helps but definitely understand the 3rd party dll aspect.

[johngrace]

Thanks for the quick response Jeff.

I've created a feature request to see if we can momentum to get your team to include it in your plans :)

https://feedback.azure.com/forums/355860-azure-functions/suggestions/34148206-azure-functions-v2-supporting-the-net-framewor

Just out of interest is the reason for not supporting the .NET Framework just to push people to .NET Core as that's the future or is it just a very large piece of work to support it?

[MisinformedDNA]

Also, 3rd party DLLs don't necessarily need to be converted to .NET Core. They just need to support .NET Standard.

.NET Standard and .NET Core are the future, that's where functionality should be focused. If the community wants to port stuff, that's fine, it's all open source. But the core team should be focused on the future. IMO.

[johngrace]

I completely agree with you on the future, but the day to day reality of Azure Functions (AF) for enterprise production systems is a lot trickier.

Here is a good example of some 3rd party Dlls that we can use in AF v1 but not v2 because of being able to use the .Net Framework.

https://www.nuget.org/packages/Microsoft.CrmSdk.CoreAssemblies/

These are all from the Microsoft Dynamics 365\CRM team. They currently have no support for .NET Standard \ Core and we do not know when they will support it. This hurts AF v2 as you now just cannot use AFs because in around 1 years time AF v1 could be turned off & then you are really in trouble.

Give it a few more months & if more pain points like this keep cropping up then maybe they will support .Net Framework. for AF v2.

[MisinformedDNA]

Given that AF v2 isn't GA and the NuGet package is in active development (and from Microsoft), I wouldn't be too worried. But what you should be doing is contacting your MS CRM rep and let them know that .NET Standard support is something that is important for you.

I'm guessing that MS won't stop supporting AF v1, if important packages are not converted. And also, they'll want to see people moving over on their own and being happy, before they force everyone.

But let's touch on that. How many changes has Azure forced us to make? I can think of one: caching. The cost of keeping up old services is a trivial cost, so really, it's way too early to be concerned about being left in some crazy limbo. Also, MS hasn't deprecated the .NET Framework, so I would be very surprised if they deprecated AF v1 (at least for a long, multi-year, time).

[ColbyTresness]

@paulbatum are there any outstanding work items being tracked here?

[paulbatum]

@ColbyTresness not at this time. Either we can leave this open simply for the purposes of making it easier to find for users that want to submit additional feedback on the topic, or just close it.

[ColbyTresness]

Up to you - just wanted to triage. I'll leave it in active questions for now.

[CANUSA]

Is there an update on this being supported down the road? At the very least is there any guidance other than using v1 for this requirement? What happens down the road when we are forced to upgrade and we have full framework dependencies?

[ColbyTresness]

There's no guidance right now other than "use v1". We're evaluating plans for supporting this down the road and will try to update this issue when we start building something.

[AkbarAnsari]

Hi @jeffhollan,

While moving function app v1 to v2 we are facing many issues with third party dll & wcf services build on .Net framework. As of now WSHttpBinding support is not available and have not seen any updates on future plan on this.

Can you provide a date by when Azure will discontinue V1, and plan to support .Net framework based library in V2. because moving everything in .net core is not easy there are many dependencies and resolving them is difficult. I can move/change my api's into .net core but third party services or code library which written in .net framework changing them is difficult.

[jeffhollan]

Understand and we are aware of some libraries not yet having support in .NET Core that may prevent users from moving to v2. While we hope those who can make the effort to move to v2 soon (just as that's the current major version), we do not intend to make any changes to the status of functions v1 in CY 2019. Whenever we do make a change, we'll give customers at least 12 months notice and proactively let users know this change is incoming.

[emilbm]

These answers are just plain old unacceptable. The Azure Functions team have been luring people to get on the AF boat with all their magnificent promises, and now that companies are in production with business critical systems, you drop the bomb that "1 year from v2 GA we will probably force you to upgrade to something that is just not practically feasible for most real use-cases.".

If AF ever wants to be a real product that is used in actual systems, they need to hire some people that actually know what real world systems look like. The casual indifference that that the MSCRM team will deploy .NET Standard packages within a year from now is mind-blowing.. Having followed development for MSCRM since 2010, their timelines are nowhere near as fast.

I understand that MS is pushing to eventually discontinue .NET Framework, which is fine, but pulling a bait-and-switch like the AF team has done is such terrible business practice.

I sincerely hope that the AF team will either decide to extend guaranteed support of V1 to several years, or find a way to support framework dlls in V2 (which I realize is doubtful for several reasons).

[MisinformedDNA]

@emilbm You should reread @jeffhollan's post:

While we hope those who can make the effort to move to v2 soon (just as that's the current major version), we do not intend to make any changes to the status of functions v1 in CY 2019. Whenever we do make a change, we'll give customers at least 12 months notice and proactively let users know this change is incoming.

Notes:

• v2 is already GA
• v1 will not be deprecated in 2019
• Customers will receive at least 12 months notice
• We have at least until 2021 until v1 is deprecated.
• v1 and v2 are both open source and can be run on a VM (if worst comes to worst)

[coreConvention]

• We have at least until 2021 until v1 is deprecated.

@MisinformedDNA I'm curious where you are deriving that statement from. I have a current client wanting to roll out some azure functions, but they are hesitant to go straight to v2 as I am recommending. If that is suggested somewhere, officially or otherwise, that would very much help make my case.

[MisinformedDNA]

See quote: https://github.com/Azure/Azure-Functions/issues/790#issuecomment-475835595

That said, new development in v1 is a horrible idea. Only certain versions of NuGet packages can be used. v2 is being actively developed and improved, v1 is not. Most of the documentation is for v2 now, so that would be confusing as well. v1 to v2 upgrade is not trivial. (It's not hard either, but it is recommended that you start a new project.)

Here's another quote

By default, function apps created in the Azure portal are set to version 2.x. When possible, you should use this runtime version, where new feature investments are being made.

[paulbatum]

I work on the functions team and I can confirm that everything @MisinformedDNA said is correct.

[paulbatum]

Also to put it into perspective, go here and scroll through the pages of releases, taking note of how many updates we've done for V2 and how many updates we've done for V1 in the past 12 months: https://github.com/Azure/azure-functions-host/releases

[emilbm]

@MisinformedDNA

Only certain versions of NuGet packages can be used.

Do you by any chance mean this sets us free in terms of internally-used nuget packages as well? I'm referring WindowsAzure.Storage, Newtonsoft and packages like that, which is pretty locked in V1.

[MisinformedDNA]

@emilbm Yes! Complete freedom. V2 runs out of process instead of in-process (which was the implementation in V1).

[paulbatum]

@MisinformedDNA hmm that might be a bit misleading. Functions V2 executes user provided C#/F#/etc code within the same process as our functions host. You are correct that we have an out-of-process model but that only applies to the other languages (Java, JavaScript, Python, etc). The major change between V1 and V2 is how we load the assemblies, specifically the fact that we use a separate AssemblyLoadContext. That, combined with a few other changes, is what enables the freedom you mentioned :)

[JerryNixon]

Boo. I don't understand why anyone would say.

That said, new development in v1 is a horrible idea.

When we know .NET Framework is not supported in v2. There is use case after use case with .NET Framework dependencies that you are casually characterizing as a horrible idea. How about saying not supporting .NET Framework in v2 is a horrible betrayal of customers who trust Microsoft? Or how about saying, If you have to use v1 because we don't support your technology stack in v2, then you do what you have to do and we will support you.?

Flippantly saying we should contact some sales rep and insist they push for Standard assemblies violently undermines the trust customers have for Microsoft; it also undermines Microsoft's prescriptive guidance that customers listen to and obey, then feel cheated when this happens. You are just saying, "Not my job. Good luck.". It's a disappointing behavior. When a company or developer is left behind, it sucks - find a path for them, not a way to end the conversation.

[JerryNixon]

Final note, EVERYONE SHOULD READ THIS: a comment on Github is not a contractual guarantee of anything, including that v1 functions will exist past 2019, 2020 or any other date. It's just a comment. Microsoft is bound by the policies they publish. Without a link to a policy, what team members say doesn't matter. It doesn't matter at all, because it is not binding. Members come and go on teams and you can't pull up this Github thread as any kind of proof if things change. If you don't see it in a written, official policy than it's just people talking and not something to bet your business on. I appreciate Microsoft teams telling us the direction of products, but remember when the rubber hits the road, only published policies are contractual.

[paulbatum]

@JerryNixon regarding your comments on new development on V1/V2 - I think you perhaps took the earlier statement a little out of context. If you read the comments just before it, the context was a new project that had no specific requirement to be on .NET framework. In that scenario, it is quite difficult to justify targeting V1. If you need to run on .NET framework then target V1 and we will support you.

[paulbatum]

The functions V2 host is based on .NET Core, which by definition cannot run packages that have a hard dependency on .NET framework.

If we had made the choice to keep V2 on .NET Framework, we would have an extremely long list of customers complaining about not being able to use any of the new features in .NET Core on functions.

We would also not be able to support languages that require running on Linux (Python is the best example). This last point is especially important to us - Azure Functions is a multi-language service and so our efforts to make .NET users happy have to coincide with making JavaScript, Java, PowerShell and Python users happy.

The fact I described above - that some users need to stay on .NET Framework and some users want to run on .NET Core is the reason why we are currently supporting both V1 and V2.

[chillNZ]

Hi Paul,

Sorry, I'd been struggling for days with (reasonable from your summary) limitations in functions which made me act irrationally. Please accept my apologies, I realize this project will be close to many hearts as it is an impressive undertaking and I was out of line. I've since removed the offending comment, have a nice day.

[paulbatum]

@chillNZ Apology accepted! I understand where your frustration is coming from and I also updated my comment.

[brandonh-msft]

If you need to run on .NET framework then target V1 and we will support you.

@paulbatum can you speak to how long support will go on for V1 customers? With the latest revelations that the NetFx -> NetCore port is "complete" I ask this on behalf of our enterprise customers with NetFx (read: XML, XSLT, etc.) dependencies.

[AartBluestoke]

It should be noted that by-design certain c#8 features are not intended to be available with any Framework 4.x target (ie, azure functions V1), along with specific performance improvements not being ported (related to readonly-span, and not having temporary copies of objects) (can't find the [citation needed] for this atm)

Referencing https://github.com/dotnet/csharplang/issues/2877#issuecomment-540011743 and https://devblogs.microsoft.com/dotnet/net-core-is-the-future-of-net/