Al comenzar con Blazor, seguro que veis en la mayoría de ejemplos que la implementación de la lógica (código C#) y de la pura interfaz de usuario (HTML) se encuentran en un bloque @code en el mismo archivo .razor, como en el siguiente bloque de código:

@* File: ~/Pages/HelloWorld.razor *@
@page "/hello"
<h1>Hello</h1>
<div>
    <label for="name">Your name:</label>
    <input id="name" @bind-value="Name" @bind-value:event="oninput"/>
</div>
@if (HasName)
{
    <h2>Hello, @Name!</h2>
}

@code
{
    public string Name { get; set; }
    public bool HasName => !string.IsNullOrWhiteSpace(Name);
}

Sin embargo, esto no tiene que ser necesariamente así. En tiempo de compilación, un archivo .razor genera una clase parcial C# con su mismo nombre, lo cual nos brinda la posibilidad de mover todo el código C# a otra porción de dicha clase.

Podéis ver las clases generadas para cada archivo .razor en la carpeta del proyecto obj\debug\netcoreapp3.1\Razor\Pages.

Ahí van los enlaces recopilados durante la semana pasada. Espero que os entretengan, al menos un ratillo, durante el confinamiento :-)

Por si te lo perdiste...

• Convenciones personalizadas en ASP.NET Core MVC
  José María Aguilar
• Etiquetado de consultas en Entity Framework 6
  José María Aguilar

.NET Core / .NET

• Cannot get the value of a token type ‘Number’ as a string con System.Text.Json
  Jorge Serrano
• El fin de Visual Basic .NET ya ha empezado
  José Manuel Alarcón
• Announcing .NET 5 Preview 1
  Scott Hunter
• Using Windows Antimalware Scan Interface in .NET
  Gérald Barré
• Introducing Clippit, get your slides out of PPTX.
  Sergey Tihon
• Translating C# Lambda Expressions to General Purpose Filter Descriptors & HTTP Query Strings
  Kamran Saeedi
• Immutable types in C# with Roslyn
  Cezary Piątek
• C# developers! Your scoped components are more dangerous than you think
  Jonathan George
• Async ValueTask Pooling in .NET 5
  Stephen Toub
• A couple of nice Tuple use cases | Joseph Woodward, Software Developer"
  Joseph Woodward
• Upgrading from ASP.NET Core 3.1 to 5.0 (Preview 1)
  Steve Gordon
• VB.NET is done, not dead
  Matt Lacey
• Is C# Slower Than C++?
  Michael Shpilt
• Lazily resolving services to fix circular dependencies in .NET Core
  Thomas Levesque
• Introducing Ais.Net – High-Performance Parsing in C#
  Ian Griffiths
• Lessons learned porting Octopus Server to .NET Core 3.1
  Rob Pearson
• C#: Why You Should Prefer the is Keyword Over the == Operator – Thomas Claudius Huber
  Thomas Claudius Huber

Hace unos días han anunciado la disponibilidad de una herramienta que os puede interesar si, como un servidor, acumuláis un gran número de versiones del SDK y runtimes de .NET Core que no váis a necesitar, algo muy propio de ese Diógenes digital que todos llevamos dentro ;)

El estado actual de acumulación de SDKs podéis conocerlo muy fácilmente desde línea de comandos utilizando la orden dotnet --list-sdks:

C:\>dotnet --list-sdks
1.1.11 [C:\Program Files\dotnet\sdk]
2.1.202 [C:\Program Files\dotnet\sdk]
2.1.503 [C:\Program Files\dotnet\sdk]
2.1.504 [C:\Program Files\dotnet\sdk]
2.1.505 [C:\Program Files\dotnet\sdk]
2.1.507 [C:\Program Files\dotnet\sdk]
2.1.508 [C:\Program Files\dotnet\sdk]
2.1.509 [C:\Program Files\dotnet\sdk]
2.1.511 [C:\Program Files\dotnet\sdk]
2.1.602 [C:\Program Files\dotnet\sdk]
2.1.604 [C:\Program Files\dotnet\sdk]
2.1.700 [C:\Program Files\dotnet\sdk]
2.1.701 [C:\Program Files\dotnet\sdk]
2.1.800-preview-009696 [C:\Program Files\dotnet\sdk]
2.1.801 [C:\Program Files\dotnet\sdk]
2.1.802 [C:\Program Files\dotnet\sdk]
2.2.102 [C:\Program Files\dotnet\sdk]
2.2.105 [C:\Program Files\dotnet\sdk]
2.2.202 [C:\Program Files\dotnet\sdk]
2.2.203 [C:\Program Files\dotnet\sdk]
2.2.204 [C:\Program Files\dotnet\sdk]
3.0.100-preview8-013656 [C:\Program Files\dotnet\sdk]
3.0.100-preview9-014004 [C:\Program Files\dotnet\sdk]
3.0.100 [C:\Program Files\dotnet\sdk]
3.1.100 [C:\Program Files\dotnet\sdk]
3.1.101 [C:\Program Files\dotnet\sdk]
3.1.102 [C:\Program Files\dotnet\sdk]

