Orleans upgrade to .Net Framework 4.6

[wanderq]

Is this upgrade is already planned, when it will be performed and what prevents from doing it now?

[veikkoeeva]

@wanderq Officially, or at least semi-officially, I believe Orleans follows the strategy of latest - 1 in its dependencies. There are a few GH issues where it's being discussed, but I don't know how official this is. A real hard limit has been that of Azure compute role .NET version support (which has gone to .NET 4.6 across the board or going soon, I suppose).

I think it would be informative if you or someone else would try updating to .NET 4.6 and running in Azure to see if there are problems.

[jthelin]

Yes, one of the major restrictions on "upgrading" is still which .NET versions are supported by Azure compute worker roles.

Currently anything above 4.5.1 is not directly supported in Azure OS Family 4 and 4.5 is the limit in OS Family 3. https://azure.microsoft.com/en-us/documentation/articles/cloud-services-guestos-update-matrix/#family-4-releases

This is why the code base currently (deliberately) targets .NET 4.5 only [and not 4.5.1 or anything higher] https://github.com/dotnet/orleans/issues/173 https://github.com/dotnet/orleans/pull/273

[wanderq]

Thanks for the clarification.

[grahamehorner]

@jthelin no doubt this will all change soon with the release of ASP.NET 5 CoreCLR ;)

[galvesribeiro]

@jthelin just to clarify. 4.5.1 today is supported. I'm running Orleans on it on cloud services and it does not require any workaround to install new frameworks. I agree 4.6 isn't supported and will probably change with the release of CoreCLR.

Yesterday I received an email from Azure OS team with the following info:

"...On August 7, 2014, we announced that support will end for .NET Framework 4, 4.5, and 4.5.1 on January 12, 2016. To ensure that your cloud services continue to be secure and protected, Azure will update the .NET Framework in Windows Azure Guest operating system (Guest OS) family 2.x, 3.x and 4.x to .NET Framework 4.5.2 in November Guest OS Release. Cloud services running on Guest OS family 2.x, 3.x and 4.x with automatic updates enabled will be updated to the November Guest OS with .NET Framework 4.5.2. If you have concerns of possible application compatibility issues of the .NET update, we would suggest you to validate your cloud service with .NET 4.5.2 before November Patch Tuesday, Nov 10, 2015...."

So, November 10 patch would bring 4.5.2 as well. 4.6 still have some bugs that wasn't completly fixed as the tail-call one.

[jthelin]

Yes, currently we build with TargetFramework=4.5 (Azure OS Family 3 is lowest common denominator) although everything is known to runs ok on 4.5.1 (Azure OS Family 4).

Agree we should test / confirm things run ok on 4.5.2 as well, although running binaries compiled for 4.5 should (supposed to!) still work seamlessly on 4.5.2. Nobody shouted so far..... This is the subtly distinction between "runs-on" and "built-for" versions.

If both OS Family 3 & 4 move to 4.5.2 [which seems to be what the quoted e-mail says] then the "N - 1" version policy we use on this project will certainly allow us to build against that new target after Nov-10.

Personally, I have no strong desire to move to 4.6 too soon. I am more than happy to let someone else flushes out all the bugs in there first! :wink: It was a "big" step change in the internal code structure, APIs and C# language syntax, so really should have been named .NET 5.0 IMHO.

