.NET 2015, ASP.NET 5, C# 6 e tudo mais
•Transferir como PPTX, PDF•
1 gostou•347 visualizações
O ASP.NET e o .NET estão tomando um novo caminho que muda completamente o que conhecemos: com o objetivo principal de ser cross-platform, você será capaz de programar em C# para todas plataformas existentes hoje
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a .NET 2015, ASP.NET 5, C# 6 e tudo mais
Semelhante a .NET 2015, ASP.NET 5, C# 6 e tudo mais (20)
Mais de akamud
Mais de akamud (18)
Último
Último (9)
.NET 2015, ASP.NET 5, C# 6 e tudo mais
- 2. ♥
- 3. ♥
- 9. .NET API for Hadoop WebClient .NET Compiler Platform ("Roslyn") .NET Map Reduce API for Hadoop .NET Micro Framework ASP.NET MVC ASP.NET Web API ASP.NET Web Pages ASP.NET SignalR MVVM Light Toolkit .NET Core 5 Orleans MEF (Managed Extensibility Framework) OWIN Authentication MiddlewareRx (Reactive Extensions) Orchard CMS Windows Azure .NET SDK Thinktecture IdentityManager WnsRecipe Mimekit Xamarin.Auth Xamarin.Mobile Couchbase for .NET Meet the people behind the .NET Foundation http://www.dotnetfoundation.org/teamhttp://www.dotnetfoundation.org @dotnetfdn Mailkit System.Drawing ASP.NET 5 Salesforce Toolkits for .NET NuGetKudu Cecil
- 10. Qualquer app, qualquer plataforma .NET C# VB F# JavaScript
- 11. Inovação .NET Cross-PlatformOpen Source O caminho à frente do .NET .NET Core ASP.NET 5
- 13. Windows Desktop App Model Framework Runtime Windows Store Windows Phone ASP.NET 4 ASP.NET 5 App Model Framework Runtime Runtime App Model Framework Runtime App Model Framework Runtime App Model Framework
- 14. ASP.NET 5 App Model Universal Windows Apps Model Any other app model Unified BCL (Base Class Library) Runtime Adaption Layer .NET Native and Runtime Core CLR Other Runtime
- 16. Next gen JIT SIMD Runtime Compilers .NET Compiler Platform Languages innovation .NET Core 5 Libraries .NET Framework 4.6 Libraries NuGet packages .NET Framework 4.6 .NET Core 5
- 17. RyuJIT + SIMD Garbage Collector Runtime components Compilers .NET Compiler Platform (Roslyn) Languages innovation .NET Framework 4.6 .NET Core 5 Fully-featured and integrated .NET libraries and runtime for Windows Modular and optimized .NET libraries and runtimes Base class libraries NuGet packages Libraries
- 20. Demo: Roslyn
- 21. O ASP.NET 5
- 22. ASP.NET 5 .NET Framework 4.6 stack e libs .NET Core 5 stack e libs Framework unificado para MVC, Web API e SignalR Framework .NET completo para qualquer cenário e suporte às bibliotecas Runtime pequeno otimizado para servidores e computação nas nuvens
- 24. ASP.NET 5 e a Modern Web Escolha seus editores e ferramentas Open Source com contribuições Cross-PlatformOSS Transição simples de on-premises para nuvem Ciclo de desenvolvimento mais ágil Totalmente Modular Rápido
- 25. Modern Web – Agilidade Ciclo de desenvolvimento mais ágil • Recursos são lançados como pacotes • Framework é lançado como parte da aplicação Mais controle • Bugs de segurança são arrumados pela Microsoft • Faça suas alterações em um fork do projeto e use-o nas suas aplicações • Atualização de módulos separados de acordo com sua necessidade
- 26. Modern Web - Rápido Performance de execução • Inicialização mais rápida (50%+) • Menos memória / maior densidade (> redução de 90%) • Use um socket, um framework, ou ambos Produtividade de desenvolvimento e baixo atrito • Edite o código e atualize o browser • Flexibilidade de um ambiente dinâmico com a força do .NET • Desenvolva com Visual Studio, editores de terceiros ou editores na nuvem • Padrões da web moderna
- 28. Demo: ASP.NET 5 no Visual Studio 2015 RC
- 29. Modern Web – Cross Platform Editores • Visual Studio, Code, Texto, editors na nuvem • Sem editores (linha de comando) Open Source com contribuições Runtime • Windows, Mac, Linux OSS
- 32. Mono.NET Core cross-platform Desenvolvimento Mobile e parceria .NET/Xamarin .NET Xamarin Unity Services e Web applications Mobile apps Windows Linux Mac OS X .NET Core ASP.NET 5
- 33. • .NET Core already installed as part of VS2015 RC • Clone repo on GitHub and build from source (advanced) • Download & install tar file • Use Homebrew formula on GitHub • Download & install tar file • Create VM on Azure Marketplace • Use Dockerfile on Docker Hub (coming)
- 34. http://brew.sh
- 36. Demo: ASP.NET 5 no Mac com VS Code Vai funcionar? ¯_(ツ)_/¯
- 37. ASP.NET 5 .NET Framework 4.6 stack e libs .NET Core 5 stack e libs Framework unificado para MVC, Web API e SignalR Framework .NET completo para qualquer cenário e suporte às bibliotecas Runtime pequeno otimizado para servidores e computação nas nuvens
- 39. .NET Framework 4.x ainda vai ser o mais usado por um bom tempo .NET Framework 4 .NET Framework 4.5 .NET Framework 4.5.1 .NET Framework 4.5.2 .NET Framework 4.6
- 40. Recurso Rodando no .NET 4.6 Rodando no .NET Core 5 Pronto para nuvem * * Design modular * * Injeção de dependência * * Tracing / Debugging consistente * * Desenvolvimento mais ágil (Sem necessidade de Build) * * Open Source * * Totalmente lado a lado (framework enviado junto com a aplicação) * Startup rápido, pouca memória / alta responsividade * MVC 6 (MVC + Web API + Web Pages), SignalR 3
- 41. Entity Framework 6.x Evolução do EF atual Continuará rodando no .NET Framework 4.6 Entity Framework 7 Suas habilidades em LINQ e EF serão reusadas, fácil de migrar a maioria dos aplicativos existentes hoje Otimizado para nuvem (baixo consumo de memória e alta eficiência) Otimizado para dispositivos (leve, funciona com SQLite) Suporta bases relacionais e não-relacionais Roda no .NET Core 5 e .NET Framework 4.6 Pronto para closs-platform (baseado no .NET Core 5) Feito com cenários desconectados em mente (web services) Ambas são OPEN SOURCE! Acesso a dados / investimentos ORM no .NET
- 42. Participe!
Notas do Editor
- O mundo do .NET está passando por 3 grandes mudanças
- O .NET já tem seu código inteiro liberado para visualização
- A Microsoft tem mais de 300 projetos no GitHub desde que começou. Quando perguntado porque eles haviam abandonado o CodePlex, eles responderam dizendo simplesmente ”o GitHub é onde as pessoas estão”.
- http://dotnet.github.io/ is the list of all the repos and activity for the .NET foundation projects [NOTE: Data was pulled on 1/26/15. Check the upper right of the live site daily to see numbers grow (and adjust slide)].
- .NET Foundation core messaging Description (“what is the .NET Foundation”) The .NET Foundation is an independent organization created to foster open development and collaboration around the growing collection of open source technologies for.NET. It will serve as a forum for commercial and community developers alike with a set of practices and processes that strengthen the future of the .NET ecosystem. Story telling (“why the .NET Foundation”) Two years ago we announced how some key components of .NET such as ASP.NET MVC or Entity Framework embraced a new development process that was more transparent, open, and community driven. Since then, we have only received great feedback from you. Increasing our investments in .NET, while opening the process to the community has allowed .NET to innovate faster with feedback and contributions. With the .NET Foundation we want to extend this new development model to be the norm for .NET and not the exception. We want to make sure that .NET projects (both from Microsoft and from other companies and individual contributors) have a place that provides the mechanisms to promote the openness, community participation and rapid innovation to build the next generation of the .NET ecosystem. Messaging pillars (“what are the top three things I need to know about the .NET Foundation”) It opens the development process for .NET: The .NET Foundation brings into one common umbrella existing and new relevant open source projects for the .NET platform, such as ASP.NET, Entity Framework and the recently added .NET Compiler Platform (“Roslyn”). The .NET Foundation will provide the frame for making this the norm moving forward, so more and more components and libraries of .NET are using an open process that is transparent and welcomes your participation. It encourages customers, partners and the broader community to participate: The .NET Foundation will foster the involvement and direct code contributions from the community, both through its board members as well as directly from individual developers, through an open and transparent governance model that strengthens the future of .NET. It promotes innovation by a vibrant partner ecosystem and open source community: The .NET Foundation will promote commercial partners and open source developers to build solutions that leverage the platform openness to provide additional innovation to .NET developers. This includes extending .NET to other platforms, extending Visual Studio to create new experiences, providing additional tools or extending the framework and libraries with new capabilities. Call to action: Join the conversation We are just taking the first steps in the creation of the .NET Foundation because we want your feedback and participation from the very beginning. We are starting with a core set of participants including representatives for the .NET open source community, partners and enterprises such as Miguel de Icaza and Salesforce for example, who will collaborate to define the frame of the .NET Foundation. You can actually be part of that process too by providing feedback at dotnetfoundation.org. LIST OF PROJECTS (25 initially) .NET API for Hadoop WebClient http://hadoopsdk.codeplex.com .NET Compiler Platform ("Roslyn") http://roslyn.codeplex.com .NET Map Reduce API for Hadoop http://hadoopsdk.codeplex.com .NET Micro Framework http://netmf.codeplex.com/ ASP.NET MVC http://aspnetwebstack.codeplex.com/ ASP.NET SignalR https://github.com/SignalR/SignalR ASP.NET Web API http://aspnetwebstack.codeplex.com/ ASP.NET Web Pages http://aspnetwebstack.codeplex.com/ Composition (MEF2) http://mef.codeplex.com/ Entity Framework http://entityframework.codeplex.com/ Linq to Hive http://hadoopsdk.codeplex.com MEF (Managed Extensibility Framework) http://mef.codeplex.com/ OWIN Authentication Middleware http://katanaproject.codeplex.com/SourceControl/latest#src/Microsoft.Owin.Security.Google/GoogleOAuth2AuthenticationMiddleware.cs Rx (Reactive Extensions) https://rx.codeplex.com/ Salesforce Toolkit for .NET https://github.com/developerforce/Force.com-Toolkit-for-NET Web Protection Library http://wpl.codeplex.com/ Windows Azure .NET SDK https://github.com/WindowsAzure/azure-sdk-for-net Windows Phone Toolkit http://phone.codeplex.com/ WnsRecipe https://github.com/nickharris/WnsRecipe Xamarin couchbase-lite-net https://github.com/xamarin/couchbase-lite-net Xamarin Mailkit https://github.com/jstedfast/MailKit Xamarin Mimekit https://github.com/jstedfast/MimeKit Xamarin.Auth https://github.com/xamarin/Xamarin.Auth Xamarin.Mobile https://github.com/xamarin/Xamarin.Mobile
- Visual Studio is transforming so it continues to provide the best tools and services for the diverse world of devices and services. On the client side, Visual Studio provides a solution to create first-class applications for any device including iOS, Android and Windows. On the server side, just like the rest of the Microsoft platform, Visual Studio is embracing Linux and provides a development environment for creating server applications that run on Linux.
- When we originally shipped the .NET Framework in 2002 there was only a single framework. Shortly after, we released the .NET Compact Framework which was a subset of the .NET Framework that fit within the footprint of smaller devices, specifically the old Windows Mobile. The compact framework was a separate code base from the .NET Framework. It included the entire vertical: a runtime, a framework, and an application model on top. Since then, we’ve repeated this sub-setting exercise many times: Silverlight, Windows Phone and most recently for Windows Store. This yields to fragmentation because the .NET Platform isn’t a single entity but a set of platforms, owned by different teams, and maintained independently. Of course, there is nothing wrong with offering specialized features in order to cater to a particular need. But it becomes a problem if there is no systematic approach and specialization happens at every layer with little to no regards for corresponding layers in other verticals. The outcome is a set of platforms that only share APIs by the fact that they started off from a common code base. Over time this causes more divergence unless explicit (and expensive) measures are taken to converge APIs. What is the problem with fragmentation? If you only target a single vertical then there really isn’t any problem. You’re provided with an API set that is optimized for your vertical. The problem arises as soon as you want to target the horizontal, that is multiple verticals. Now you have to reason about the availability of APIs and come up with a way to produce assets that work across the verticals you want to target. Today it’s extremely common to have applications that span devices: there is virtually always a back end that runs on the web server, there is often an administrative front end that uses the Windows desktop, and a set of mobile applications that are exposed to the consumer, available for multiple devices. Thus, it’s critical to support developers in building components that can span all the .NET verticals.
- .NET Core is essentially a fork of the NET Framework whose implementation is also optimized around factoring concerns. Even though the scenarios of .NET Native (touch based devices) and ASP.NET 5 (server side web development) are quite different, we were able to provide a unified Base Class Library (BCL). The API surface area for the .NET Core BCL is identical for both .NET Native as well ASP.NET 5. At the bottom of the BCL we have a very thin layer that is specific to the .NET runtime. We’ve currently two implementations: one is specific to the .NET Native runtime and one that is specific to CoreCLR, which is used by ASP.NET 5. However, that layer doesn’t change very often. It contains types like String and Int32. The majority of the BCL are pure MSIL assemblies that can be shared as-is. In other words, the APIs don’t just look the same – they share the same implementation. For example, there is no reason to have different implementations for collections. On top of the BCL, there are app-model specific APIs. For instance, the .NET Native side provides APIs that are specific to Windows client development, such as WinRT interop. ASP.NET 5 adds APIs such as MVC that are specific to server- side web development. We think of .NET Core as not being specific to either .NET Native nor ASP.NET 5 – the BCL and the runtimes are general purpose and designed to be modular. As such, it forms the foundation for all future .NET verticals.
- In contrast to the .NET Framework, the .NET Core platform will be delivered as a set of NuGet packages. We’ve settled on NuGet because that’s where the majority of the library ecosystem already is. In order to continue our effort of being modular and well factored we don’t just provide the entire .NET Core platform as a single NuGet package. Instead, it’s a set of fine grained NuGet packages. For the BCL layer, we’ll have a 1-to-1 relationship between assemblies and NuGet packages. Moving forward, the NuGet package will have the same name as the assembly. For example, immutable collections will no longer be delivered in a NuGet package called Microsoft.Bcl.Immutable but instead be in a package calledSystem.Collections.Immutable. In addition, we’ve decided to use semantic versioning for our assembly versioning. The version number of the NuGet package will align with the assembly version. The alignment of naming and versioning between assemblies and packages help tremendously with discovery. There is no longer a mystery which NuGet packages contains System.Foo, Version=1.2.3.0 – it’s provided by the System.Foo package in version 1.2.3. NuGet allows us to deliver .NET Core in an agile fashion. So if we provide an upgrade to any of the NuGet packages, you can simply upgrade the corresponding NuGet reference. Delivering the framework itself on NuGet also removes the difference between expressing 1st party .NET dependencies and 3rd party dependencies – they are all NuGet dependencies. This enables a 3rd party package to express, for instance, that they need a higher version of the System.Collections library. Installing this 3rd party package can now prompt you to upgrade your reference to System.Collections. You don’t have to understand the dependency graph – you only need to consent making changes to it. The NuGet based delivery also turns the .NET Core platform into an app-local framework. The modular design of .NET Core ensures that each application only needs to deploy what it needs. We’re also working on enabling smart sharing if multiple applications use the same framework bits. However, the goal is to ensure that each application is logically having its own framework so that upgrading doesn’t interfere with other applications running on the same machine. Our decision to use NuGet as a delivery mechanism doesn’t change our commitment to compatibility. We continue to take compatibility extremely seriously and will not perform API or behavioral breaking changes once a package is marked as stable. However, the app-local deployment ensures that the rare case where a change that is considered additive breaks an application is isolated to development time only. In other words, for .NET Core these breaks can only occur after you upgraded a package reference. In that very moment, you have two options: addressing the compat glitch in your application or rolling back to the previous version of the NuGet package. But in contrast to the .NET Framework those breaks will not occur after you deployed the application to a customer or the production server.
- .NET 2015 is like a snapshot in the time of the different components and frameworks within .NET. When .NET was born and during quite a few years, the .NET Framework was a single big framework targeting all scenarios. But, nowadays, .NET is composed by different components, frameworks and even runtimes but at the same time those frameworks share many things in common, like languages (C#, VB.NET and F#), compilers and the new .NET Compiler Platform (“Roslyn”), JITs, etc. For instance, you have a different API/Framework when developing a Windows Store application compared to when you develop a desktop application in WPF or a web application with ASP.NET frameworks (MVC, Web Forms, Web API, SignalR). .NET 2015 is a snapshot/picture that shows all the technologies/components released from Microsoft in 2015”. That is basically .NET 2015. At the end of the day, .NET 2015 is a set of .NET releases. The year denotes a single umbrella release that provides a cohesive experience and unifies the family of .NET technologies. It also helps us talk about all the releases that come out at the same time and work well together.
- System.Web Static Files Project.json Task Runner Explorer Intellisense Json (code + VS) Grunt, Bower TagHelpers **Cache, restaurar Project.json** Warning códigos não disponíveis no Core
- Browser Link
- System.Web Static Files Project.json Task Runner Explorer Intellisense Json (code + VS) Grunt, Bower TagHelpers **Cache, restaurar Project.json** Warning códigos não disponíveis no Core
- .NET Framework 4.6.NET Framework 4 There are also investments that are exclusively being made for the .NET Framework 4.6 such as the work we announced in the WPF Roadmap. http://blogs.msdn.com/b/dotnet/archive/2014/11/12/the-roadmap-for-wpf.aspx The .NET Framework 4.6 is the next version of the .NET Framework, a Highly compatible, in-place replacement for with .NET 4, 4.5, 4.5.1, and 4.5.2. Leading up to the Preview release, we had been using .NET Framework 4.5.3, however since the payload includes significant features and improvements, we bumped up the version to clearly communicate the magnitude of changes. Note that in the Preview release, you’ll still see instances of “4.5.3” in the .NET Framework and Visual Studio version information. We will be updating these in future releases. There are many great features in the .NET Framework 4.6 Preview, which you can use today. These range from new WPF features to RyuJIT as well as productivity enhancements in Visual Studio. WPF Improvements and Roadmap Today, the WPF team announced the roadmap for the WPF platform. Their post defines the areas of investment in future releases of WPF and details the current progress of improvements made to the WPF platform in the .NET Framework 4.6 and Visual Studio 2015. The team has made key improvements to WPF in this release: Transparent child windows Multi-image cursor files Re-designed Blend experience New set of Visual Diagnostics tools Timeline tool in the Performance and Diagnostics hub The team has also fixed a set of customer reported issues. The best place to ask WPF questions or engage with the team is in the comments of the WPF team post. Windows Forms High DPI Windows Forms High DPI support has been updated to include more controls. Next Generation JIT Compiler -- RyuJIT This release includes a new version of RyuJIT, the 64-bit JIT Compiler. It is enabled by default for 64-bit processes. CLR Performance Improvements The assembly loader now uses memory more efficiency by unloading IL assemblies after a corresponding NGEN image is loaded. This change is a major benefit for virtual memory for large 32-bit apps (such as Visual Studio) and also saves physical memory. .NET Language Innovation In this release, several new C# and Visual Basic language features help reduce boilerplate and clutter in everyday code, encourage a more declarative style of programming, and bring the two languages even closer together. The features listed below will be available to both languages in the final release. A few highlights are shared below. Checkout the C# and VBTeam blogs for all the details. Methods, getter-only properties etc. can now have a single expression as their body, just like lambdas. Nameof provides a refactoring-safe way of getting the name of e.g. a parameter, member or type as a string. Auto-properties can have initializers and no longer require setters. Index initializers Inside an object initializer you can now initialize a specific index of the new object. C# only. Exception filters let you look at an exception and decide whether to catch it with a given catch block. Using null-conditional operators you can get a built-in null check while accessing and invoking members and indexers. Using clauses for static classes bring their static members directly into scope, so you can. call e.g WriteLine() or Sqrt() without prefixing with the class name. Await now works in catch and finally blocks, obviating some very tricky workarounds. String interpolation: String interpolation provides a concise way of describing string templates that insert expressions into format strings (C# only at Preview, both VB and C# at RTM).
- .NET Framework 4.6 The .NET Framework is still the platform of choice for building rich desktop applications and .NET Core doesn’t change that. For Visual Studio 2015 our goal is to make sure that .NET Core is a pure subset of the .NET Framework. In other words, there wouldn’t be any feature gaps. After Visual Studio 2015 is released our expectation is that .NET Core will version faster than the .NET Framework. This means that there will be points in time where a feature will only be available on the .NET Core based platforms. We’ll continue to release updates to .NET Framework. Our current thinking is that the release cadence will roughly be the same as today, which is about once a year. In these updates, we’ll bring the innovations that we made in .NET Core to the .NET Framework. We’ll not just blindly port all the feature work, though – it will be based on a cost-benefit analysis. As I pointed out, even additive changes to the .NET Framework can cause issues for existing applications. Our goal is to minimize API and behavioral differences while not breaking compatibility with existing .NET Framework applications. There are also investments that are exclusively being made for the .NET Framework such as the work we announced in the WPF Roadmap.