What is the Project Structure in Blazor? | Blazor Tutorial

Before getting into this article, we would suggest you please read all our other Blazor articles for more and sequential information about ASP .NET Core Blazor with the links below:

1. Chapter 1: Blazor Interview Questions and Answers
2. Chapter 2: What is ASP.NET Core Blazor?
3. Chapter 3: Blazor Vs Angular
4. Chapter 4: Blazor hosting models
5. Chapter 5: Project Structure in Blazor
6. Chapter 6: What are Blazor Components
7. Chapter 7: net core razor components in details | Nesting Razor Components
8. Chapter 8: Blazor Model Classes
9. Chapter 9: Data Bindings in Blazor
10. Chapter 10: Data access technique in blazor

Project Structure in Blazor:

Regardless of their huge project structure contrasts, ASP.NET Web Forms and Blazor share numerous comparable ideas. Here, we'll take a gander at the structure of a Blazor project and contrast it with an ASP.NET Web Forms project.

Project file

Blazor Server applications are .NET Core projects. The project file for the Blazor Server application is about as straightforward as it can get:

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>netcoreapp3.0</TargetFramework>
  </PropertyGroup>

</Project>

The project file for a Blazor WebAssembly application looks somewhat increasingly included (careful variant numbers may differ):

Blazor WebAssembly projects target .NET Standard rather than .NET Core since they run in the program on a WebAssembly-based .NET runtime. You can't introduce .NET into an internet browser like you can on a worker or designer machine. Therefore, the project references the Blazor system utilizing singular bundle references.

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <RazorLangVersion>3.0</RazorLangVersion>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Blazor" Version="3.1.0" />
    <PackageReference Include="Microsoft.AspNetCore.Blazor.Build" Version="3.1.0" PrivateAssets="all" />
    <PackageReference Include="Microsoft.AspNetCore.Blazor.HttpClient" Version="3.1.0" />
    <PackageReference Include="Microsoft.AspNetCore.Blazor.DevServer" Version="3.1.0" PrivateAssets="all" />
  </ItemGroup>

  <ItemGroup>
    <ProjectReference Include="..\Shared\BlazorWebAssemblyApp1.Shared.csproj" />
  </ItemGroup>

</Project>

By examination, a default ASP.NET Web Forms project incorporates right around 300 lines of XML in its .csproj file, the vast majority of which is unequivocally posting the different code and substance files in the project. Huge numbers of the disentanglements in the .NET Core-and .NET Standard-based projects originate from the default targets and properties imported by referencing the Microsoft.NET.Sdk.Web SDK regularly alluded to as basically the Web SDK.

<ItemGroup>
  <PackageReference Include="Newtonsoft.Json" Version="12.0.2" />
</ItemGroup>

Entry point

The Blazor Server application's entry point is characterized in the Program.cs file, as you would find in a Console application. When the application executes, it makes and runs a web have case utilizing defaults explicit to web applications. The web has dealt with the Blazor Server application's lifecycle and sets up have level administrations. Instances of such administrations are configuration, logging, reliance infusion, and the HTTP worker. This code is for the most part standard and is frequently left unaltered.

public class Program
{
    public static void Main(string[] args)
    {
        CreateHostBuilder(args).Build().Run();
    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>();
            });
}

Blazor WebAssembly applications likewise characterize an entry point in Program.cs. The code looks marginally changed. The code is comparable in that it's setting up the application host to give similar host-level administrations to the application. The WebAssembly application have doesn't be that as it may, set up an HTTP worker since it executes legitimately in the program.

Static files

Not at all like ASP.NET Web Forms projects, not all files in a Blazor project can be mentioned as static files. Just the files in the wwwroot envelope are web-addressable. This organizer has alluded to the application's "webroot". Anything outside of the application's webroot isn't web-addressable. This arrangement gives an extra degree of security that forestalls inadvertent uncovering of project files over the web.

Configuration

Configuration in ASP.NET Web Forms applications is regularly taken care of utilizing at least one web.config files. Blazor applications don't normally have web.config files. On the off chance that they do, the file is possibly used to arrange IIS-explicit settings when facilitated on IIS. Rather, Blazor Server applications utilize the ASP.NET Core configuration reflections (Blazor WebAssembly applications don't as of now bolster similar configuration deliberations, yet that might be a component included what's to come). For instance, the default Blazor Server application stores a few settings in appsettings.json.

Program.cs

This document contains the Main() strategy which is the passage point for both the task types (i.e Blazor WebAssembly and Blazor Server).

In a Blazor worker venture, the Main() strategy calls CreateHostBuilder(a) technique which sets up the ASP.NET Core has.

