Blog

What are app logs?

Azure provides built-in diagnostics with app logging. App logs are the output of runtime trace statements in app code. For example, you might want to check some logic in your code by adding a trace to show when a particular function is being processed. Or, you might only want to see a logged message when a particular level of error occurs. App logging is primarily for apps in preproduction and for troublesome issues, because excessive logs can carry a performance hit and quickly consume storage. For this reason, logging to the file system is automatically disabled after 12 hours.

App logging has scale limitations, primarily because files are being used to save the logged output. If you have multiple instances of an app, and the same storage is shared across all instances, messages from different instances might be interleaved, making troubleshooting difficult. If each instance has its own log file, then there are multiple logs, again making it difficult to troubleshoot instance-specific issues.

The types of logging available through the Azure App Service depends on the code framework of the app, and on whether the app is running on a Windows or Linux app host.

ASP.NET

ASP.NET apps only run on Windows app services. To log information to the app diagnostics log, use the System.Diagnostics.Trace class. There are four trace levels you can use, that correlate with the error, warning, information, and verbose logging levels shown in the Azure portal:

• Trace.TraceError(“Message”); // Writes an error message
• Trace.TraceWarning(“Message”); // Writes a warning message
• Trace.TraceInformation(“Message”); // Writes an information message
• Trace.WriteLine(“Message”); // Writes a verbose message

ASP.NET Core apps

ASP.NET Core apps can run on either Windows or Linux. To log information to Azure app logs, use the logger factory class, and then use one of six-log levels:

• logger.LogCritical(“Message”); // Writes a critical message at log level 5
• logger.LogError(“Message”); // Writes an error message at log level 4
• logger.LogWarning(“Message”); // Writes a warning message at log level 3
• logger.LogInformation(“Message”); // Writes an information message at log level 2
• logger.LogDebug(“Message”); // Writes a debug message at log level 1
• logger.LogTrace(“Message”); // Writes a detailed trace message at log level 0

For ASP.NET Core apps on Windows, these messages relate to the filters in the Azure portal in this way:

• Levels 4 and 5 are error messages.
• Level 3 is a warning message.
• Level 2 is an information message.
• Levels 0 and 1 are verbose messages.

For ASP.NET Core apps on Linux, only error messages (levels 4 and 5) are logged.

Node.js apps

For script-based Web apps, such as Node.js apps on Windows or Linux, app logging is enabled using the console() method:

• console.error(“Message”); // Writes a message to STDERR.
• console.log(“Message”); // Writes a message to STDOUT.

Both types of message are written to the Azure app service error level logs.

Logging differences between Windows and Linux hosts

To route messages to log files, Azure Web apps use the Internet Information Services (IIS) Web server. Because Windows-based Web apps are a well-established Azure service, and messaging for ASP.NET apps is tightly integrated with the underlying IIS service, Windows apps benefit from a rich logging infrastructure. For other apps, logging options are limited by the development platform, even when running on a Windows app service.

The Docker image used for the app’s container, determines the logging functionality available to Linux-based scripted apps, such as Node. Basic logging, such as using redirections to STDERR or STDOUT, uses the Docker logs. Richer logging functionality is dependent on the underlying image, and whether it’s running PHP, Perl, Ruby, and so on. To download equivalent Web application logging as provided by IIS for Windows apps, might require connecting to your container using SSH.

The following table summarizes the logging support for common app environments and hosts.

https://lernix.com.my/sap-fico-financial-accounting-training-courses-malaysia

Scaling out enables you to run more instances of a web app. The pricing tier determines resources available to each instance used by the App Service plan that hosts the web service. Each pricing tier specifies the computing power provided, together with the memory and maximum number of instances that can be created.

If you initially deploy a web app using a relatively cheap pricing tier, you might find the resources are sufficient to start with. But the resources might become too limited if demand for your web service grows, or if you add features that require more power. In this case, you can scale up to a more powerful pricing tier.

In the hotel reservation system, you notice a steady increase in the number of visitors, beyond the variations caused by special offers or events. Your company is adding more features to the web app that require more resources. You’re nearing the scale-out limits of your current App Service plan pricing tier, so you need to scale up to a tier that provides more instances and more powerful hardware.

In this unit, you learn how to scale up the web app to meet the increasing resource requirements.

App Service plan pricing tiers and hardware levels

