.NET without Windows
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 96 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/51827 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
NDC Oslo 201619 / 96
2
7
8
9
12
14
19
20
26
28
31
33
38
40
43
45
48
50
51
61
63
65
76
79
80
83
87
88
90
93
94
96
00:00
.NET FrameworkOpen setPoint cloudCore dumpNetwork operating systemFreewareComputing platformGraphical user interfaceOpen sourceCodeMobile appSubsetEscape characterAndroid (robot)Thermische ZustandsgleichungKeyboard shortcutForm (programming)Game theoryWindows PhoneServer (computing)FactorizationSoftware frameworkAssembly languageBoiling pointStack (abstract data type)Just-in-Time-CompilerPoint cloudFunctional (mathematics)SpeicherbereinigungServer (computing)Inheritance (object-oriented programming)MiniDiscWebsiteComputer fileCross-platformMachine codeWindowGUI widgetoutputCore dumpLogic.NET FrameworkSoftware developerGame theorySurfacePoisson-KlammerLibrary (computing)Revision controlComputing platformVirtualizationCartesian coordinate systemThread (computing)Flow separationTask (computing)Ocean currentData conversionNumberImplementationOpen source40 (number)CodeAssembly languageInformationKeyboard shortcutSummierbarkeitField (computer science)Compilation albumMultiplication signPoint (geometry)Physical systemRight angleRun time (program lifecycle phase)1 (number)Android (robot)Sign (mathematics)Computer hardwareSemiconductor memoryProcess (computing)SpacetimeMoment (mathematics)CASE <Informatik>BootingSet (mathematics)Software development kitQuicksortAreaCodeProjective planeSoftware frameworkGraphical user interfaceEscape characterSubsetForm (programming)Mobile appDifferent (Kate Ryan album)Computer programmingFormal languageGoodness of fitMobile WebFront and back endsOpen setInformation securityBitFinite differenceVisualization (computer graphics)Virtual realityComputer animation
07:46
.NET FrameworkComputing platformStandard deviationSubsetComputer-generated imageryApplication service providerCore dumpIntegrated development environmentAxonometric projectionFile formatData modelMachine vision1 (number)Code refactoringThermal expansionSurfaceControl flowMathematicsSoftware developerGoodness of fitQuicksort.NET FrameworkReading (process)Core dumpLibrary (computing)Virtual machineInheritance (object-oriented programming)Cartesian coordinate systemCross-platformFile formatType theoryBitMultiplication signSystem callComputing platformSoftware frameworkStandard deviationSubsetEndliche ModelltheorieAuthorizationAbstractionLatent heatElectronic mailing listRevision controlCodePortable communications deviceCode refactoringView (database)1 (number)Machine visionProjective planePoint (geometry)Run time (program lifecycle phase)Medical imagingElectronic meeting systemWindowMobile appBlogVirtualizationMoment (mathematics)Application service providerProfil (magazine)Line (geometry)Computer fileDot productSurfaceTunisPrisoner's dilemmaBuildingRoundness (object)PlanningService (economics)MereologyFrustrationSocial classVisualization (computer graphics)Integrated development environmentRewritingComputer animation
15:27
Application service provider.NET FrameworkCore dumpProjective planeVisualization (computer graphics)Core dumpPhysical systemApplication service providerComputer fileMathematicsTelecommunicationClosed setFormal languageLattice (order)Decision theoryStability theoryPlastikkarteGoodness of fitMultiplication signPower (physics)Beta functionCodeComputing platform.NET FrameworkTask (computing)Open setBitSet (mathematics)Computer animation
18:11
.NET FrameworkInstallation artCore dumpComputer configurationLine (geometry)InformationElectronic visual displayComputer programRun time (program lifecycle phase)Execution unitSimulationMaizeSign (mathematics)MiniDiscSet (mathematics)Physical systemInformation securityCodierung <Programmierung>CryptographyCoding theoryUtility softwareSynchronizationRevision controlDemo (music)Inheritance (object-oriented programming)Multiplication signUniform resource locatorCartesian coordinate systemOvalSampling (statistics)WindowSoftware frameworkBitElement (mathematics)Number.NET FrameworkMultilaterationQuicksortCore dumpVideo game consoleElectronic mailing listType theoryLibrary (computing)Mobile appLine (geometry)Content (media)Standard deviationRevision control1 (number)Computer fileMassDifferent (Kate Ryan album)Computer programmingDirectory serviceInformationDivisorObject (grammar)Computing platformBinary fileRun time (program lifecycle phase)Projective planeBuildingSoftware testingComputer configurationSystem callPoint (geometry)File formatPhysical systemComputer animation
23:13
Template (C++)Visual systemMobile app.NET FrameworkApplication service providerVacuumTwin primeRevision controlLibrary (computing)Query languageBootingSign (mathematics)MiniDiscInformationMacro (computer science)Cache (computing)Computer fileServer (computing)Integrated development environmentProgrammable read-only memoryComputer fontComputer iconSet (mathematics)Group actionVisualization (computer graphics)Installation artWeb applicationSoftware frameworkWeb 2.0Code2 (number)Core dumpBit.NET FrameworkType theoryParameter (computer programming)Computer configurationMobile appApplication service providerComputer fileFront and back endsData managementDemo (music)Default (computer science)Social classCartesian coordinate systemAxiom of choiceRun time (program lifecycle phase)Extension (kinesiology)Projective planeElement (mathematics)QuicksortSpeicherbereinigungUnit testingRevision controlMultiplication signServer (computing)Text editorStructural loadTouchscreenWindowScripting languageTemplate (C++)Video game consoleBuildingClient (computing)Library (computing)File viewerWeb browserSource codeComputer animation
28:16
Visual systemView (database)Group actionGame controllerRootApplication service providerConvex hullProgrammable read-only memoryComputer programSynchronizationMobile appControl flowSimultaneous localization and mappingComputer fileSource codeMathematicsChainRadarCellular automatonVacuumCore dumpWindowText editorVideo game consoleApplication service providerWeb 2.0Computer fileQuicksortConfiguration space.NET FrameworkComputer programmingDifferent (Kate Ryan album)Assembly languageGroup actionCodeIntegrated development environmentBitScripting languageProjective planeWeb applicationVisualization (computer graphics)Similarity (geometry)Link (knot theory)MereologyProcess (computing)Library (computing)Computing platformMultilaterationFunctional (mathematics)Computer configurationView (database)Cartesian coordinate systemDrill commandsTemplate (C++)Variable (mathematics)Complete metric spaceType theoryPlug-in (computing)Goodness of fitControl flowPoint (geometry)Server (computing)Web browserINTEGRALFile formatDefault (computer science)Front and back endsCross-platformRange (statistics)Moment (mathematics)Computer animationSource code
34:20
Drum memory.NET FrameworkApplication service providerExecution unitInformationData miningCache (computing)Set (mathematics)MiniDiscDot productPrice indexComputer fileRaster graphicsArc (geometry)Ljapunov-ExponentRevision controlScalable Coherent InterfaceCore dumpSoftware testingVideo game consoleConfiguration spaceInternetworkingServer (computing)Bit rateTotal S.A.Error messageExpected valueRing (mathematics)EmailStreaming mediaVideo game consoleSoftware testing.NET FrameworkCodeBinary fileInternetworkingProjective planeCartesian coordinate systemExecution unitEquivalence relationBenchmarkMobile appQuicksortResource allocationWeb 2.0Category of beingCode refactoringResolvent formalismType theoryServer (computing)Installation artMereologyLocal ringPoint (geometry)Software frameworkBuildingVisualization (computer graphics)Standard deviationSocial classDemonCore dumpCross-platformWeb applicationCarry (arithmetic)Default (computer science)Computer fileComputing platformRun time (program lifecycle phase)Application service providerLibrary (computing)Unit testingDemo (music)Cheat <Computerspiel>Computer animation
40:20
Menu (computing)Run time (program lifecycle phase)Multiplication signComputing platform.NET FrameworkPlastikkarteElement (mathematics)Greatest elementMobile appBitType theoryComputer animation
41:05
InformationData miningRevision controlComputer iconPhysical systemComputer virusFunction (mathematics)Extension (kinesiology)View (database)QuicksortWeb 2.0Mobile app.NET FrameworkCartesian coordinate systemWeb applicationCross-platformProjective planeComputer fileScripting languageRun time (program lifecycle phase)Asynchronous Transfer ModeFitness functionCore dumpTask (computing)Binary filePoint (geometry)Extension (kinesiology)Application service providerFlagComputing platformSoftware frameworkLatent heatStructural loadComputer animation
43:42
Physical systemCodierung <Programmierung>String (computer science)Task (computing)Exception handlingMessage passingToken ringServer (computing)Electronic program guideKernel (computing)Process (computing)Local GroupVirtual machineVirtual realityComputer-generated imageryProcess (computing)Mobile appCartesian coordinate systemVirtual machineRevision controlKernel (computing)Portable communications deviceGroup actionLine (geometry)Directory service.NET FrameworkFigurate numberMedical imagingFluid staticsWindowServer (computing)Computer fileFile formatComputer programmingWeb applicationGreatest elementWebsiteBit
47:18
Proxy serverServer (computing)Client (computing)Process (computing)Set (mathematics)Module (mathematics)Reverse engineeringLevel (video gaming)Core dumpMedical imagingSystem callReverse engineeringCartesian coordinate systemClient (computing)MathematicsServer (computing)Proxy serverIntegrated development environmentQuicksortRoundness (object)Instance (computer science)Default (computer science)Web browserWeb 2.0Interface (computing)BitComputing platformProcess (computing)Mobile appApplication service providerWindowDependent and independent variablesData management2 (number).NET FrameworkIP addressVirtual machineComputer fileDemo (music)Module (mathematics)Computer configurationWebsiteDirection (geometry)LastteilungInternetworkingKernel (computing)Cache (computing)Configuration spaceText editorFunctional (mathematics)TwitterComputer virusCore dumpMultiplication signIntrusion detection systemSoftware bugStack (abstract data type)Buffer overflowFlow separationDataflowWeb pageService (economics)Perfect groupElectronic mailing listSoftware development kitComputer animation
Transcript: English(auto-generated)
00:04
Okay then folks, good morning, thanks for coming. Hope you're enjoying the conference so far. My name is Matt and today we're going to talk about .NET without Windows, which of course means it's a .NET core talk. We're going to have a look at what it means to build and
00:23
run and deploy and debug a .NET core application without having to use Windows, without using Visual Studio. The first thing we need to do really is kind of ask ourselves why. Why are we interested in doing this? Why do we want to run .NET without Windows? And of course the answer is of course because all developers love Macbooks and we're all sick and tired of running Windows on a VM.
00:43
Although of course if you want a slightly less flippant answer, probably a couple of things you could say here. Firstly I think there's a decline of the monoculture, the idea that Microsoft has to be the entire stack top to bottom. We've had more of a sort of a rise of the polyglot programming,
01:02
so the idea of using different tools, different languages, different operating systems with the right tools for the right job. We've also seen in recent times the rise of the DevOps culture, more specifically the idea that you can sort of automate your infrastructure. It's got it repeatable, it's immutable and you can automate it.
01:21
And Windows doesn't really fit into this world at the moment. So they're working on that with Nano Server and it's going to be much more scriptable and workable. But right now the majority of the tooling around this is really focused around the Linux space. And the third reason is the cloud. Running your servers on somebody else's hardware is a great idea.
01:41
It's nice being able to scale up and scale down as appropriate. But when you pay for this and you pay per the size of the files on disk and the size of the memory footprint that you've got, then Windows can be a bit heavy for this. Windows Server is several gigs, whereas Linux is several hundred megabytes. When you install Windows Server you've got more files on disk
02:03
than you're actually going to need. You're not going to use COM, you're not going to use WPF, you're not going to use Notepad or Explorer. And this just kind of bloats in what you've got on your disk and increases any kind of surface area you've got for security attacks and means you've got more reboots and so on. And this is definitely the use case for Nano Server in the future,
02:22
which is a much more stripped down version of Windows, which is, again, several hundred megs similar to Linux. But Linux is there now, so we want to really have something within that space which we can reuse our skill sets as .NET developers to implement applications.
02:42
But it's not just .NET Core. We shouldn't just totally focus on .NET Core. We've been able to do cross-platform for a good while now. Mono has been around since 2001, since pretty much the start of the .NET framework itself. It's cross-platform. It runs on Linux, on Mac, on Windows, even on your PlayStation,
03:00
which is pretty cool. The other interesting thing is that it's not just for server applications. So you can do GUI applications with it. GTK Sharp is a cross-platform GUI toolkit, so you could do desktop applications. The other thing to say about Mono is that it's open source, which means that you can contribute to it. But also, and anecdotally really,
03:23
it means that there isn't a big corporation behind it like Microsoft to put in necessarily the resources that you'd require for such a big project. So anecdotally, you are more likely to encounter incompatibilities with the .NET framework and other issues which can cause you problems.
03:43
For example, the current conversation around .NET Core is that it is faster than Mono. So this is a good thing here. It also works both ways as well. So because Mono is open source, it can take code in, and because .NET and .NET Core is open source, then they can pull those codes in.
04:01
So Mono has seen a number of things brought in from the .NET framework. They've replaced the thread pool implementation with the one from the .NET framework. Just the other week on .NET, Miguel was talking about the number of class libraries that have changed, and depending on how you count, it's between 40 and 60 percent of the base class libraries have been updated with code from Microsoft.
04:22
They're also looking at bringing the garbage collector in as well. And then we've got Xamarin, which is perhaps Mono's biggest sponsor. They provide cross-platform support for the Mac, for iOS, for Android, and the thing they add on top of Mono really is some platform API binding so you can do native applications.
04:42
Everything is statically compiled ahead of time, statically linked, so you don't deploy the runtime. You've still got garbage collector, but you don't necessarily have things like the JIT compilation. This has also been recently open sourced with the acquisition by Microsoft. Again, the interesting thing I want to point out here is Xamarin.Forms.
05:00
Again, it's about cross-platform desktop applications and GUI apps and having a native-looking field by abstracting the native widgets, building a XAML toolkit or framework that works with the native widgets and gives you the native-looking field.
05:20
That gives you a common subset of functionality, but it gives you then an escape hatch if you want to get into more rich and more native functionality. And this is there for iOS, for Android, for Windows Phone, and the interesting thing is there's a WPF backend which is nearly finished. So this could be an interesting thing to watch for doing cross-platform desktop applications.
05:43
And then Unity. Unity is a huge thing as well. The website says they have 4.5 million registered developers. If you haven't used it, then if you've downloaded a game on your mobile phone, chances are it's powered by Unity. It's a native game engine, but the logic behind the games can be powered by .NET, by Mono.
06:01
And this is very much cross-platform as well. iOS, Android, Windows Phone, Windows, Mac, PlayStation, Xbox, virtual reality things, and even Tizen. Anybody know what Tizen is? More than me. Well done. I've got no idea. So that brings us to .NET Core. I kind of assume all of you have heard of .NET Core,
06:21
but just to kind of quickly recap, it's a new .NET stack from Microsoft. That means it's the full stack, top to bottom, the CLR itself, the runtime, the JIT compiler, the garbage collector, and it's the base class libraries as well. System.threading, collections, collections immutable, XML, HTTP, and so on.
06:41
It's not brand new. It was initially forked from the .NET framework, so it is based on tried and tested code, and this is now cross-platform. This is a big thing here. It works on Windows. It's also going to work on Nano Server, which is a good thing, and also runs on OS 10, various flavors of Linux, and also FreeBSD. FreeBSD is in brackets here because it's not listed
07:01
as one of their officially supported platforms, but it does run on there. It's open source as well. It's hosted on GitHub. You can get the source, build it, contribute. You can interact with the developers. You can raise issues and so on. It's all good. And the other big thing about it really is that the base class library has been very much refactored.
07:21
All of the assemblies have been split down into more of a fine-grained set of collections. So collections API, for example, is a good one. You'd have system.collections, and collections immutable as separate assemblies. You've got threading as one assembly, threading tasks as another. And the same with things like IO. Zip files would be different to drive info,
07:40
which is different to file info. All are separate assemblies. And NuGet is everywhere. Every single assembly is packaged as a NuGet package. The runtime is also a NuGet package. This is a big deal with .NET's core. I'm not going to spend too much time on this, but this is kind of the way that compatibility is going to work with .NET core.
08:01
This is worth looking at in more detail at the docs on GitHub. The idea of the .NET standard platform. This is a virtual platform which other platforms implement. So it's kind of like a specification, really. It's a common subset of APIs that are available on a particular physical platform.
08:20
And it's versioned. And each version is sort of backwards compatible. The APIs in that subset are additive. So for example, you've got .NET platform standard 1.6. And the platforms that currently work with that are .NET core 1.0 and the .NET framework 4.6.3. The idea of this is that it kind of replaces
08:40
the portable class library idea. Portable class libraries, they are not extensible. So if you have a library that targets a portable class library, that specifies the list of all the platforms that it actually supports. And if you add a new platform, it's not supported. So this idea of having this kind of virtual API abstraction specification kind of gets around that.
09:03
As long as the platform conforms to one of these standards, then it can consume stuff. The idea is that as a package author, you target the lowest .NET standard possible. And in that way, you then get the widest reach of actual platforms. So for example, if you targeted 1.6, your library would only work on .NET core 1.0
09:24
and .NET framework 4.6.3. But if you targeted 1.3, for example, you can run on .NET framework 4.6 and above. You can also run on Windows 10 applications and also, of course, Mono. And likewise, if you run on 1.1, then you can run on all the platforms that 1.1 supports.
09:42
Application authors will then target the actual platform. So you'd still target .NET 4.5.1 if you're on .NET. Or you could do another new one here, which is Netcore App, which is an application for .NET core. Now, I don't think we can talk about .NET core, really,
10:02
without talking about some of the recent angst in the community in the early adopters and a bit of its image problem. I think this image here from one of MSDN blogs is a good sort of metaphor for this, really. At the bottom layer here, we've got .NET core. That's the runtime, the base class library. It's all nice and neat and lovely and ready and everything.
10:22
Next layer up is ASP.NET core, which relies on .NET core below. And again, that's nice and neat and ready and everything. And then at the top in this little kind of thing, not quite fitting in and sort of sticking out, we've got Visual Studio and the tooling and everything. And this is kind of the situation we're in. So to briefly recap some of this,
10:41
up until sort of release candidate one during development, everything's moving along nicely. We've got the cross-platform ports. We've got the refactored base class library. We hit RC1. We get a go live license. Everything's good. And then after RC1, it's announced that they're going to replatform. That means that the tooling is going to get a complete rewrite. This is a breaking change on top of RC1.
11:03
It makes sense. Having had a look at the platform, you can see that it's actually really quite focused on ASP.NET development and doesn't necessarily focus on some of the other platforms that .NET Core would like to address. And so there's been a rewrite of all the tooling there.
11:20
But we're then left in a situation where we've had a go live license for RC1. We've had lots of breaking changes for RC2 and the tooling. And right now with the release, we've got the .NET Core, the bottom layer. We've got the middle layer with ASP.NET Core. They are release candidates to status. They're going to RTM at the end of June. But our tooling is at preview one.
11:42
And that's just a bit kind of weird. And then on top of that, we've got changes to the project formats. So the project format file right now is project.json. This is going away, which makes giving a talk about it fun. But the idea, again, having a look at what it does,
12:00
it's very much again focused on the ASP.NET side of things and the Node.js type of working. And it's great for simple applications, simple libraries. But if you want to do something a bit more complicated, then there's kind of not enough scope to work with that and to get that done. So Microsoft could invest time and effort
12:21
to increase what project.json does, make it more flexible and more powerful. Or they could turn around to their existing solution to this problem, which is MSBuild. And that's what they're doing. So they're rolling back changes in project.json and they're using MSBuild and CSProj files. That then gives us a little bit of a dilemma.
12:42
Do we port now and migrate everything to project.json just for it to return back to CSProj files, or do we hang on and wait? The tooling is going to help with this. The tooling is going to make this a bit somewhat automatic. But then that's due with Visual Studio Next, which we don't really know what the RTM is for that. Sometime about November is kind of the best we know.
13:04
So there's kind of a couple of frustrations about this. And then there's another thing. So we've kind of, after the RTM, there are plans to greatly expand the API surface. This was already part of the plans. It was already going to happen. The API service and the net standard was going to increase and improve.
13:22
But it looks like some of the APIs that were removed from .NET Core and the net standard were decided to be cut to sort of improve the developer experience. And these are now going to get put back in again. And this then sort of gives us a bit of an interesting
13:40
dilemma with this here. So if we now have a net standard 2.0, which implements a whole bunch of APIs that were previously cut, .NET Framework 4.5, for example, could implement all of those APIs. But how is it now going to support net standard 2.0? So you're going to have code in net standard 2.0, which can't work on 4.5.
14:05
So this all looks very much like it's associated with the Xamarin acquisition. The target APIs that are going to be implemented are pretty much the same as Mono's model platform, which is Mono's subset of APIs of the .NET Framework that it implements.
14:20
And reading between the lines there, does that mean that .NET Core is now starting to target Xamarin and Unity? There are questions really, does this harm adoption? Should I bother porting right now if it's going to sort of be easier later? Because if I'm going to go back to CS Proj file, I don't have to convert my file format. I don't have to work around any API changes that are there.
14:41
So from our point of view at JetBrains, we've got Project Rider, which is going to be our .NET IDE. We run ReSharper at the moment on Mono when we're running it across platform. We want to put that in .NET Core because we've been told Mono .NET Core is going to be faster. But we've got about 300 projects to convert. So right now we'd have to convert 300 projects
15:02
to project.json, fix up any API changes, or we could just wait. And waiting looks a whole lot easier. The other thing is, does this change the vision of .NET Core? If we had something which was kind of small, focused on nice layering, on the nice refactoring of the base class libraries, does this kind of change the vision by greatly expanding the APIs like this?
15:22
And right now, this is kind of early days really. We don't know enough detail to know how this is going to affect things. But don't panic. This is all okay. This isn't too bad. This is the very top layer that we've got going on here. The bottom layer is still good. The .NET Core and the ASP.NET Core is good.
15:41
And most of this really is a timing and communications issue. If this had happened during beta, this would be fine. We wouldn't bother about this. But it's happened during release candidate. And that kind of makes things a bit tricky. And it's not the best timing. But we can work around it. We can work with it. This is a great quote by Nick Craver saying about the project, it's not developed in the open, it's coded in the open.
16:03
And this is the thing. The decisions are made behind closed doors. That's not necessarily a bad thing. For example, the Roslyn projects, all of its language design meetings happen behind closed doors, but they're minute and put on GitHub and discussed. So it's all fine, but we all need to kind of adjust to this and get used to this idea that it's still Microsoft's project,
16:21
these changes can happen, and it's okay. We just need to make sure that the communications around this happen as well. It's all recent news. Dust will settle. It'll move on, and it'll be okay. The changes all make sense as well. So it's actually going to make things better. The new command line tooling is better. It's more extensible. It's better focused on tasks
16:41
that we want it to be able to do. The project.json changes are going to be good because we're going to have projects that do need the power of MSBuild and do need to do extra interesting things like that. And also the idea of the extended API set. It is going to make porting code easier. And if we can get more code onto the new platform,
17:00
it's going to be better. So the changes do all make sense. We also have very smart men and women working on this as well. So it is a good project. It's going to come together, and it's going to be okay. And the other thing to point out, to reiterate as well, despite any kind of controversy we've got at the top, the .NET Core and the ASP.NET Core layers, they are definitely solid.
17:20
They are good quality, and they're stable and everything. And everything is kind of genuinely ready for RTM. The other thing to point out, I know it's not terribly easy to read up that, is that Microsoft are very much aware that CS Proj files are horrible. And project.json files are much nicer and simpler and easier to use.
17:41
And they're going to be aiming to work towards this. So we've got most of the stuff in the CS Proj file on the left there. It's there for Visual Studio. And they also control Visual Studio. And they're rewriting the project system for Visual Studio Next for C Sharp. And they've already got an issue which is tracking this and trying to reduce the amount of cruft
18:01
that is in the file there. I don't think it'll ever get to the simplicity of project.json, but it can certainly get a bit close. Right, that's enough about that. Let's actually start talking about .NET Core outside of Windows then.
18:22
Okay, so the first thing you need to do is get .NET Core actually installed. You can get it from this URL, which is clearly our URL which is designed to be written down and not said out loud. Really, www.dot.net. It's too much. Although, to be fair, it is just shortened to .dotnet,
18:40
which is clearly better. And once you've got that, then it's time to create a project. So what we're going to do now is we're going to switch to the command line. And obviously, everything is very much command line driven. You're all familiar with that if you're not working on Windows. And the first thing we need to do is run the .NET command line tools.
19:02
And we can do .NET new. And we've now got a simple sample application built in a file here. So now the .NET tools, it works kind of like Git where you've got a driver application, .NET, and then you've got a bunch of subcommands. And those subcommands will do interesting stuff for you. You've got new, you've got restore,
19:21
which will do something like NuGet restore, build, publish, run, test, and so on. We'll have a look at some of these as we go through. Okay, so we've got various files. We'll have a quick look at those. Program.cs, it's a simple hello world application. The interesting thing to point out is that we've got a static void made here.
19:42
So this is going to be a console application. And the next thing to look at is project.json. This is our file format. And this is kind of fairly simple. There's not much going on here. We've got a version number of the thing we're going to build.
20:00
And then the other two elements we've got are frameworks and dependencies. The frameworks tells us what framework we are targeting. And here we're saying I'm targeting Net Core App 1.0. This line here, the imports, is a bit of a backwards compatibility thing. It's saying that I'm going to build a Net Core App 1.0, but I can also consume DNX Core 50 stuff.
20:21
This is kind of one of the names that got used in NuGet packages as .NET Core was evolving. And we're saying that until everything has kind of been updated and moved on, I can still consume DNX Core 50 libraries. The other dependency we've got is on a package called microsoft.netcore.app.
20:42
So all the items in the dependencies list here are packages. They're NuGet packages, and we can just consume those. This one is the standard package for Net Core applications. And we get to specify the version, RC2 version. And we've also got a type of platform. I'll come back to that later.
21:00
So the next thing we need to do is .net restore. This is a NuGet restore, and it will go off and it will download absolutely everything. It will download the microsoft-netcore-app package and all of its dependencies. And fortunately, I've done this earlier, and it's all locally cached, because there is a lot of them. So all the packages are...
21:22
No, can't spell. All the packages are cached locally and sort of globally per user, and so you've got a nice, easy way of pulling and restoring without necessarily having all the pain of having to download everything all the time. And there's a whole bunch of different packages going on in there.
21:41
So we can see there's some Microsoft ones. We've also got the system-type ones there. These are the nicely factored base class library. And we've also got the runtimes as well. So the actual CLR itself is pulled down as NuGet packages. And once we've restored
22:00
and we've got our NuGet packages all downloaded, we end up with a project.lock.json file, which is a massive JSON file which we don't need to worry about the contents of, but basically it lists all of our transitive dependencies from our packages. So rather than having to walk all the packages again every time it needs that information, it can just pull it straight from the lock.json file.
22:27
Okay, next we can do .net build. This will compile the app for us. And once we're done, we've got a bin and an object folder. We've got a debug folder underneath the bin. And we've also got netcoreapp 1.0 underneath that. We can target multiple frameworks,
22:41
and so everything is handled, is put under a directory under that. And in that folder we've got several files. We've got a couple of JSON files, which are all about the runtime information. But the important one there is we've got simple.dll and a pdb file for debugging as well. Now, interestingly, we have a dll file
23:01
even though it's an executable. This is because even if it was a .exe, we wouldn't be able to run it because I'm on a Mac. You can't run exes on that. So to run it, we've got two options, really. We can do .net run, and that will sort of run the project. It'll make sure everything is compiled and up to date, and it'll run it. Or we can get to the dll itself,
23:22
and we can do .net simple.dll, and it'll just load that dll and execute it and run it. Okay, so that's running a very simple project. Now, that's good, but that's not particularly that much fun. So it is not that interesting, so we could really kind of create something
23:42
a bit more interesting. And so how do we create an ASP.NET core application? We don't have Visual Studio, so we can't use Visual Studio templates. .NET new has a type parameter to it, and so it looks like you could perhaps put in something interesting here and generate something with a bit more fun going on there.
24:01
But it's only implemented for console, so you can do .net new type equals console. That's all you've got. There are a couple of NuGet packages which can extend the .net command line tooling. There is one for web code generation, but it doesn't seem to do anything yet. It's not documented yet, so maybe this is how it'll work in the future. I don't know. There are existing packages which extend this
24:21
for entity framework and publishing to IIS. So this could clearly be the way to do it. So what we'll do instead is use Yeoman. Yeoman is a node-based scaffolding app which is extensible, and it's for creating web applications to start with, really.
24:41
The OmniSharp team have created a generator for ASP.NET Core, and we can use this then to get ourselves started. We've got the steps here to actually get it started. You need node install. You need Yeoman installed. You need Bower installed. Bower is a front-end package management for CSS and JavaScript files. And then you need the generator installed.
25:01
And then you need to run Yeoman with YoASPnet, which is clearly, I'm too old to say and get away with any kind of cool thing. But it's easy to run. We will do YoASPnet. And now we get a choice of options of things we can build here.
25:21
So we can build an empty web application. This is probably the one you'd pick to get started here because it will just give you the framework to get going. You can have a console app. There are a couple of demo web applications which are going to be useful. You can do like a web API application, Nancy class library, and a unit test application as well. So we'll just create a simple web application,
25:42
and we will just use the default values there just to sort of get us up and going. So it creates a bunch of files for us. Then it runs NPM install and Bower install to make sure we've got all of our client-side JavaScript type files, and we're done. And if we go into web application basic, we've got a lot more files here.
26:01
So this is a much more interesting project to get started with. And if we have a look at the project.json, let's just get to the top of the file, you can see that there's a bit more going on here. The dependencies is a bit bigger. We've got more things going on. We've got a Microsoft Net Core app here again. So we're still a .NET Core application, but we've got extra things on top of that.
26:22
We've got ASP.NET Core packages and various extensions as well. We've also got a new element here for tools, which means that we can extend the .NET tooling with various packages as well. So if we go to .NET, now we can do .NET Razor tooling, and that gives us command line tooling
26:41
to work with Razor files there. Other sort of interesting things we've got in here, we can specify runtime options to use the server version of the garbage collector rather than the desktop version, and we can run some scripts when we're publishing as well.
27:02
Okay, so we need to do .NET restore again, and again this will sort of trundle through. I've got everything cached locally, so it's all nice and quick. It's created our lock file so that we've got something to build against. And we can do .NET build, and it'll go off and compile it.
27:21
And then we can do .NET run again. And now we say that we're running on local host 5000. Oh, clear the screen rather. Let's just open a web browser, and as that loads up, we're hitting the view,
27:41
we're compiling the views, and in fact, if we go back to that, we can see that there's logging going on on the screen as we sort of click around and move everything, and so there. So we can run an ASP.NET Core application on the Mac.
28:02
So let's have a look at the code, and that's probably a good time to switch over and have a look at editors. What tools can we use when we're not on Windows to edit and work with our projects and applications and everything? So I'd like to introduce you to Vim. So this handy chart here, I'm just kidding.
28:22
So we've got several different options we can do. Vim is clearly a very capable editor, and we won't go into that. We've got several options here. We've got a couple of IDEs that we can use and a couple of editors that we can use as well. JetBrains Rider, .NET IDE, which is using ReSharper in the back end, that can run cross-platform, and it's good.
28:43
Xamarin Studio has recently just got a plug-in which allows it to open RC2 applications as well, and so you can use that as an IDE to work with your code. And then there's Visual Studio Code and Atom as rich text editors, which, with the OmniSharp plug-in, gives you editing and code completion for C Sharp
29:02
and various projects with that. Okay, so let's just have a look at that. So let's have a quick look. We'll start with looking at things in Rider. So Rider gives you the sort of ID thing that we've got here.
29:20
So if you want to do templates, you can have templates here to create new projects and everything. We can have something which, you know, creates you a .NET Core class library or a desktop-style class library and so on, so we can get our features from, you know, the templates that we'd like from, that we're familiar with with Visual Studio, or we can just sort of open an existing application.
29:43
So we'll open our web application basic here. I cheated a little bit there. I've run a little script here. The IDEs, both Rider and Xamarin Studio, they don't really work with the project.json as a file format. They still require the same thing that Visual Studio requires, which is a solution file and a .xproj file.
30:03
And so I've just cheated and created the .xproj file there. Okay, let's just close those windows. So, you know, we've got an IDE, all the kind of things we'd expect from an IDE. We can see our references. We can see what our package is, and we can sort of drill down into them
30:21
and see then what the dependencies are and then what they resolve to with various assemblies and so on. We can navigate to the program. And now we can see, actually looking at the code, that this is all a bit different to what we'd expect from a web application. So, for example, the big difference here, really,
30:44
is that we're a web application, but we have a public static void main. So we are still a console application, even though we're a web app. What we do is we create a web host builder, and basically we set up a bunch of configuration for hosting a web app, and then we run it.
31:01
There's the short thing. There's a couple of interesting things. We do use Kestrel. By default, we've got to sort of use it, IS integration, even though we're not on windows. And it variously starts everything up. Okay, so, well, we're in the editor here. We've got all the sort of usual kinds of things we can do.
31:22
Sort of, I'll tend to clean things up. Navigate around. Let's go to a HTML file. And we've got all the usual kind of editor features. Where are we? Things like co-completion. We can do things like co-completion
31:41
with the tag helpers. So ASP.NET Core includes the idea of a tag helper, which is a HTML tag which runs server-side, which runs as part of the CSS HTML processing. And while it can look like a real tag, it's got some additional processing on the top. So, for example, we can have a link to an ASP action here.
32:00
And then we can sort of provide those as co-completion and sort of navigate around and move around to all those kinds of things there. And we can do a similar sort of thing in code. So I've got Visual Studio code here. This works in a different way. It doesn't work with project files and solution files. It works with folders. And so what we can do here is open a folder.
32:22
And there's my web application basic. If I open this up, code sort of restarts. And it takes a moment, and then it notices that actually I can work with this as a project as a folder and ask you if you want to create some files. And it creates this VS code file
32:41
with some config in there, which helps. And again, we get sort of similar sort of functionality that we are used to with an IDE. We've got, you know, tool tips and auto-completion. Let's just put this in, because I'll need this later.
33:03
So if we hover over everything, we're good there. We've got navigation. We've got squigglies, and we can sort of fix that. We can remove unnecessary usings and so on. So we've got ways of editing and doing rich editing and IDE-type functionality then on different platforms.
33:25
Let's just go here. We can also set breakpoints. We can do debugging as well. So we can switch the debug window. We can put a breakpoint in our code. We just press go. It'll make sure everything's up to date, and it won't be because I've just changed things. It'll rebuild it, and then it'll run and start debugging.
33:47
Okay, so let's just start the browser again. And it'll just hit the first view. It'll compile everything.
34:01
And I'll put the breakpoint in about, so if we click about now, bang, we've hit our breakpoint. And we've got variables on the side here. We can sort of drill into that, and we can see the values that are set there. We can highlight and right-click and evaluate. And it's down in the debug console down here.
34:22
We can also set data. And if we sort of run and carry on, then it comes through and everything. So we can do debugging as well. So we've got editing. We've got projects. We've got debugging.
34:40
We've got refactoring. We can do all these kind of things without having to use Visual Studio. Okay, so what's next? Testing. Testing. Actually, let's switch straight back to the console. We can use EOS PNET again for this one, and we can create a unit test project. Again, I'll just take the defaults.
35:03
And we'll do a quick restore. We've got, so X unit is the default. Well, it's kind of the de facto standard for running tests in .NET Core. It's basically the first framework that got ported over. There are also frameworks that support MS test,
35:21
and N unit, I believe, has a framework. I think it's N unit lite that they use. And you can use whichever one you want there. And if we have a quick look at the project.json here, we'll see that this is handled nice and easily by taking on a dependency on .NET test X unit. This is adding the test runner into the tooling.
35:44
And we've got X unit, which is our dependency for actually using the X unit API. We're also saying that the test runner is X unit, and that sort of enables it within the tooling. So we can do .NET run, and we can see that it will immediately fall over
36:04
because we're not a console application. If we have a look at the code, we can see this is just a class. So we're just building a class library here. We're not building a console app like we did with our simple demo with the web application. So we've got a simple test here. We've got two tests. One passes, one fails.
36:22
And to run those, we just use .NET test. And that'll make sure everything is compiled and up to date, and it'll run it. We can see that X unit does discovery, and then it actually runs the tests. It prints out anything that fails, and then we get a nice little sort of summary
36:40
at the end there. And so we can do testing as well. So we can create a project. We can edit it. We can do refactoring and building and debugging. We can test it. The next thing we want to do is hosting. And hosting. So how does this work in the world when we don't have IIS? How do we do testing?
37:00
Sorry, hosting. And everything is a console app as well. So if everything is a console app, how does this all work? Well, we could have seen it with the web application basic there. It's a console app. We configure everything all up, and then we run it. And this basically means that we are self-hosting. We have an in-process web server, and this is Kestrel. There was a great talk yesterday.
37:20
Damian Edwards and David Fowler were talking about the internals of Kestrel. They've done crazy things to optimize it. It is very, very fast. It's all based on libuv, like Node is, and it's all sort of very much sort of async-await and efficient, and they've reduced all the allocations they possibly can, and it is just fast. So it's a great stat.
37:41
2,300% more requests than an equivalent benchmark on ASP.NET 4.6. That's pretty fast, so that'll be good. But don't expose it to the Internet. The recommendation here is that you do not have this exposed to the Internet. While they've made it as secure as they can, it's not battle-tested. It's not battle-hardened or anything.
38:02
It's not designed to be exposed to the Internet. Also, you're self-hosting, so it's a different thing. So what do we do now? We want to deploy it. We want to get it up and running to be able to host it properly. We need to do packaging, and this is .net publish.
38:20
So we're back to the command line again. Let's go back to our simple Hello World application, and we'll package this up ready to go. It's all nice and easy. We just do .net publish. That'll compile it and make sure everything's good, and if we go into the bin, debug, netcoreapp 1.0, publish folder, we're going to see
38:40
these are all the files that we need to deploy. And here, it looks just like what we had before. Just in the debug folder, there's our simple.dll, the pdb file, and a couple of runtime JSON files. In fact, if we... Let's just... Let's just go into that folder.
39:00
We can just do .net simple.dll and run it, and it's fine. Now, one of the premises of .netcore was that you could do application local installs of the .net framework. And clearly here, there are no dependencies going on here. The .net framework isn't being packaged up as part of all of this.
39:21
So what we've created here is what Microsoft are calling a portable application. This means it is portable to anywhere that already has .netcore installed, and so it can be reused anywhere. .netcore can run it and sort of resolve everything and work with it. And the thing which drives this
39:43
is this, the type equals platform, property of the dependency here. So what we're doing here is we're saying that the Microsoft .netcore app dependency is a platform dependency. It's already there. It's installed and handled by the platform. And when .net publishes, packaging everything up,
40:00
it sees this, and it knows not to pull all of that in there. We're telling it that it's going to be on the target platform when we get there. We can build a standalone application, and a standalone application will have all of its dependencies in, and we do that by getting rid of the type equals platform. Now, I'm just going to again cheat
40:25
and copy this in because there's an extra bit you need to add, which I will fat finger if I'm going to do it live. So we've got rid of the type equals platform from Microsoft .netcore app, and then down the bottom we have to add in a new element,
40:41
the runtimes element. Because we're saying we're going to run on a platform which doesn't have .net installed, there's no smarts there to figure out what platform the .net actually supports here, what runtime it is. So we have to tell the packaging .net publish what runtime we're targeting. So I'm going to run on my back here,
41:02
so I want to target the OS 10 runtime. And now I've changed the project .json, so I have to do another .net restore. And if I do .net publish now, it should build us a standalone application. I'm going to also add the minus C flag, which means I'm actually going to build
41:20
in release mode now. And so we've got a release mode application. And if we go into bin, we've now got debug and release. And I can go into netcore app 1.0. I don't have the publish now, I've got an extra folder which is my OS 10 folder, so it's saying that this is now not only framework specific,
41:40
but runtime specific. And I've now got a publish folder under that. And if I list that, I've got a ton of files, and this is my full dependency set now to do a full standalone application. And now to run this, I can't use .net and the DLL name, but fortunately the .net publish
42:01
has given us an executable here, so I can just run simple from the current directory, and it'll do my hello world. And so we can package everything up. We can package up it as a portable application, or as a standalone application. Right, so let's have a look at that,
42:23
how that works then with sort of a web application, and how that sort of fits together. So we can just do the same thing. We can just do .net publish minus the release. And that'll go off and build the application in release mode.
42:41
It'll run a few more steps because the project.json had some pre-publish scripts which would run some Grunt and Gulp tasks for our CSS and JavaScript. And then we're done. So if we go to bin, we've got a debug and release again, so we're going to release, and we can go to publish, and if we list that,
43:01
we've got a ton of files. But this project was set up to be a portable app. So it wasn't saying, including the net core app stuff, that is still set to be a platform dependency. But we've still got a load of files here because these are the dependencies on top of the platform. So if we just have a quick look at the project.json,
43:29
have a look at my dependencies here. Microsoft net core app is still a platform dependency, but we've also got a whole bunch of other dependencies on ASP net core and various extensions and so on.
43:41
These all need to be distributed when we're packaging things up as well, and that's what these extra files are in here. And we've also got then the main application. This is our program static main, and we can run it by doing .net webapplicationbasic.dll.
44:03
No, because I forgot to stop that, and the port is in use. Okay, and we're listening on port 5000 again. Right, so that's all good for packaging.
44:20
We can package our application up. We know now how to deploy it because we just need to basically take all of the files in that folder and put it on a server somewhere and run that. If we're doing a standalone app, we can just run the executable that .net publish creates. If we're running a portable application, we need .net installed on there already,
44:41
and we can just do .net and the dll name. But that's no fun because we want to use containers because everybody wants to use containers. So if you've not used containers before, the idea of this is that it's a packaging format for packaging up an application on all of its dependencies and running it in isolation.
45:03
The key thing is that it's not a virtual machine. What it is is an isolated process group that runs on a shared Linux kernel. So the idea is you've got a Linux kernel at the bottom here, and then you can run a container which kind of sits on top, and you can run multiple containers on the same Linux kernel, and they are isolated from each other.
45:22
So when you have one container running, it thinks it's the only thing running on the Linux kernel. It thinks it owns that kernel. And the important thing to point out is that right now containers are all about Linux. It is a Linux technology. Microsoft have got Windows containers coming in the next version.
45:41
In fact, I think they've got Hyper-V containers in the current preview builds of Windows 10. But right now, when we're talking about containers, we generally mean Linux containers. And this next bit, I wish they'd put this on the website. It took me ages to kind of figure this one out. But if you are running a container on Windows or Mac, if you're trying to run Docker
46:01
or any other kind of container on Windows or Mac, you need to have a virtual machine which runs this Linux container. Sorry, this Linux kernel. It's all about Linux is what we're doing here. And what you need then to put things into a container is that you need to create an image to run in it. Okay, and that's all nice and easy.
46:21
So what we want to do is have an image which basically contains all of these files. So what we'll do is we'll grab a Docker file and pull it in. And if we have a look at the Docker file, it's actually really quite straightforward. We've only got a few steps here. We're saying, the first line is a from command, and we're saying, I want to build an image based on this existing image.
46:43
An image is the Microsoft.net image which is packaged by Microsoft. It's a version of Debian, I think it is, which has .net already installed on it for us. And so we can build on top of this. We'll have .net installed, and we can put our portable app on there and run it. So the next line is to just copy the current directory,
47:01
which is our portable app files, and put that into the slash app folder. We change directory to slash app. We use the expose command to tell Docker that we're going to be listening on port 5000. And then we run the application. We don't run .net and the DLL name itself. So it's all nice and easy. There's only a few steps, and it's all straightforward.
47:22
And now what we need to do is build, let's call it demo in the current folder. And that will build a new image based on the Microsoft Docker image that we've got. So if we list our images now, we can see, let's just pull that out a bit.
47:40
We have two images now. I've got the Microsoft.net image, which I downloaded previously. If it wasn't there already, Docker build would have downloaded it for me. And then we have my demo image, which we've just created. And now I can run it. And very importantly, I need to tell Docker to expose port 5000, that I want to use port 5000.
48:03
I'm going to run it interactively, so I can do Control-C and finish it. And there it is. It's running. Oh, yeah, I should point out that I have, don't start Windows 10, that would be bad.
48:20
There we go. So I have my Docker instance running. I have my Linux virtual machine here. That is my shared kernel, which is all the containers are going to run in. So that's already running. And let's just open up the browser. Localhost 5000 and run it, and it fails.
48:42
And this is, again, because we're running in a virtual machine. Our Linux kernel is running in a virtual machine, which has its own IP address, and which is separate to localhost. So what I need to do, is I need to get the IP address of my Ducky. I'm not sure you can see that.
49:00
So I can ask Docker what the IP address of the shared Linux kernel is, and it'll give me here. And then I can point the browser at that. Let's just do that again. And the browser will now talk to the shared Linux kernel, port 5000, which is then being forwarded to the container,
49:21
and I can actually display that. So now we are hosting our application and running it in a Docker container. But we're doing that with Kestrel, with our self-hosted web server, which we said don't expose that to the internet. It has been battle-hardened. You want to put something in front of that. And what we want to do now,
49:41
is we want to put a reverse proxy in front of it. This is a bit of kit, which will actually be the interface to the internet, and is something which is designed to do this job, rather than Kestrel, which is sort of designed to do self-hosting and be as fast as possible. So the idea of a reverse proxy is, you're most likely very much already familiar
50:01
with a forward proxy. If you've ever worked in a corporate environment, and you've had to configure your browser to talk to a proxy to get your web pages, then that's a forward proxy. Your browser knows about the proxy. It talks to the proxy and says, go and get me google.com. Go and get me another site. Reverse proxy kind of works the opposite direction.
50:23
The client thinks it's talking to the end server, but the reverse proxy is then talking internally to another server. So it allows servers to be contacted by any client, rather than a client talking to any server.
50:40
The easiest way to think of this is as a load balancer. A load balancer is a perfect example of a reverse proxy. So we're just going to step back out of this a minute. How would this work in the IIS world, in the Windows world? Because we're all used to how ASP.NET's apps are hosted in IIS. But for this idea where we've got executables
51:01
and reverse proxies and everything, how does this work in IIS? And the answer is to use the HTTP platform handler. This acts as a reverse proxy. It does process management. So it would start up the executable, the .NET DLL. And this is how it would work for things like Ruby applications as well, where they are run essentially as an executable,
51:21
as an out-of-process executable. The module is responsible for forwarding the request from these external processes, these child processes. And it's responsible for also telling the child process where to listen to. When we're on Linux and everything, there are several options here.
51:41
You've got things like nginx, HAProxy, HTTPd. And this is where you want to speak to your certified DevOps engineer and not listen to me. And you get the best solution for the job here. These are reverse proxies and load balancers. HAProxy is a big one used by GitHub, StackOverflow, Twitter. Nginx is also huge and used all over the world as web. But it also provides extra functionality
52:00
like web servers and HTTP caches and so on. And these are very easy to do. So I've got a config file for HAProxy here. And there's a bunch of sort of defaults at the top.
52:21
The interesting thing is down here. And what we need to do is we kind of listen on port 5,000. And then we can forward it onto a server, which I've called Docker 1. That's my IP address in port 5,000 there. So I can just do HAProxy, which I've got installed on my Mac.
52:41
And I can pass in the config file. If I swap back to the browser and go to local host, before I refresh that, I've now got my reverse proxy in place. So I'm talking to local host, which is my reverse proxy, which then forwards the call into my Docker container. And if I had multiple instances there, I could use that as a sort of load balancing
53:01
and sort of round robin or whatever technique I want to navigate around them. OK, so now we've been able to create. So that's basically it. Then we can create an application. We can edit it. We can debug it. We can refactor it. We can use IDEs. We can use text editors.
53:21
We can package it up. We can publish it. We can deploy it. We can put a reverse proxy in it. We can host it. So we can do everything that we need to do with an application outside of Linux. Sorry, outside of Windows and on Linux. So that just leaves me really basically to say thanks, and I'm just glad I've managed to get to the end of a .NET Core Talk without anything changing.
53:40
So it's all good. So we've got a few minutes. If anyone has any questions, please shout out. If not, come and grab me later. And thank you very much. Yes, question.
54:03
While running in Docker, you can't debug. You can do debugging, but you have to do a couple steps to actually get that working. I'm not going to be able to show you with the time we've got. But yes, you can do remote debugging as well.
54:43
Hello.