In a Blazor WebAssembly venture, the App segment, which is the root part of the application, is determined in the Main technique. This root segment is available in the root venture envelope in the App.razor document.

Parts are the structure squares of a Blazor application. We will examine all that you have to know to assemble viable and reusable blazor parts in our forthcoming recordings. For the time being, simply comprehend the App part is the root segment of the application.

wwwroot

For both the venture types, this organizer contains static records like pictures, templates, and so forth.

App.razor

This is the root segment of the application. It utilizes the implicit Router segment and sets up customer side steering. It is this Router part that intercepts the programmed route and delivers the page that coordinates the mentioned address. The Router utilizes the Found property to show the substance when a match is found. On the off chance that a match isn't discovered, the NotFound property is utilized to show the message - Sorry, there's nothing at this location.

Pages folder

This folder contains the _Host razor page and the routable components that make up the Blazor app. The components have the .razor augmentation.

Index component (Index.razor) – Rendered when we explore to the root application URL.

Counter component (Counter.razor) – Rendered when we explore the way/counter.

FetchData component (FetchData.razor) – Rendered when we explore the way/fetch data.

Blunder component (Error.razor) – Rendered when an unhandled special case happens in the blazor app.

Common folder

As the name infers, contains the mutual components

MainLayout component (MainLayout.razor)

The application's primary design component

NavMenu component (NavMenu.razor)

Actualizes the route menu on the sidebar. NavLink component renders route connects to other Razor components like the index, counter, and fetch data components. This NavLink component is sufficiently wise to feature the route menu thing, if it's component is right now showing.

_Imports.razor

This resembles _ViewImports.cshtml document in an asp.net center MVC venture. This document contains the basic namespaces so we don't need to remember them for each razor component.

wwwroot/index.html

This is the root page in a Blazor WebAssembly venture and is executed as an Html page. At the point when a first solicitation hits the application, it is this page, is at first served. It has the standard HTML, HEAD, and BODY labels. It indicates where the root application segment App.razor ought to be delivered. You can discover this App.razor root part in the root venture organizer. It is remembered for the page as a HTML component <app>. We will discuss razor segments in detail in our forthcoming recordings.

This index.html page additionally stacks the blazor WebAssembly JavaScript document (_framework/blazor.webassembly.js). It is this record is liable for downloading

The accumulated blazor application, it's conditions and the .NET runtime

It likewise instates the runtime to run the blazor application in the program

Startup.cs

This record is available just in the Blazor Server venture. As the name infers it contains the applications' startup rationale. The Startup class contains the accompanying two techniques.

ConfigureServices

Configures the applications DI i.e reliance infusion administrations. For instance, AddServerSideBlazor() technique includes Blazor worker side administrations. On the IServiceCollection interface, there are a few strategies that start with the word Add. These techniques include different administrations for the Blazor application. We can even add our own administrations to the DI compartment. We will see this in real life in our up and coming recordings.

Configure

Configures the application's solicitation preparing pipeline. Depending on what we need the Blazor application to have the capacity to do we include or expel the individual middleware segments from the solicitation handling pipeline. For instance, UseStaticFiles() strategy includes the middleware part that can serve static records like pictures, CSS, and so on.

Pages/_Host.cshtml

This is the root page of the application and is indicated by calling MapFallbackToPage("/_Host") technique. It is executed as a razor page.

It is this page, is at first-served when a first solicitation hits the application. It has the standard HTML, HEAD, and BODY labels. It additionally indicates where the root application segment, App part (App.razor) must be delivered. At long last, it additionally stacks the blazor.server.js JavaScript document, which sets up the ongoing SignalR association between the server and the customer program. This association is utilized to trade data between the customer and the server. SignalR is an incredible system for adding ongoing web usefulness to applications.

The data folder (Blazor Server)

Contains code records identified with the example WeatherForecast administration

appsettings.json (Blazor Server)

Much the same as an asp.net center MVC venture, a blazor venture additionally utilizes this document to store the configuration settings.

Conclusion:

One significant highlight remember is, Blazor Server and Blazor WebAssembly are only 2 distinct ways we can host a Blazor application. Recall everything in a Blazor application is a razor part. Segments are the essential structure squares of a Blazor application. The manner in which we manufacture these segments is the equivalent of a Blazor server application just as for a Blazor WebAssembly application. In this way, the point that I am attempting to make is, there is only one Blazor system and the manner in which we construct, the Blazor server application and the Blazor WebAssembly application is fundamentally the same as. The main contrast is standing out the application is hosted. Whenever executed appropriately, it is anything but difficult to change over a Blazor server application to a Blazor WebAssembly application and the other way around.