The different pricing tiers available for App Service plans offer various levels or resources. The Basic, Standard, and Premium tiers are based on A-Series virtual machines that have different amounts of memory and IO capacity. The PremiumV2 and Isolated tiers are based on Dv2-Series virtual machines. Each of these tiers has three hardware levels, roughly corresponding to 1, 2, and 4 CPUs. For detailed information about the pricing tiers and hardware levels, see App Service pricing.

Scale up a web app

You scale an App Service plan up and down by changing the pricing tier and hardware level that it runs on. You can start with the Free tier and scale up as needed according to your requirements. This process is manual. You can also scale down again if you no longer need the resources associated with a particular tier.

Scaling up can cause an interruption in service to client apps running at the time. They might need to disconnect from the service and reconnect if the scale-up occurs during an active call to the web app. New connections might be rejected until scaling finishes. Also, scaling up can cause the outgoing IP addresses for the web app to change. If your web app depends on other services that have firewalls restricting incoming traffic, you need to reconfigure these services.

As with scale-out, you should monitor the performance of your system to ensure that scaling up or down has the desired effect. It’s also important to understand that scale up and scale out can work cooperatively together. If you scale out to the maximum number of instances available for your pricing tier, you must scale up before you can scale out further.

https://lernix.com.my/sap-s-4-hana-training-courses-malaysia

By manually scaling out and back in again, you can respond to expected increases and decreases in traffic. Scaling out has the extra benefit of increasing availability because of the increased number of instances of the web app. A failure of one instance doesn’t make the web app unavailable.

In the hotel reservation system, you can scale out before an anticipated seasonal influx. You can scale back in when the season is over and the number of booking requests is reduced.

In this unit, you learn how to manually scale out a web app and how to scale it back in.

App Service plans and scalability

A web app that runs in Azure typically uses Azure App Service to provide the hosting environment. App Service can arrange for multiple instances of the web app to run. It load balances incoming requests across these instances. Each instance runs on a virtual machine.

An App Service plan defines the resources available to each instance. The App Service plan specifies the operating system (Windows or Linux), the hardware (memory, CPU processing capacity, disk storage, and so on), and the availability of services like automatic backup and restore.

Azure provides a series of well-defined App Service plan tiers. This list summarizes each of these tiers, in increasing order of capacity and cost:

• The Free tier provides 1 GB of disk space and support for up to 10 apps, but only a single shared instance and no SLA for availability. Each app has a compute quota of 60 minutes per day. The Free service plan is suitable for app development and testing rather than production deployments.
• The Shared tier provides support for more apps (up to 100) also running on a single shared instance. Apps have a compute quota of 240 minutes per day. There’s no availability SLA.
• The Basic tier supports an unlimited number of apps and provides more disk space. Apps can be scaled out to three dedicated instances. This tier provides an SLA of 99.95% availability. There are three levels in this tier that offer varying amounts of computing power, memory, and disk storage.
• The Standard tier also supports an unlimited number of apps. This tier can scale to 10 dedicated instances and has an availability SLA of 99.95%. Like the Basic tier, this tier has three levels that offer an increasingly powerful set of computing, memory, and disk options.
• The Premium tier gives you up to 20 dedicated instances, an availability SLA of 99.95%, and multiple levels of hardware.
• The Isolated tier runs in a dedicated Azure virtual network, which gives you a network and computes isolation. This tier can scale out to 100 instances and has an availability SLA of 99.95%.

https://lernix.com.my/sap-supply-chain-management-scm-training-courses-malaysia

The purpose of a web application is to receive and respond to HTTP requests. A request is received, and then the server generates the appropriate response. Everything in ASP.NET Core is concerned with this request/response cycle.

When an ASP.NET Core app receives an HTTP request, it passes through a series of components to generate the response. These components are called middleware. Middleware can be thought of as a pipeline that the request flows through, and each middleware layer can run code before and after the next layer in the pipeline.

Middleware and delegates

Middleware is implemented as a delegate that takes a HttpContext object and returns a Task. The HttpContext object represents the current request and response. The delegate is a function that processes the request and response.

For example, consider the following code:

C#Copy

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.Run(async context =>
{
    await context.Response.WriteAsync("Hello world!");
});

app.Run();

In the preceding code:

• WebApplication.CreateBuilder(args) creates a new WebApplicationBuilder object.
• builder.Build() creates a new WebApplication object.
• The first app.Run() defines a delegate that takes a HttpContext object and returns a Task. The delegate writes “Hello world!” to the response.
• The second app.Run() starts the app.

