IDE ◦ how the IDE works. • 2014: Mono and Open Source .NET ◦ how Mono is made up with OSS-ed .NET parts • 2015: .NET Core ◦ what .NET Core is, how it works. (meh, the topics are getting bloat...)
not quite handy, need to install .NET Fx ◦ apps easily become Windows-only ◦ too much of Windows-isms ◦ too many framwork variants, hard to support all ◦ .NET Fx development is getting slow ◦ updatable only in sync with Windows or VS releases. ◦ several issues due to closed source
defects • cross platform • open source • non-Windows native API Also, Microsoft friendly Problems • not (meant to be) fully compatible w/ .NET Fx • not actively developing server stack anymore • Xamarin went mobiles, leaving Linux desktop
Fx and versions ◦ because everything cannot be implemented everywhere ◦ You cannot reference Desktop assemblies in those frameworks ◦ Normally libraries need to be built for those platforms • PCL (Portable Class Library) makes it easy ◦ you build your library as a PCL project ◦ PCLs can be referenced by any (of the profile targets) ◦ For PCLs, you specify Profile, not dll references ◦ packages via NuGet.org (zip archive of dlls, resources and tools)
◦ so each Profile is represented as a set of feature assemblies • Type forwarding ◦ PCL "Facade" assemblies don't have implementation ◦ instead, they have [TypeForwardedTo] attributes.
VB coders) x integration with external JavaScript was horrible ASP.NET Ajax • MVC o that's what normal Web dev. wanted. o started as an OSS project, and extended OSS-ism. x depends on System.Web
of .NET Fx • sort out all of those known issues ◦ MIT license w/ patent covenant ◦ standalone redist-able, per app ◦ x-plat • release stages: src(git)/pkg/Fx the rise of .NET Core
https://github.com/dotnet/coreclr#get-net-core or Docker ◦ ... or manually set up everything (complicated) • app files: (C#) sources, package.json (project config) • Run ◦ set up dnvm (dnvm: runtime configurator; see coreclr docs) like update-alternatives ◦ dnu restore (dnu: package resolver) ◦ dnx (-p) . run (dnx: runtime, -p is very new option) ◦ dnvm install 1.0.0-beta7-12275 -r coreclr -u; dnvm install 1.0.0-beta7-12275 -u; dnu restore; dnvm use 1.0.0-beta7-12275 -r coreclr; dnx . run
▪ the Fx runtime backend can be: clr, mono, coreclr ◦ dnu (package resolver) ▪ based on nuget ◦ dnx (runtime) ▪ uses roslyn (compiler) to compile app at run time
everything to run app is messy.) • coreclr runtime ◦ you need Windows to build mscorlib.dll ◦ or, some people offer precompiled ones ◦ or, use my patched build that partially works (PR1275) • corefx classlibs ◦ builds on Linux/Mac/Win (often fails outside Windows) ◦ still lacks PCL Facades - need to download binaries (dnu restore) • roslyn compiler ◦ Windows for full build, or partial x-plat build
Silverlight (on Mac) -> this ◦ EE (execution engine) , GC, native interop, JIT, debugging ◦ mscorlib.dll (as it is tightly-coupled with the VM) ◦ architecture docs for hackers: Book of the Runtime (BotR), CoreCLR Coding Guide (in the github repo) but you would be just happy with existing .NET readings, they are so advanced...
COSCUP2013 slides ◦ Used by VS2015, MonoDevelop6 and "omnisharp" • managed C#/VB compiler implementation ◦ easy to extend by .NET devs • debug symbols are getting portable (PPDB - very new)
Core) • It is mostly for Mono project ◦ so that Mono can import it, for improved compatiblity. ◦ Mono is importing them, but cannot simply replace. ▪ remove Windows-isms, mobile restrictions etc.
= native executable code generator ◦ coreclr JIT is pluggable (can be replaced) • JIT implementation trend: use LLVM native codegen ◦ to support as many platforms as LLVM supports. • llilc: coreclr JIT implementation using LLVM • under development yet
Cross platform IDE for .NET Core • Very simple IDE. Just an enhanced code editor + debugger ◦ But what is an "IDE" ? >> my COSCUP2013 slides • built upon Electron (Atom Shell) • supports C# and TypeScript (TS has language service)
.NET platform (i.e. not now) ◦ .NET Framework etc. will be based on it. • code status ◦ coreclr - Windows dependencies in the build system ◦ corefx - more porting work needed ◦ no integrated build/installs. ◦ builds are not stable yet. Builds on CI servers are almost fake. • ASP.NET - on its own roadmap
cross platform is still big TODO at .NET Core. ◦ There is mono ecosystem (Gtk# and apps) ◦ so as Xamarin platforms • Mono visions ◦ import more referencesource for .NET compatibility ◦ reuse good coreclr parts (e.g. GC)
if you just write apps, use .NET Framework etc. ! • You can understand the underlying Fx you use better. • You can build and ship app with your own .NET Core build. ◦ ship with fixed version of .NET Core ◦ modify the Fx behavior to fit your app's need. • You can research how the modern dev. framework works.
has done in the past • Hosting CoreCLR ◦ Office.NET, CLI-UNO (LibreOffice) ◦ SQLCLR ◦ Unity3D etc. • Develop another .NET based framework? ◦ Browser plugin? (Silverlight/Moonlight => WebAssembly) ◦ IoT? (.NET Micro Framework) ◦ new mobile platforms? (Xamarin)