Omarsoft For IT Solutions (Java Codes ,C#.NET Codes , ASP.NET Codes ,VB.NET Codes ,Oracle Database Administration, Real Application Cluster , Remote Support, Cloud Services , Networks ,Virtualization....
  • الأنظــمــة المكتبية        Windows App Programming
  • أنظــمـةالويــب        Web based systems programming
  • تطبيقات الهواتف الذكية     smartphones programming
  • إدارة قواعــــــد البيــــــــــــــــانات        Database Administration
  • إدارة الشبكـــــــــــــــــــــــــــــــــات        Networks Administration
  • إدارة الســـيــرفرات (ويب - محلية)  Servers Administration
  • إدارة مخـــــــــــــــــازن البيــــــــــــانات     Storage Administration
  •             N Computing & 2X Application services

    Social Icons

Loading...

What’s New in .NET 6 for Blazor



.NET 6 is coming and, with it, some notable Blazor improvements. Dynamic components, hot reload, Blazor MAUI apps—the list goes on and on. Here are some of the main highlights.

.NET 6 is shaping up nicely ahead of its November release, but what’s in it for Blazor?

Here are a few of the standout changes coming in Blazor’s next significant release.

Dynamic Components

The standard way to build a Blazor app is to break the UI down into a number of smaller components which you can then compose together to build a larger section of the UI.

Greeting.razor

<p>Hello @Name</p>
@code {
[Parameter]
public string Name { get; set; }
}
C#

Index.razor

@page "/"

<Greeting Name="Jon"/>
<Greeting Name="Esme"/>
C#

So in this case we’d see two Hello messages if we visited the application’s home page.

This is great for those occasions when you know ahead of time exactly which components you want to display.

But what about those times when you need to render varying components at runtime, based on data.

Take, for example, a customizable dashboard where your users could pick and choose which widgets they wanted displayed.

In this case it might be desirable to store those dashboard preferences/design as data, then read that data and dynamically render the relevant component(s).

Say we have a List of Dashboard components, stored as types:

List<Type> widgets = new List<Type>{ typeof(Counter), typeof(FetchData) }
C#

We can loop over that list and render each component (according to its type):

@foreach(var widgetType in widgets){
<DynamicComponent Type="@widgetType"/>
}
C#

This would render the Counter and FetchData components.

But what if we need to pass extra parameters to the dynamic component? We can’t just pass them to the DynamicComponent when we declare it because we can’t know at compile-time which component is going to be rendered.

For this scenario we can pass a dictionary of parameters.

Extending our widget example, if we create a class or record to represent a widget:

public record Widget {
public Type Type;
public IDictionary<string, object> Parameters;
}
C#

Then store a list of them in our Blazor component, we can iterate over each one and pass the Parameters along to DynamicComponent.

@page "/"

@foreach (var widget in widgets)
{
<DynamicComponent Type="@widget.Type" Parameters="@widget.Parameters"/>
}

@code {
private readonly List<Widget> widgets = new()
{
new Widget { Type = typeof(FetchData) },
new Widget
{
Type = typeof(Greeting),
Parameters = new Dictionary<string, object>
{
["Name"] = "Jon"
}
}
};
}
C#

This is equivalent to:

@page "/"

<FetchData />
<Greeting Name="Jon" />
HTML

Except now we can change the dashboard at runtime by adding/removing items to the List<Widget>.

Hot Reload

It’s hard to overstate the importance of a fast feedback loop when developing for the web.

So much of “modern” web development involves making small changes to HTML, CSS, UI logic and it’s hard to rapidly iterate your design when you find yourself waiting to see those changes spring to life in the browser.

Improving this feedback loop was a priority for .NET 6, and the preview releases have shown steady improvements with each release.


Ahead of Time Compilation (Blazor Wasm)

AOT directly compiles your .NET code to WebAssembly as part of the compilation process.

This is different from the standard way your Blazor Wasm apps run today, where your code is never compiled to WebAssembly, instead running on a .NET IL interpreter (which is itself implemented in WebAssembly).

This use of an interpreter means, in practice, your standard Blazor Wasm app will perform more slowly than it would on a normal .NET runtime (for example an MVC or Razor Pages app running on a server).

AOT addresses this performance issue by compiling your code to WebAssembly. For CPU-intensive tasks the performance improvement is significant (up to 5 times faster), but AOT compilation brings its own tradeoffs.

It requires an additional build tool to be installed, the actual compilation itself is quite slow (as of Preview 7) and AOT-compiled apps are larger (about 2x larger on average).

To use AOT you’ll need to install the latest .NET WebAssembly tools (watch out, the name of these tools changed between Preview 4 and Preview 7 of .NET 6. The new name is shown below).

dotnet workload install wasm-tools
Bash

The main tradeoff is that you’ll sacrifice load time for runtime performance, so the decision as to whether this makes sense will vary depending on the specific app you’re building.

Blazor Query String Component Parameters

You could do this previously but you had to lean on Microsoft.AspNetCore.WebUtilities and write your own code to handle it.

Now it’s much simpler as you can simply decorate your parameters with the new SupplyParameterFromQuery attribute:

[Parameter]
[SupplyParameterFromQuery]
public string Filter { get; set; }
C#

With this, if you append ?filter=x to the URL for your Blazor page, the corresponding parameter (Filter) will be populate with the value from query string.

Note there’s currently a debate ongoing about the name of the attribute, so it may change in a future release but the functionality will remain the same.

Required Parameters

[EditorRequired]
[Parameter]
public string Name { get; set; }
C#

If you attempt to use the component without specifying required parameters, you’ll get an error at design time (in your IDE and/or when the app is compiled).

Worth noting it isn’t enforced at runtime so doesn’t guarantee that your parameters values will not be null.

Modify HTML Head From Blazor

You can easily change the page title and add meta tags for SEO without resorting to JS interop to get the job done.

For this, .NET 6 introduces two new components: PageTitle and HeadContent.

You can change the page title using PageTitle.

<PageTitle>@title</PageTitle>

@code { private string title = "Dynamic title!"
}
HTML

And add anything else you like to the HTML <head> via HeadContent.

<HeadContent>
<meta name="description" content="@description">
</HeadContent>

@code { private string description = "Comprehensive dynamic description"
}
HTML

Error Boundaries

With the current/previous release of Blazor, any exception thrown in any component would generally result in your entire application failing, often requiring a restart of the entire app.

With .NET 6 you can contain the chaos and wrap any part of your application in an error boundary.

<h1>Super Fancy Application</h1>
<div>
<ErrorBoundary>
<Counter />
</ErrorBoundary>
</div>
HTML

Now if Counter throws an exception, an error will be displayed where the ErrorBoundary is declared, leaving the rest of the UI unaffected.

By default error boundaries render an empty div with a blazor-error-boundary CSS class when an exception occurs. However, you can take more control of that error if you wish:

<h1>Super Fancy Application</h1>
<div>
<ErrorBoundary>
<ChildContent>
<Counter />
</ChildContent>
<ErrorContent>
<p class="bad-error">
Oh dear, something went horribily, horribly wrong whilst attempting to count...
</p>
</ErrorContent>
</ErrorBoundary>
</div>

Creating a Disaster Recovery Plan




Creating a Disaster Recovery Plan 

Last week we decided on how often to backup our database; now we must decide where to backup our database. The first option available is to backup directly to tape from SQL Server. On the plus side, a backup to tape allows for off-site storage of backups. On the down side, tape backups are slow and therefore can impact the server for a longer amount of time than a backup to a file. The other common place to backup to is a file. File backups are much faster than a tape backup, for both backup and restore operations; however, backups to files don't allow for quick off-site storage (unless you happen to have a high speed remote link).
A third option is to use a combination of making backups to a file and then using another backup utility, such as NT Backup, to copy the file backups to tape. By making backups to files on another server nearby and then copying the files to tape, you can minimize the time a backup will impact your SQL Server while still allowing for off-site storage of tapes. Also, if you need to make multiple copies of tape backups, using another computer for copying backups to multiple tapes can help even more.
Another thing to think about when you are choosing where to make a backup is the time it takes to restore a backup. For example, a backup that is stored on another computer could be restored much faster over a high speed network than it could be from a tape drive. To take advantage of this faster recovery you may consider saving file backups for the week on another computer (in addition to your tape backups). In the event your SQL Server crashes you have a current backup on hand and available at a faster speed than tape.
File and tape backups do provide for lots of flexibility in designing your disaster recovery plan, but there are still many options available from third party venders. For example, you can find utilities that make the process of making backups of multiple SQL Servers very simple. You may also consider a Storage Area Network for large mission-critical systems. Although I would love to cover every option available, other backup utilities and hardware options are outside the scope of this series.
Before we can move on, there is a second half to deciding where to backup...choosing a tape, or file for that matter, rotation. If you used a new tape for each day's backup you would probably eat up a good part of your budget on nothing but tapes. In order to save money a few popular tape rotation schemes are in use. The rotation we are going to look at is known as the Grandfather-Father-Son rotation. Let's look at our example from last week to see how this rotation works (note: I have rearranged the order of the days from the last article):

MONTUEWEDTHUFRISATSUN
12:00 AMFULL
1:00 AM
2:00 AMDIFDIFDIFDIF DIFDIF
3:00 AM
In a Grandfather-Father-Son rotation you start out by using a new tape for each day of the week for the first week. For each week following the first week you reuse the same tapes except for the last tape of the week. By using a new tape at the end of each week you can keep an archive of data. In the event you need to restore data that was deleted or lost, the archive from past weeks is available. Once a month has gone by you keep the tape for the last week of that month and then reuse the end-of-week tapes. Here is what a Grandfather-Father-Son rotation would look like for our example over a two month period:
11 Tapes are used: M, T, W, TH, F, S, W1, W2, W3, Month1, Month2...

MONTUEWEDTHUFRISATSUN
Week 1
MTWTHFSW1
Week 2MTWTHFSW2
Week 3MTWTHFSW3
Week 4MTWTHFSMonth1

MONTUEWEDTHUFRISATSUN
Week 5
MTWTHFSW1
Week 6MTWTHFSW2
Week 7MTWTHFSW3
Week 8MTWTHFSMonth2
In our example we must take the monthly backup on Sunday because that is the only day we make a full backup. However, if you make a full backup of your database every day of the week you can use the monthly tape on the last day of the month no matter what day of the week it ends on. To illustrate, this is what a Grandfather-Father-Son rotation would look like if we took a full backup every night for the next two months:
Note that a new tape is substituted for the last day of each month. Also note that once the last day of the month has passed, the end-of-week tapes can then be reused.
May 2002, Wednesday 1st - Friday 31st:
MONTUEWEDTHUFRISATSUN
Week 1
WTHFSW1
Week 2MTWTHFSW2
Week 3MTWTHFSW3
Week 4MTWTHFSW4
Week 5MTWTHMonth1
June 2002, Saturday 1st - Sunday 30th:
MONTUEWEDTHUFRISATSUN
Week 1
SW1
Week 2MTWTHFSW2
Week 3MTWTHFSW3
Week 4MTWTHFSW4
Week 5MTWTHFSMonth2


-------------
Having decided on how often to backup and where to backup, you now must choose a location to store your tapes. Deciding on a location is going to depend greatly on your situation, but there are some general rules you should keep in mind. First of all, the location, either on or off-site, should be secure! If someone has access to your tapes...you might as well give them access to your server. Second, you need to find a balance between keeping the most recent tapes nearby (in case you need to restore a database) vs. the need to store tapes off-site (in case of a disaster).
One approach that we talked about earlier is storing a file backup on a second computer from your SQL Server. By doing this, not only can you recover from a crash faster, but it also allows you to store tapes off site without having to worry about going to get them to restore a database. You can also accomplish this same effect, minus the faster restore time, by making two sets of tape backups; one off-site for storage and one on-site for quick access. You may even consider making a third copy of your monthly backup for storage in a third off-site location. Also keep in mind that you don't have to keep all your tapes off-site. Depending on your needs, you may find that keeping the weekly backups, or even the monthly backups, off-site is adequate.
Before I move on, there is one last issue with backups that I would like to cover -- choosing someone to swap tapes. Once you have your plan in place you should designate a single person responsible for checking that backups took place and that tapes are swapped out as needed. It is important to have one person do this because when multiple people share the responsibility you end up with: "I thought you swapped the tapes last night?!?" When a single person is responsible for backups it becomes a routine for them. Now, if that one person is unable to swap tapes (ex: they get sick) it is their responsibility to find another person to swap tapes for them. Although another person may do the job of swapping tapes now and then, you still have the accountability of the single person who normally does the tape swapping, not a group of people. If the job is too big for one person, consider giving the responsibility for half the servers to one person and half to another person (or however you would like to split them up). Additionally, if you can't have the same person swapping tapes every day (ex: you take backups on the weekend), make it clear who is responsible for what days and keep the days the same from week to week.
So, having decided how often to backup, where to backup, and where to store our backups...what's left in a disaster recovery plan? Well quite a lot, but most of it is highly dependent on your environment. The first step is to document, document, and document. Get a folder and dedicate it to your disaster recovery plan. Here are some things that you should include in your plan:
- Server Hardware Specifications
- Network Layout
- Server Software Configurations
- Database File Layout (i.e. log files and data files)
- Label your tapes and include a backup and rotation description
The next step is to start thinking about, and write down, what should happen if a failure occurs. Keep in mind when you start to write out the plan, you should assume that you are not on-site and are unable to come to the rescue. You should also assume that the person restoring the server does have technical knowledge about SQL Server, but knows nothing about your particular setup. Think about things like:
- Who should be contacted if something goes wrong?
- Where are the backups stored?
- Where are the software and driver disks stored?
- Are there any tech support numbers available?
- If new hardware is required, what should be done?
- Is there any other information that may be useful?
Once you have completed documenting what should happen if a disaster occurs, there is one final step that you must complete...testing your plan. Having a plan is not enough, you have to test to see if your plan has all the necessary information, if your backups work correctly, and if everyone knows what to do. In order to do this you should setup a fake disaster. Now, don't go lighting your servers on fire (we all know how tempting that can be sometimes!), but use some extra hardware to test your plan. Don't worry about getting exactly the same setup (hardware wise), you will need just enough to run the services and any client applications. When testing, you should follow your disaster recovery plan and see if all the information is available in the plan. If you left anything out, or something was wrong, now is the time to make corrections and additions. By using the test hardware you not only get a feel for what information needs to be in your plan, but you are also able to test your backups by restoring the server from tape.

Sana'a Yemen - 50th st.

+967 738166685

omar.soft2000@gmail.com

للاتصال بنا CONTACT US

الاسم Name

بريد إلكتروني Email *

رسالة Message *

2015-2016 © All Rights Reserved Omarsoft
Back To Top