When the app receives an HTTP request, the delegate is called. The delegate writes “Hello world!” to the response and completes the request.

Chaining middleware

In most apps, you have multiple middleware components that run in sequence. The order in which you add middleware components to the pipeline is important. The components run in the order they were added.

Terminal and nonterminal middleware

Each middleware can be thought of as terminal or nonterminal. Nonterminal middleware processes the request and then calls the next middleware in the pipeline. Terminal middleware is the last middleware in the pipeline and doesn’t have a next middleware to call.

Delegates added with app.Use() can be terminal or nonterminal middleware. These delegates expect a HttpContext object and a RequestDelegate object as parameters. Typically the delegate includes await next.Invoke();. This passes control to the next middleware on the pipeline. Code before that line runs before the next middleware, and code after that line runs after the next middleware. A delegate added with app.Use() gets two opportunities to act on a request before the response is sent to the client; once before the response is generated by the terminal middleware, and again after the response is generated by the terminal middleware.

Delegates added with app.Run() are always terminal middleware. They don’t call the next middleware in the pipeline. They’re the last middleware component that runs. They only expect a HttpContext object as a parameter. app.Run() is a shortcut for adding terminal middleware.

Consider the following example:

C#Copy

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.Use(async (context, next) =>
{
    await context.Response.WriteAsync("Hello from middleware 1. Passing to the next middleware!\r\n");

    // Call the next middleware in the pipeline
    await next.Invoke();

    await context.Response.WriteAsync("Hello from middleware 1 again!\r\n");
});

app.Run(async context =>
{
    await context.Response.WriteAsync("Hello from middleware 2!\r\n");
});

app.Run();

In the preceding code:

• app.Use() defines a middleware component that:
  • Writes “Hello from middleware 1. Passing to the next middleware!” to the response.
  • Passes the request to the next middleware component in the pipeline and waits for it to complete with await next.Invoke().
  • After the next component in the pipeline completes, it writes “Hello from middleware 1 again!”
• The first app.Run() defines a middleware component that writes “Hello from middleware 2!” to the response.
• The second app.Run() starts the app.

At runtime, when a web browser sends a request to this app, the middleware components run in the order they were added to the pipeline. The app returns the following response:

OutputCopy

Hello from middleware 1. Passing to the next middleware!
Hello from middleware 2!
Hello from middleware 1 again!

Built-in middleware

ASP.NET Core provides a set of built-in middleware components that you can use to add common functionality to your app. In addition to the explicitly added middleware components, some middleware is implicitly added for you by default. For example, WebApplication.CreateBuilder() returns a WebApplicationBuilder that adds the developer exception page routing middleware, conditionally adds the authentication and authorization middleware if the related services are configured, and adds the endpoint routing middleware.

For example, consider the following Program.cs file:

C#Copy

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddRazorComponents()
    .AddInteractiveServerComponents();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error", createScopeForErrors: true);
    // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
    app.UseHsts();
}

app.UseHttpsRedirection();

app.UseAntiforgery();

app.MapStaticAssets();
app.MapRazorComponents<App>()
    .AddInteractiveServerRenderMode();

app.Run();

In the preceding code:

• app.UseExceptionHandler() adds a middleware component that catches exceptions and returns an error page.
• app.UseHsts() adds a middleware component that sets the Strict-Transport-Security header.
• app.UseHttpsRedirection() adds a middleware component that redirects HTTP requests to HTTPS.
• app.UseAntiforgery() adds a middleware component that prevents cross-site request forgery (CSRF) attacks.
• app.MapStaticAssets() and app.MapRazorComponents<App>() map routes to endpoints, which are then handled by the endpoint routing middleware. The endpoint routing middleware is implicitly added by the WebApplicationBuilder.

There are many more built-in middleware components that you can use in your app depending on the type of app and your needs

https://lernix.com.my/sap-wm-warehouse-management-training-courses-malaysia

When you swap slots, you can precisely control the behavior and configuration of web apps.

Suppose you set up deployment slots for production and staging. You test a new version of your social media web app in the staging slot. Now it’s time to deploy that new version to production. You want to deploy the app smoothly and in the correct configuration.

Here, you learn the correct configuration to swap the web app into production.

Manage the configuration for a swap