C:\>_

En mi caso, tengo aún por ahí el SDK de .NET Core 1.x, un par de decenas de .NET Core 2.x, y algunas previews, pero los he visto mucho peores ;) Obviamente, salvo dos o tres versiones que quizás me interesen porque tengo aplicaciones que aún no he migrado, el resto ocupan en mi equipo un espacio considerable sin motivo, más de 5GB, pues cada SDK puede pesar entre 150 y 200 Mb.

Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes, ¡y que los veáis desde casa, que la cosa se está poniendo muy muy fea! ¡Cuidaos mucho!

Por si te lo perdiste...

• Etiquetado de consultas en Entity Framework Core
  José María Aguilar
• La directiva @helper no existe en MVC Core 1.0
  José María Aguilar

.NET Core / .NET

• Announcing the .NET Core Uninstall Tool 1.0
  Sarah Oslund
• Visual Basic support planned for .NET 5.0
  .NET Team
• Microsoft: 'We Do Not Plan to Evolve Visual Basic as a Language'
  David Ramel
• Your C# is already functional, but only if you let it
  Igal Tabachnik
• Morestachio 3.0. An Evolving .NET TextEngine
  Jean-Pierre Bachmann
• Improving list sum function based on head and tail with C# 8
  Jiří Činčura
• Passing awaited tasks
  Eric Lippert
• Some more C# 8
  Tom Deseyn
• Microsoft Dotnet Gitignore File
  Vijay Ganesh
• C# Implementation of Basic Linear Algebra Concepts
  Mohammad Elsheimy
• C#: Different ways to Check for Null – Thomas Claudius Huber
  Thomas Claudius Huber

 Alguna vez he escuchado, a modo de leyenda urbana, que no era bueno utilizar try/catch porque el mero hecho de usar este tipo de bloque de código afectaba al rendimiento.

La verdad es que de forma intuitiva se puede adivinar que esto no debería ser así. Si no se producen excepciones en un código que tengamos envuelto en un try/catch se debería ejecutar virtualmente a la misma velocidad que si no usáramos este tipo de bloque. Cosa distinta es si producen excepciones: ahí el rendimiento sí se verá seriamente penalizado, pero no es culpa del try/catch sino del propio sistema de gestión de excepciones de .NET.

Pero claro, lo dicho anteriormente es sólo cierto si somos capaces de demostrarlo, así que usaremos nuestro viejo conocido BenchmarkDotnet para desmontar este mito.

Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)

Por si te lo perdiste...

• Índices y rangos en C# 8 (2 de 2)
  José María Aguilar
• ¿Cuál es el "Bus factor" de tu proyecto?
  José María Aguilar

.NET Core / .NET

• Nuevo curso: Testing de aplicaciones .NET y .NET Core
  CampusMVP
• Fin de soporte de .NET Core 3 ¿y ahora qué?
  Jorge Serrano
• Creando un Servicio Windows con .NET Core 3.1
  Jorge Serrano
• Introducing perfolizer
  Andrey Akinshin
• .NET Threading and WebAssembly
  Jerome Laban
• Why do I rag on BinaryFormatter?
  Marc Gravell
• C# 8 default interface methods
  Tom Deseyn
• Optimize struct performances using StructLayout
  Gérald Barré
• Analysing .NET start-up time with Flamegraphs
  Matt Warren
• How to write a Roslyn Analyzer
  Mika Dumont
• Functional Programming Optics in .NET
  William Barbosa
• Upgrade Your .NET Console App Experience
  Khalid Abuhakmeh
• C# 8 nullable reference types
  Tom Deseyn
• Patrik Svensson - How to write a stateful Roslyn analyzer
  Patrik Svensson
• C#: The Order of Interfaces Is Important for Casting Performance
  Thomas Claudius Huber