FWIW, installing VC2015 on my main dev machine pulled in .NET 4.6 and broke some of my existing Owin self-host web code which still runs just fine on 4.5 / VS2013, so I know there are still some big issues. Even uninstalling VS2015 and .NET 4.6 didn't undo the problem on that machine, and I still haven't got to the bottom of that issue yet. :(

[galvesribeiro]

@jthelin you are completly right. 4.6 is a lot unstable IMHO. I believe even coreCLR is more stable than 4.6 in its current beta stage to be honest...

I did some tests on 4.5.2 when it was released and we didn't noticed any changes in either stability or performance.

4.6 indeed should be called 5. The language really changed A LOT. IL is generated differently, different compiller etc.

Sad to know that you are with problems on your machine with vs15. I have it here as the only VS installed and I'm doing OK with it. The only thing that was upseting me(a lot!) was the current/old codegen which does not play pretty well with VS15/roslyn/intellisense and breaks with any change on the interfaces project.

Since @ReubenBond and @sergeybykov finally merged #528 those problems are apparently over. Will test more as soon as we have the -beta1 packaged pushed to Nuget.

It still don't target 4.6, but at least VS15 users will not suffer anymore with the old codegen issues.

Thanks!

[TsengSR]

Is there any update on th is issue? Now that .NET 4.6.1 has been out in the wild for over 6 months, that would be in line with the "latest - 1" dependencies? It's quite a pain to work with the new ASP.NET Core (targeting full .NET Framework rather than .NET Core) and targeting anything lower than 4.6 without dozens and dozens of wrapper classes, even though all of the libraries are "in-house" and no need to support older frameworks, except for the Orleans/Orleankka dependencies

[galvesribeiro]

Just to clarify everyone... Looks like we will need to update Orleans to 4.6.2 as part of the .Net Core move and the major reason it isn't done yet is the fact that Azure doesn't support it yet on Cloud Services unless you use Startup Tasks to install the runtime before the app start.

[luomai]

Does Orleans 1.3.1 support .Net 4.6 today?

[galvesribeiro]

@luomai you can use it on any .Net Full Framework. The minimum requirement is 4.5.1 but you can use on any 4.6.x or later.

[TsengSR]

@galvesribeiro: Maybe you can run it on .NET Framework 4.6, but your project can't target .NET Framework 4.6 and hence not use 4.6 APIs.

I got exceptions during startup that Orleans (Console Application targeting net46, using the new project.json/xproj structure,, don't use VS2017 yet) couldn't find the correct assemblies (for 4.5.1 or 4.5.2 dunno anymore).

Targeting back to 4.5.2 worked.

[galvesribeiro]

That is very weird... I had being using Orleans applications on 4.6.x since it was ever released even if Orleans was targeting 4.5.1...

Can you please share your logs with the errors?

[TsengSR]

@galvesribeiro: I was getting errors like this (restored an old state from early July this year, since at that time I targeted back 4.5.2, which that exception and stayed there ever since, waiting to read in the release notes that it works with 4.6 or so ;)

Just caused some pain to turn all of my other projects to target back 4.5 (netstandard1.2 to be more specific)

2016-12-27-12.06.50.105ZZ
ERROR starting Orleans silo name=MYCOMPUTER Exception=
Exc level 0: System.IO.IOException: Der Typeninitialisierer für "File" hat eine Ausnahme verursacht.
   bei Roslyn.Utilities.FileUtilities.OpenFileStream(String path)
   bei Microsoft.CodeAnalysis.MetadataReference.CreateFromFile(String path, MetadataReferenceProperties properties, DocumentationProvider documentation)
   bei Orleans.CodeGenerator.CodeGeneratorCommon.<>c.<CompileAssembly>b__3_1(Assembly asm)
   bei System.Linq.Enumerable.WhereSelectArrayIterator`2.MoveNext()
   bei System.Linq.Buffer`1..ctor(IEnumerable`1 source)
   bei System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
   bei Orleans.CodeGenerator.CodeGeneratorCommon.CompileAssembly(GeneratedSyntax generatedSyntax, String assemblyName)
   bei Orleans.CodeGenerator.RoslynCodeGenerator.CompileAndLoad(GeneratedSyntax generatedSyntax)
   bei Orleans.CodeGenerator.RoslynCodeGenerator.GenerateAndLoadForAssemblies(Assembly[] inputs)
   bei Orleans.CodeGeneration.CodeGeneratorManager.GenerateAndCacheCodeForAllAssemblies()
   bei Orleans.Runtime.AssemblyProcessor.Initialize()
   bei Orleans.Serialization.SerializationManager.Initialize(Boolean useStandardSerializer, List`1 serializationProviders, Boolean useJsonFallbackSerializer)
   bei Orleans.Runtime.Silo..ctor(String name, SiloType siloType, ClusterConfiguration config, ILocalDataStore keyStore)
   bei Orleans.Runtime.Silo..ctor(String name, SiloType siloType, ClusterConfiguration config)
   bei Orleans.Runtime.Host.SiloHost.InitializeOrleansSilo()
Exc level 1: System.TypeInitializationException: Der Typeninitialisierer für "File" hat eine Ausnahme verursacht.
   bei Roslyn.Utilities.FileUtilities.OpenFileStream(String path)
Exc level 2: System.IO.FileLoadException: Die Datei oder Assembly "System.IO.FileSystem, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" oder eine Abhängigkeit davon wurde nicht gefunden. Die gefundene Manifestdefinition der Assembly stimmt nicht mit dem Assemblyverweis überein. (Ausnahme von HRESULT: 0x80131040)
   bei System.RuntimeTypeHandle.GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMarkHandle stackMark, IntPtr pPrivHostBinder, Boolean loadTypeFromPartialName, ObjectHandleOnStack type)
   bei System.RuntimeTypeHandle.GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean loadTypeFromPartialName)
   bei System.RuntimeType.GetType(String typeName, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark)
   bei System.Type.GetType(String typeName, Boolean throwOnError)
   bei Roslyn.Utilities.ReflectionUtil.GetTypeFromEither(String contractName, String desktopName)
   bei Roslyn.Utilities.PortableShim.File..cctor()

But back when Orleans 1.2.3 or 1.2.4 was there, so maybe it changed.

I just tried to set my current master branch back to net46, but didn't receive that error. I simply just assumed it's still there, as I didn't see anything in the release notes about 4.6.

[galvesribeiro]

Yeah, I cant't precise the problem you are facing (maybe someone from core team can) but Like I said, I was using 4.6.x projects with Orleans and I never had anything like it. Orleans target 4.5.1 today so we dont require users to upgrade to 4.6.x but it should be totally compatible.

In 2.0 however, we are upgrading to 4.6.2 in the full framework by targeting netstandard1.5 so people will have to upgrade their environments if they want to go 2.x