Target .NET 4.5.1 instead of 4.5.

[sergeybykov]

This is to address #173.

[veikkoeeva]

@sergeybykov Out of curiosity, do you have performance figures with this change?

[sergeybykov]

@veikkoeeva I didn't notice any performance differences in our internal load test. I was expecting none since the test machines already had 4.5.1 installed for quite some time. I presume there's no difference in performance between code targeted to 4.5 and 4.5.1 when run on 4.5.1.

[jthelin]

@sergeybykov - Is there any advantage in specifically targeting the build to 4.5.1 then?

If we are not using any 4.5.1 specific APIs [should not really be any differences in a 0.0.1 delta though] and the 4.5.1 runtime code is automatically used if installed [I assume this is how it works, same as 4.0->4.5 does], then isn't this change a no-op?

I am wary of making people force-update all their deployments to 4.5.1 if they are already comfortably running Orleans services with stock .NET 4.5 machines.

Sticking with 4.5 also seems to be consistent with the N-1 versioning baseline policy we have converged on for Orleans, if you consider the definition of "latest" to be "what Azure supports".
http://azure.microsoft.com/en-us/documentation/articles/cloud-services-guestos-update-matrix/#family-4-releases
ie N == Azure OS Family 4 == .NET 4.5.1 [Note: 4.5.2 is NOT auto-installed on OS Family 4]
& N-1 == Azure OS Family 3 == .NET 4.5.

There seem to be enough known issues with 4.5.1 [and 4.5.2] that it feels like we should really leave the decision of when to upgrade machines to sys-admins rather than some random collection of infrastructure software developers on GitHub ;)

• Known issues for the .NET Framework 4.5.1
• Known issues for the .NET Framework 4.5.2

However, I 100% agree we should add a "recommendation" to use .NET 4.5.1 somewhere through, and link to the perf article.

[jthelin]

BTW, while we are thinking about assembly reference versioning, I notice that 4.5.1 has a feature called "Automatic Binding Redirection" which can auto-magically change binding versions even if you specify something specific in app.config [my emphasis added below]

https://msdn.microsoft.com/en-us/library/2fc472t2(v=vs.110)

Starting with Visual Studio 2013, when you compile apps that target the .NET Framework 4.5.1, binding redirects may be automatically added to the app configuration file to override assembly unification. Binding redirects are added if your app or its components reference more than one version of the same assembly, even if you manually specify binding redirects in the configuration file for your app. The automatic binding redirection feature affects traditional desktop apps and web apps that target the .NET Framework 4.5.1, although the behavior is slightly different for a web app. You can enable automatic binding redirection if you have existing apps that target previous versions of the .NET Framework, or you can disable this feature if you want to keep manually authored binding redirects.

This sounds to me like this could create a huge app-versioning time-bomb -- making it almost a crap-shoot to working out deterministically what assembly binding versions any particular build will produce unless everyone sets AutoGenerateBindingRedirects=False.

Am I misunderstanding the utility of this new 4.5.1 "feature"?

[sergeybykov]

@jthelin I don't know. Maybe actually be a pretty useful feature for typical cases, e.g. Newtonsoft.Json 5.0.8 vs. 6.0.4 vs. 6.0.8 where all such versions appear compatible and auto-binding would actually work. I'm just guessing here.

In any case, I don't think we can freeze the target .NET version forever anyway. So moving to 4.5.1, to 4.5.2, 4.6 seems inevitable to me. Only a question of time.

[jthelin]

Right, but I am not suggesting that we freeze forever -- I am suggesting that until Azure officially supports 4.5.2 pre-installed then we should not consider it to be an official "current version".

Therefore at the moment seems like the "current" version N = 4.5.1 and N-1 = 4.5 ?

By forcing versioning to 4.5.1 we are in effect disallowing use of Azure OS Family 3 and saying must use OS Family 4.

BTW, the AzureWebSample currently uses OS Family = 3 so that would break with this proposed change :(

[sergeybykov]

I'm fine with staying on 4.5 until Azure moves to 4.5.2 or 4.6.

[sergeybykov]

Should we close this one for now then?

[jthelin]

Yes, let's close for now and we can revisit if/when Azure version situation changes.