When you swap two slots, the app’s configuration travels to the new slot along with the app. You can override this behavior for individual application settings and configuration strings by configuring them as slot settings.

Suppose, for example, you have two databases. You use one for production and the other for acceptance testing. You always want the app version in the staging slot to use the testing database. The app version in the production slot should always use the production database. You can achieve this overall configuration by configuring the database connection string as a slot setting.

Configure slot settings

To view and configure settings for the swap, go to the web app resource and follow these steps:

1. On the Azure portal menu or from the Home page, select All resources, and select the deployment slot you want to configure.
2. Go to the Configuration pane.
3. On the Application settings tab, observe whether the settings you’re interested in contain a checkmark in the deployment slot setting field. To set or unset a checkmark on a given setting, select the setting’s pencil button to edit it, then toggle the deployment slot setting checkbox to the desired value, and select OK.
4. Select Save on the Configuration pane when you’re finished to save your settings.

Swap slots in the Azure portal

To swap two slots in the Azure portal:

1. On the Azure portal menu or from the Home page, select All resources, and go to any of the deployment slots for the web app, and select the Deployment Slots pane.
2. Select Swap.
3. In the Swap dialog box, you can select the source and target slots, and see a summary of the settings to be applied to the swapped slots.

Understand the slot-swapping preview

When you swap slots, the settings in the target slot (typically the production slot) are applied to the app version in the source slot, before the hostnames are swapped. You might discover problems at this point. For example, if the database connection string is configured as a slot setting, the new version of the web app uses the existing production database. If you forgot to upgrade the database schema in the production database before the swap, you could see errors and exceptions when the new app version attempts to use the old schema.

To help you discover problems before your app goes live into production, Azure App Service offers a swap-with-preview feature. When you choose this option, the swap proceeds in two phases:

• Phase 1: Slot settings from the target slot are applied to the web app in the source slot. Azure then warms up the source slot. At this point, the swap operation pauses so you can test the app in the source slot to make sure it works with the target slot configuration. If you find no problems, begin the next phase.
• Phase 2: The hostnames for the two sites are swapped. The version of the app now in the source slot receives its slot settings.

https://lernix.com.my/microsoft-sharepoint-certification-training-courses-malaysia

Organizations often need to run web apps in isolated environments to test them before deployment. They also need to deploy quickly and without affecting users.

Suppose you’re trying to decide whether to use slots as a streamlined way to deploy a web app in your social media system. You want to find out if deployment slots reduce downtime during deployments, if they ease rollbacks, and if you can set them up in Azure.

Here, you learn how deployment slots ease the testing and rollout of new code.

Use a deployment slot

Within a single Azure App Service web app, you can create multiple deployment slots. Each slot is a separate instance of that web app, and it has a separate hostname. You can deploy a different version of your web app into each slot.

One slot is the production slot. This slot is the web app that users see when they connect. Make sure that the app deployed to this slot is stable and well tested.

Use the other slots to host new versions of your web app. Against these instances, you can run tests such as integration tests, acceptance tests, and capacity tests. Fix any problems before you move the code to the production slot. The other deployment slots behave like their own App Service instances, so you can have confidence that your tests show you how the app runs in production.

After you’re satisfied with the test results for a new app version, deploy it by swapping its slot with the production slot. Unlike a code deployment, a slot swap is instantaneous. When you swap slots, the slot hostnames are exchanged, immediately sending production traffic to the new version of the app. When you use slot swaps to deploy, your app is never exposed to the public web in a partially deployed state.

If you find that, in spite of your careful testing, the new version has a problem, you can roll back the version by swapping the slots back.

Understand slots as separate Azure resources

When you use more than one deployment slot for a web app, those slots are treated as separate instances of that web app. For example, they’re listed separately on the All resources page in the Azure portal. They each have their own URL. However, each slot shares the resources of the App Service plan, including virtual machine memory and CPU, and disk space.

Create deployment slots and tiers

Deployment slots are available only when your web app uses an App Service plan in the Standard, Premium, or Isolated tier. The following table shows the maximum number of slots you can create:

Tier	Maximum staging slots
Free	0
Shared	0
Basic	0
Standard	5
Premium	20
Isolated	20

Avoid a cold start during swaps

