A first hand look from the .NET engineering teams
The free, virtual and community-driven dotnetConf is on. Point your web-browser to dotnetConf. No registration, manager approval or anything required! The virtual conference is two days long.
Check out the schedule to find talks that interest you. Join the community, online and in the dotnetConf JabbR room.
Excellent conference so far! I missed the keynote and the the "New innovations in .Net Runtime", but I have a question I would have asked then. Currently the only available .Net runtime available in the .Net Foundation is the .Net MF. Are there any plans to open source the CoreCLR, K Runtime, .Net CF, or a limited subset of one of these for the .Net Foundation under the same Apache license as .Net MF? Or, any plans to enhance the existing .net MF to support higher-end hosted environments with an OS pre-installed (raspberry pi, wearables)?
@SleepyDaddySoftware - Glad you enjoyed the conference! We’ve opened up a lot of the framework already, particularly ASP.NET vNext, including github.com/.../KRuntime under the Apache license and we’re looking into the possibility of more in the future. As for plans with .NET MF, you should reach out to the project leaders. You can find more information about all the projects in the foundation here: www.dotnetfoundation.org/projects
I've seen some references to doing away with .NET strong naming. I think that is "throwing out the baby with the bathwater". It is good to guarantee a unique assembly name given that there is no .NET namespace registration/clearing house (not that I would want one). The problem people run into with strong naming is due to the fact that the version that to match exactly - hence the infamous .NET version hell. There is where I think the .NET runtime gets a bit too opinionated.
CLR loading based on strong names should have an option to suppress the consideration of the version number. Perhaps this could be a new AssemblyAttribute. And when folks choose not to suppress use of the version number for loading, perhaps there could be an option to specify use of semantic versioning. That is, I would use an AssemblyAttribute to specify use of SemVer and I would specify a minimum version e.g. 1.3. The CLR would then load any assembly matching the strong name with versions 1.3 up to but not including 2.0. In SemVer a change in major version number indicates a breaking change with previous versions.
@Keith -- We are looking at some of those options with ASP.NET vNext. Take a look at what we're doing there and see if you believe that we're getting closer to a great solution. I'm sure we'll post more on that when we get a little bit farther along.