Many of the technologies that developers use to create web apps require final compilation and other actions on the server before they deliver a page to a user. Many of these tasks are completed when the app starts up and receives a request. For example, if you use ASP.NET to build your app, code is compiled and views are completed when the first user requests a page. Subsequent requests for that page receive a faster response, because the code is already compiled.

The initial delay is called a cold start. You can avoid a cold start by using slot swaps to deploy to production. When you swap a slot into production, you “warm up” the app because your action sends a request to the root of the site. The warm-up request ensures that all compilation and caching tasks finish. After the swap, the site responds as quickly as if it were deployed for days.

Create a deployment slot

Before you create a slot, make sure your web app is running in the Standard, Premium, or Isolated tier:

1. Open your web app in the Azure portal.
2. Select the Deployment Slots pane.
3. Select Add Slot.
4. Name the slot.
5. Choose whether to clone settings from another slot. If you choose to clone, settings are copied to your new slot from the slot you specify.

 Note

Although you can clone settings to a new slot, you can’t clone content. New slots always begin with no content. You must deploy content by using Git or another deployment strategy. The clone operation copies the configuration to the new slot. After you clone the settings, the configuration of the two slots can be changed independently.

Select Add to create the new slot. You now have the new slot in the list on the Deployment Slots page. Select the slot to view its management pane.

Access a slot

The new slot’s hostname is derived from the web app name and the name of the slot. You get this hostname when you select the slot on the Deployment Slots page:

You can deploy your code to the new slot the same way you deploy it for the production slot. Just substitute the new slot’s name or URL in the configuration of the deployment tool you use. If you use FTP to deploy, you see the FTP hostname and username just under the slot’s URL.

The new slot is effectively a separate web app with a different hostname. Anyone on the internet can access it if they know that hostname. Unless you register the slot with a search engine or link to it from a crawled page, the slot doesn’t appear in search-engine indexes. It remains obscure to the general internet user.

You can control access to a slot by using IP address restrictions. Create a list of IP address ranges that are allowed access to the slot or a list of ranges that are denied access to the slot. These lists are like the allow and deny ranges that you can set up on a firewall. Use this list to permit access only to computers that belong to your company or development team.

https://lernix.com.my/microsoft-sql-server-certification-training-courses-malaysia

Code challenges throughout these modules will reinforce what you’ve learned and help you gain some confidence before continuing on.

Challenge: Write code in the .NET Editor to display two messages

1. Select all of the code in the .NET Editor, and press Delete or Backspace to delete it.
2. Write code that produces the following output:OutputCopyThis is the first line. This is the second line. In the previous unit, you learned how to display a message in just one line of code, and you learned how to display a message using multiple lines of code. Use both techniques for this challenge. It doesn’t matter which technique you apply to which line, and it doesn’t matter how many ways you split one of the messages into multiple lines of code. That’s your choice.No matter how you do it, your code should produce the specified output.

Whether you get stuck and need to peek at the solution or you finish successfully, continue to the next unit to view a solution to this challenge.

https://lernix.com.my/vmware-certification-training-courses-malaysia

To understand how your code works, you need to step back and think about what a programming language is. Consider how your code communicates commands to the computer.

What is a programming language?

Programming languages like C# let you write instructions that you want the computer to carry out. Each programming language has its own syntax, but after learning your first programming language and attempting to learn another one, you’ll quickly realize that they all share many similar concepts. A programming language’s job is to allow a human to express their intent in a human-readable and understandable way. The instructions you write in a programming language are called “source code” or just “code”. Software developers write code.

At this point, a developer can update and change the code, but the computer can’t understand the code. The code first must be compiled into a format that the computer can understand.

What is compilation?

A special program called a compiler converts your source code into a different format that the computer’s central processing unit (CPU) can execute. When you used the green Run button in the previous unit, the code you wrote was first compiled, then executed.

Why does code need to be compiled? Although most programming languages seem cryptic at first, they can be more easily understood by humans than the computer’s preferred language. The CPU understands instructions that are expressed by turning thousands or millions of tiny switches either on or off. Compilers bridge these two worlds by translating your human-readable instructions into a computer-understandable set of instructions.

What is syntax?

The rules for writing C# code is called syntax. Just like human languages have rules regarding punctuation and sentence structure, computer programming languages also have rules. Those rules define the keywords and operators of C# and how they are put together to form programs.

When you wrote code into the .NET Editor, you may have noticed subtle changes to the color of different words and symbols. Syntax highlighting is a helpful feature that you’ll begin to use to easily spot mistakes in your code that don’t conform to the syntax rules of C#.

How did your code work?

Let’s focus on the following line of code you wrote:

C#Copy

Console.WriteLine("Hello World!");

When you ran your code, you saw that the message Hello World! was printed to the output console. When the phrase is surrounded by double-quotation marks in your C# code, it’s called a literal string. In other words, you literally wanted the characters H, e, l, l, o, and so on, sent to the output.

The Console part is called a class. Classes “own” methods; or you could say that methods live inside of a class. To visit the method, you must know which class it’s in. For now, think of a class as a way to represent an object. In this case, all of the methods that operate on your output console are defined inside of the Console class.

There’s also a dot (or period) that separates the class name Console and the method name WriteLine(). The period is the member access operator. In other words, the dot is how you “navigate” from the class to one of its methods.

The WriteLine() part is called a method. You can always spot a method because it has a set of parentheses after it. Each method has one job. The WriteLine() method’s job is to write a line of data to the output console. The data that’s printed is sent in between the opening and closing parenthesis as an input parameter. Some methods need input parameters, while others don’t. But if you want to invoke a method, you must always use the parentheses after the method’s name. The parentheses are known as the method invocation operator.

Finally, the semicolon is the end of statement operator. A statement is a complete instruction in C#. The semicolon tells the compiler that you’ve finished entering the command.

Don’t worry if all of these ideas and terms don’t make sense. For now, all you need to remember is that if you want to print a message to the output console:

• Use Console.WriteLine("Your message here");
• Capitalize Console, Write, and Line
• Use the correct punctuation because it has a special role in C#
• If you make a mistake, just spot it, fix it and re-run

https://lernix.com.my/microsoft-windows-server-certification-training-courses-malaysia

Starting a new project, including setting up the initial structure and configurations, can be a daunting task. Fortunately, ASP.NET Core provides various project templates that simplify this process. The project templates offer a standardized and efficient way to kickstart your development. This unit explores the different ASP.NET Core project templates available and how to use them to create new projects.

What the ASP.NET Core project templates provide

The .NET SDK includes built-in templates for creating ASP.NET Core projects and files. ASP.NET Core project templates are used to create new ASP.NET Core projects with the necessary files, folders, and configurations to get a project up and running efficiently.

With the .NET SDK installed, you can run .NET CLI (Command Line Interface) commands in a terminal or command prompt. To list the built-in templates, run the dotnet new list command:

.NET CLICopy

dotnet new list

Some common ASP.NET Core default project templates include:

web ASP.NET Core Empty: An empty project template for creating an ASP.NET Core application. This template doesn’t have any example content in it.

blazor Blazor Web App: A project template for creating a Blazor web app that supports both server-side rendering and client interactivity. This template can be used for web apps with rich dynamic user interfaces (UIs).

webapi ASP.NET Core Web API: A project template for creating a RESTful Web API using ASP.NET Core controllers or minimal APIs, with optional support for OpenAPI and authentication.

grpc ASP.NET Core gRPC Services: A project template for creating a gRPC service using ASP.NET Core.

Customization options

All .NET project templates offer customization options to tailor the generated project to specific needs and extend it with additional services. For instance, you can add Entity Framework Core for database access, authentication, OpenAPI, caching, logging, and more, enabling the application to effectively meet specific requirements.

To view all customization options for a specific template, use the following dotnet new command with the --help option, replacing <template-name> with the name of the template you want to explore:

.NET CLICopy

dotnet new <template-name> --help

Using the .NET CLI dotnet new command to create a project

You can create a new project using the dotnet new <template-name> command. For example, to create a new empty ASP.NET Core web app project you can run dotnet new web.

Once you create a new .NET project, you can build and run the project using the dotnet build and dotnet run commands.

Alternatively you can create, run, and debug .NET projects with tools like Visual Studio and Visual Studio Code which provide convenient user interfaces.

https://lernix.com.my/agile-project-management-certification-training-courses-malaysia

Use the do-while and while statements to iterate as long as a Boolean expression evaluates to true.

Learning objectives

After you complete this module, you’ll be able to:

• Write code that uses the do-while statement to iterate through a code block
• Write code that uses the while statement to iterate through a code block
• Use the continue statement to step directly to the Boolean evaluation

https://lernix.com.my/red-hat-certified-system-administrator-rhcsa-malaysia