European ASP.NET 4.5 Hosting BLOG

BLOG about ASP.NET 4, ASP.NET 4.5 Hosting and Its Technology - Dedicated to European Windows Hosting Customer

European ASP.NET Core Hosting :: Error When Published ASP.NET Core? See Below Tips!

clock November 5, 2019 05:38 by author Scott

At the past few years, we have discussed about common error that you can find when published .NET Core, the most common error is 502.5 – process failure error.

Startup errors with ASP.NET Core don’t provide much information either, at least not in a production environment. Here are 7 tips for understanding and fixing those errors.

1. There are two types of startup errors.

There are unhandled exceptions originating outside of the Startup class, and exceptions from inside of Startup. These two error types can produce different behavior and may require different troubleshooting techniques.

2. ASP.NET Core will handle exceptions from inside the Startup class.

If code in the ConfigureServices or Configure methods throw an exception, the framework will catch the exception and continue execution.

Although the process continues to run after the exception, every incoming request will generate a 500 response with the message “An error occurred while starting the application”.

Two additional pieces of information about this behavior:

- If you want the process to fail in this scenario, call CaptureStartupErrors on the web host builder and pass the value false.

- In a production environment, the “error occurred” message is all the information you’ll see in a web browser. The framework follows the practice of not giving away error details in a response because error details might give an attacker too much information. You can change the environment setting using the environment variable ASPNETCORE_ENVIRONMENT, but see the next two tips first. You don’t have to change the entire environment to see more error details.

3. Set detailedErrors in code to see a stack trace.

The following bit of code allows for detailed error message, even in production, so use with caution.

public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
           .CaptureStartupErrors(true) // the default
           .UseSetting("detailedErrors", "true")
           .UseStartup<Startup>();

4. Alternatively, set the ASPNETCORE_DETAILEDERRORS environment variable.

Set the value to true and you’ll also see a stack trace, even in production, so use with caution.

5. Unhandled exceptions outside of the Startup class will kill the process.

Perhaps you have code inside of Program.cs to run schema migrations or perform other initialization tasks which fail, or perhaps the application cannot bind to the desired ports. If you are running behind IIS, this is the scenario where you’ll see a generic 502.5 Process Failure error message.

These types of errors can be a bit more difficult to track down, but the following two tips should help.

6. For IIS, turn on standard output logging in web.config.

If you are carefully logging using other tools, you might be able to capture output there, too, but if all else fails, ASP.NET will write exception information to stdout by default. By turning the log flag to true, and creating the output directory, you’ll have a file with exception information and a stack trace inside to help track down the problem.

The following shows the web.config file created by dotnet publish and is typically the config file in use when hosting .NET Core in IIS. The attribute to change is the stdoutLogEnabled flag.

<system.webServer>
  <handlers>
    <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />

  </handlers>
  <aspNetCore processPath="dotnet" arguments=".\codes.dll"
              stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" />
</system.webServer>

Important: Make sure to create the logging output directory.

Important: Make sure to turn logging off after troubleshooting is complete.

7. Use the dotnet CLI to run the application on your server.

If you have access to the server, it is sometimes easier to go directly to the server and use dotnet to witness the exception in real time. There’s no need to turn on logging or set and unset environment variables.

Summary

Debugging startup errors in ASP.NET Core is a simple case of finding the exception. In many cases, #7 is the simplest approach that doesn’t require code or environment changes. FYI, we also have support latest ASP.NET Core on our hosting environment. Feel free to visit our site at https://www.hostforlife.eu.



European ASP.NET Core Hosting :: InProcess and OutOfProcess Hosting Model In ASP.NET Core

clock September 17, 2019 11:37 by author Scott

Once you finish developing an ASP.NET Core web application, you need to deploy it on a server so that end users can start using it. When it comes to deployment to IIS, ASP.NET Core offers two hosting models namely InProcess and OutOfProcess. In this article you learn about these hosting models and how to configure them.

When you deploy your web application to IIS, various requests to the application are handled by what is known as ASP.NET Core Module. Under default settings the hosting model for your application is InProcess. This means ASP.NET Core Module forwards the requests to IIS HTTP Server (IISHttpServer). The IIS HTTP Server is a server that runs in-process with IIS. This results in great performance as compared to Out Of Process model. In-process models bypasses built-in Kestrel web server of ASP.NET Core.

If you decide to use Out-Of-Process hosting model then IIS HTTP Server won't be used. Instead Kestrel web server is used to process your requests. So, ASP.NET Core Module forwards your requests to Kestrel web server. This communication is out-of-process communication and is therefore slower than the in-process model.

Now that you have some basic idea about the in-process and out-of-process hosting models let's see how to configure them.

In order to understand the hosting models discussed in this article you first need to create an ASP.NET Core web application using Visual Studio. So, go ahead and do so based on any of the web application project templates. Make sure to use ASP.NET Core version 2.2 or later.

Once you create the project, click on the Build > Publish menu and Web Deploy the output (or manually copy to IIS) to IIS. Once you finish deploying the application locate the web.config file generated during the deployment process. In this web.config you will find a section like this:

<system.webServer>
  <handlers>
    <add name="aspNetCore" path="*" verb="*"
modules="AspNetCoreModuleV2" />
  </handlers>
  <aspNetCore processPath="dotnet"
              arguments=".\MyWebApp.dll"  
              stdoutLogEnabled="false"
              stdoutLogFile=".\logs\stdout"
              hostingModel="inprocess" />
</system.webServer>

As you can see the <aspNetCore> tag has hostingModel attribute that is set to inprocess by default.

Now, run the application from the browser with this default setting in place and observe the HTTP headers. The following figure shows one such sample run of the application.

As you can see the Server is Microsoft IIS.

Now, change the hostingModel attribute from inprocess to outofprocess. Run the application again. This time you will get the following output:

As you can see the Server is now Kestrel indicating that Out-Of-Process model is active.

In the preceding example you change the hosting model in the web.config generated during the publish operation. You can also specify the hosting model in project's .csproj file. Consider the following markup from .csproj file that does that.

<PropertyGroup>
    <TargetFramework>netcoreapp2.2</TargetFramework>
    <AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
</PropertyGroup>

The <AspNetCoreHostingModel> element sets the hosting model to InProcess. To set it to Out-Of-Process you need to set it like this:

<AspNetCoreHostingModel>OutOfProcess</AspNetCoreHostingModel>

Run the application with these settings and confirm whether you get the outcome as before.

That's it for now! Keep coding!!



ASP.NET Hosting HostForLIFE.eu :: Centralized Exception Handling Without Using Try Catch Block In .Net Core 2.2 Web API

clock September 3, 2019 12:00 by author Peter

Rather than writing try catch block for each method, throwing exceptions manually and handling them, here we will use the power of .Net Core middleware to handle the exceptions at one single place, so that when an exception occurs anywhere in the code, the appropriate action can be taken. We will use UseExceptionHandler extension method that will add a middleware to the pipeline, and it will catch exceptions, log them, reset the request path, and re-execute the request if response has not already started.

Developer can customize the response format as well.

To achive this in .NetCore 2.2, this code snippet is very simple and it's just a matter of adding a few lines in your Startup.cs.

Simply go in Configure method and add the below code,
if (env.IsDevelopment()) {  
    app.UseDeveloperExceptionPage();  
} else {  
    app.UseExceptionHandler(errorApp => errorApp.Run(async context => {  
        // use Exception handler path feature to catch the exception details   
        var exceptionHandlerPathFeature = context.Features.Get < IExceptionHandlerPathFeature > ();  
        // log errors using above exceptionHandlerPathFeature object   
        Console.WriteLine(exceptionHandlerPathFeature ? .Error);  
        // Write a custom response message to API Users   
        context.Response.StatusCode = "500";  
        // Set a response format    
        context.Response.ContentType = "application/json";  
        await context.Response.WriteAsync("Some error occured.");  
    }));  
}  


The Console.WriteLine() is for demonstration purposes only. Here a developer can log the exceptions using any tool/package getting used in their project.

When any exceptions are thrown in the application this code will be executed and will produce the desired custom response in non-development environments (as in a development env we are using UseDeveloperExceptionPage() as a middleware).

HostForLIFE.eu ASP.NET 4.8 Hosting
HostForLIFE.eu is European Windows Hosting Provider which focuses on Windows Platform only. We deliver on-demand hosting solutions including Shared hosting, Reseller Hosting, Cloud Hosting, Dedicated Servers, and IT as a Service for companies of all sizes. We have customers from around the globe, spread across every continent. We serve the hosting needs of the business and professional, government and nonprofit, entertainment and personal use market segments.

 



European ASP.NET Core Hosting :: Rotate Ads Without Refreshing the Page Using AdRotator in ASP.NET

clock August 20, 2019 12:18 by author Peter

This article explains the concept of the AdRotator control without the user refreshing the page and rotates the ads on a certain time interval. This article also gives a tip to fetch ad information from an XML file. The AdRotator Control presents ad images each time a user enters or refreshes a webpage. When the ads are clicked, it will navigate to a new web location. However the ads are rotated only when the user refreshes the page. In this article, we will explore how you can easily rotate ads at regular intervals, without the user refreshing the page. First of all start Visual Studio .NET And make a new ASP.NET web site using Visual Studio 2010.
 
Now you have to create a web site.
Go to Visual Studio 2010
New-> Select a website application
Click OK

Now add a new page to the website.

    Go to the Solution Explorer
    Right-click on the Project name
    Select add new item
    Add new web page and give it a name
    Click OK

We create an images folder in the application which contains some images to rotate in the AdRotator control. Now add a XML file. To do so, right-click the App_Data folder > Add New Item > 'XML File' > Rename it to adXMLFile.xml and click Add. Put this code in the .XML File.

    <?xml version="1.0" encoding="utf-8" ?> 
    <Advertisements> 
    <Ad> 
    <ImageUrl>~/Images/image1.gif</ImageUrl> 
    <NavigateUrl>http://www.c-sharpcorner.com/</NavigateUrl> 
    <AlternateText>C-sharpcorner Home Page</AlternateText> 
    <Impressions>3</Impressions> 
    <Keyword>small</Keyword> 
    </Ad> 
    <Ad> 
    <ImageUrl>~/images/forest_wood.JPG</ImageUrl> 
    <NavigateUrl>http://www.c-sharpcorner.com/</NavigateUrl> 
    <AlternateText>C-sharpcorner Home Page</AlternateText> 
    <Impressions>2</Impressions> 
    <Keyword>small</Keyword> 
    </Ad> 
    <Ad> 
    <ImageUrl>~/images/image2.gif</ImageUrl> 
    <Width>300</Width> 
    <Height>50</Height> 
    <NavigateUrl>http://www.c-sharpcorner.com/</NavigateUrl> 
    <AlternateText>C-sharpcorner Home Page</AlternateText> 
    <Impressions>3</Impressions> 
    <Keyword>small</Keyword> 
    </Ad> 
    </Advertisements> 


XML file elements

  • Here is a list and a description of the <Ad> tag items.
  • ImageUrl - The URL of the image to display.
  • NavigateUrl - The URL where the page will go after AdRotator image is clicked.
  • AlternateText - Text to display if the image is unavailable.
  • Keyword - Category of the ad, which can be used to filter for specific ads.
  • Impressions - Frequency of ad to be displayed. This number is used when you want some ads to be displayed more frequently than others.
  • Height - Height of the ad in pixels.
  • Width - Width of the ad in pixel.

Now drag and drop an AdRotator control from the toolbox to the .aspx and bind it to the advertisement file. To bind the AdRotator to our XML file, we will make use of the "AdvertisementFile" property of the AdRotator control as shown below:
    <asp:AdRotator 
    id="AdRotator1" 
    AdvertisementFile="~/adXMLFile.xml" 
    KeywordFilter="small" 
    Runat="server" /> 


To rotate the ads without refreshing the page, we will add some AJAX code to the page.
    <Triggers> 
    <asp:AsyncPostBackTrigger ControlID="Timer1" EventName="Tick" /> 
    </Triggers> 


The .aspx code will be as shown below.
 
Now drag and drop an UpdatePanel and add an AdRotator control into it. The DataList code looks like this:
    <%@ Page Language="C#" AutoEventWireup="true" CodeFile="adrotator.aspx.cs" Inherits="adrotator" %> 
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 
    <html xmlns="http://www.w3.org/1999/xhtml"> 
    <head runat="server"> 
    <title></title> 
    </head> 
    <body> 
    <form id="form1" runat="server"> 
    <div> 
    <asp:ScriptManager ID="ScriptManager1" runat="server" /> 
    <asp:Timer ID="Timer1" Interval="1000" runat="server" /> 
    <asp:UpdatePanel ID="up1" runat="server"> 
    <Triggers> 
    <asp:AsyncPostBackTrigger ControlID="Timer1" EventName="Tick" /> 
    </Triggers> 
    <ContentTemplate> 
    <asp:AdRotator ID="AdRotator1" AdvertisementFile="~/adXMLFile.xml" KeywordFilter="small" 
    runat="server" /> 
    </ContentTemplate> 
    </asp:UpdatePanel> 
    </div> 
    </form> 
    </body> 
    </html> 


Now run the application and test it. The AdRotator control rotates the ads without the user refreshing the page and rotates the ads on a certain time interval



European ASP.NET Core Hosting :: Session Wrapper Design Pattern For ASP.NET Core

clock August 14, 2019 11:11 by author Peter

In this article, we will learn to access the Session data in a Typed manner by getting IntelliSense support. We learned how to use Session in ASP.NET Core. In this article, we'll learn about Session Wrapper design pattern to ease the access of Session. In short, we'll make our access of session "Typed". Also, we may apply any validation or constraint in this wrapper class.

Step 1 - Create a Session Manager class

In this example, we are going to store two items in Session (i.e. ID & LoginName).
We are injecting IHttpContextAccessor so that we can access the Session variable.
We are creating properties which are actually accessing Session variable and returning the data or writing the data to Session.
We have added one helping property "IsLoggedIn" which is using other properties to make a decision. We may have more such helping/wrapper properties.
using Microsoft.AspNetCore.Http;

public class SessionManager 

    private readonly ISession _session; 
    private const String ID_KEY = "_ID"; 
    private const String LOGIN_KEY = "_LoginName"; 
    public SessionManager(IHttpContextAccessor httpContextAccessor) 
    { 
        _session = httpContextAccessor.HttpContext.Session; 
    } 

    public int ID 
    { 
        get 
        { 
            var v = _session.GetInt32(ID_KEY); 
            if (v.HasValue) 
                return v.Value; 
            else 
                return 0; 
        } 
        set 
        { 
            _session.SetInt32(ID_KEY, value); 
        } 
    } 
    public String LoginName 
    { 
        get 
        { 
            return _session.GetString(LOGIN_KEY); 
        } 
        set 
        { 
            _session.SetString(LOGIN_KEY, value); 
        } 
    } 
    public Boolean IsLoggedIn 
    { 
        get 
        { 
            if (ID > 0) 
                return true; 
            else 
                return false; 
        } 
    } 
}
 

Step 2
Registering IHttpContextAccessor and SessionManager in Startup file.
services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>(); 
services.AddScoped<SessionManager>(); 


Step 3
Injecting SessionManager in your classes. Here is an example of Controller class but in the same way, it can be injected in non-controller classes too.
private readonly SessionManager _sessionManager; 
public HomeController(SessionManager sessionManager) 

  _sessionManager = sessionManager; 


Step 4
Using SessionManager to access Session Data,
_sessionManager.ID = 1; 
_sessionManager.LoginName = dto.Login; 

if(_sessionManager.IsLoggedIn == true) 

ViewBag.Login = _sessionManager.LoginName; 
return View(); 


Conclusion
This wrapper pattern helps using Session without worrying about KeyNames & Makes access easier. It also helps you apply different conditioning and constraints in a wrapper class.

 



European ASP.NET Core Hosting :: How to Use Serilog with ASP.NET Core 2

clock August 7, 2019 08:48 by author Scott

Today, I will discuss about Serilog. What is Serilog? Serilog is an open source event library for .NET. Serilog gives you two important components: loggers and sinks (outputs). Most applications will have a single static logger and several sinks, so in this example I’ll use two: the console and a rolling file sink.

Starting with a new ASP.NET Core 2.0 Web Application running on .NET Framework (as in the image to the right), begin by grabbing a few packages off NuGet:

  • Serilog
  • Serilog.AspNetCore
  • Serilog.Settings.Configuration
  • Serilog.Sinks.Console
  • Serilog.Sinks.RollingFile

Next, you will need to modify some files.

Startup.cs

Startup constructor

Create the static Log.Logger by reading from the configuration (see appsettings.json below). The constructor should now look like this:

public Startup(IConfiguration configuration)
{
   Log.Logger = new LoggerConfiguration().ReadFrom.Configuration(configuration).CreateLogger();
Configuration = configuration;
}

BuildWebHost method

Next, add the .UseSerilog() extension to the BuildWebHost method. It should now look like this:

public static IWebHost BuildWebHost(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseStartup<Startup>()
.UseSerilog() // <-- Add this line
.Build();

The BuildWebHost method might look strange because the body of this method is called an expression body rather than a traditional method with a statement body.

Configure method

At the start of the configure method, add one line at the top to enable the Serilog middleware. You can optionally remove the other loggers as this point as well. Your Configure method should start like this:

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
     loggerFactory.AddSerilog(); // <-- Add this line
     ...

appsettings.json

At the root level of the appsettings.json (or one of the environment-specific settings files), add something like this:

"Serilog": {
     "Using": [ "Serilog.Sinks.Console" ],
     "MinimumLevel": "Debug",
     "WriteTo": [
            { "Name": "Console" },
            {
                    "Name": "RollingFile",
                    "Args": {
                          "pathFormat": "logs\\log-{Date}.txt",
                          "outputTemplate": "{Timestamp:yyyy-MM-dd HH:mm:ss.fff zzz} [{Level}] {Message}{NewLine}{Exception}"
                    }
            }
     ],
     "Enrich": [ "FromLogContext", "WithMachineName", "WithThreadId" ],
     "Properties": {
     "Application": "My Application"
            }
}

If you’re wondering about the pathFormat and what other parameters you can use, there aren’t that many. {Date} is the only “switch” you can use with this particular sink. But you can use any environment variable (things like %TEMP%), allowing for a pathFormat of:

"%TEMP%\\logs\\log-{Date}.txt"

The outputTemplate has a LOT of options that I won’t get into here because the official documentation does a great job of explaining it.

As for the event levels, I’ve copied the list below from the official documentation for reference.

  1. Verbose – tracing information and debugging minutiae; generally only switched on in unusual situations
  2. Debug – internal control flow and diagnostic state dumps to facilitate pinpointing of recognised problems
  3. Information – events of interest or that have relevance to outside observers; the default enabled minimum logging level
  4. Warning – indicators of possible issues or service/functionality degradation
  5. Error – indicating a failure within the application or connected system
  6. Fatal – critical errors causing complete failure of the application

You’ll also notice in the above JSON that the “Using” property is set to an array containing “Serilog.Sinks.Console” but not “Serilog.Sinks.RollingFile”. Everything appears to work, so I am not sure what impact this property has.  



European ASP.NET Core Hosting :: How to Fix “An error occurred while starting the application” in ASP.NET Core on IIS

clock July 5, 2019 07:33 by author Scott

.NET Core is the latest Microsoft product and Microsoft always keep update their technologies. We have written tutorial about how to publish ASP.NET Core on IIS server, but we know that some of you sometimes receive error when deploying your ASP.NET Core. Feel frustrated to fix the issue? Yeah, not only you have headache, but some of our clients also experience same problem like you. That’s why we write this tutorial and hope it can help to fix your issue!

Anyone see this error? Have problem to solve it? We want to help you here!

The Problem

 

It basically means something bad happened with your application. Things you need to check

  • You might not have the correct .NET Core version installed on the server.
  • You might be missing DLL’s
  • Something went wrong in your Program.cs or Startup.cs before any exception handling kicked in

If you use Windows Server, then I believe that you can’t find anything on your Event Viewer too. You’ll notice that there is no error on your Event Viewer log. Why? This is because Event Logging must be wired up explicitly and you’ll need to use the Microsoft.Extensions.Logging.EventLog package, and depending on the error, you might not have a chance to even catch it to log to the Event Viewer.

How to Fix it?

So, how to fix error above? The followings are the steps to fix the error:

1. Open your web.config

2. Change stdoutLogEnabled=true

3. Create a logs folder

  • Unfortunately, the AspNetCoreModule doesn’t create the folder for you by default
  • If you forget to create the logs folder, an error will be logged to the Event Viewer that says: Warning: Could not create stdoutLogFile \\?\YourPath\logs\stdout_timestamp.log, ErrorCode = -2147024893.
  • The “stdout” part of  the value “.\logs\stdout” actually references the filename not the folder.  Which is a bit confusing.

4. Run your request again, then open the \logs\stdout_*.log file

Note – you will want to turn this off after you’re done troubleshooting, as it is a performance hit.

So your web.config’s aspNetCore element should look something like this

 <aspNetCore processPath=”.\YourProjectName.exe” stdoutLogEnabled=”true” stdoutLogFile=”.\logs\stdout” />

Doing this will log all the requests out to this file and when the exception occurs, it will give you the full stack trace of what happened in the \logs\stdout_*.log file

  

 

 

Hope this helps!

Looking for ASP.NET Core hosting with affordable cost?

We know it is quite hard to find reliable hosting that support ASP.NET Core. We believe that some of you have signed up for 1 hosting, but they are below your expectation. Maybe they don’t support latest ASP.NET Core or they might support .NET Core but their support are not competent. We are here to help you. If you are looking for cheap, reliable with best ASP.NET Core hosting support, then you can visit our site at https://www.hostforlife.eu.



European ASP.NET Core Hosting :: Integration Test ASP.NET Core

clock June 25, 2019 09:19 by author Scott

Writing integration tests for ASP.NET Core controller actions used for file uploads is not a rare need. It is fully supported by ASP.NET Core integration tests system. This post shows how to write integration tests for single and multiple file uploads.

Getting started

Suppose we have controller action for file upload that supports multiple files. It uses complex composite command for image file analysis and saving. Command is injected to action by framework-level dependency injection using controller action injection.

[HttpPost]
[Authorize(Roles = "Admin")]
public async Task<IActionResult> Upload(IList<IFormFile> files, int? parentFolderId,
                                        [FromServices]SavePhotoCommand savePhotoCommand)
{
    foreach(var file in files)
    {
        var model = new PhotoEditModel();
        model.FileName = Path.GetFileName(file.FileName);
        model.Thumbnail = Path.GetFileName(file.FileName);
        model.ParentFolderId = parentFolderId;
        model.File = file;
 
        list.AddRange(savePhotoCommand.Validate(model));
 
        await savePhotoCommand.Execute(model);
    }
 
    ViewBag.Messages = savePhotoCommand.Messages;
 
    return View();
}

We want to write integration tests for this action but we need to upload at least one file to make sure that command doesn’t fail.

Making files available for integration tests

It’s good practice to have files for testing available no matter where tests are run. It’s specially true when writing code in team or using continuous integration server to run integration tests. If we don’t have many files and the files are not large then we can include those files in project.

Important thing is to specify in Visual Studio that these files are copied to output folder.

Same way it’s possible to use also other types of files and nobody stops us creating multiple folders or folder trees if we want to organize files better.

Uploading files in integration tests

Here is integration tests class for controller mentioned above. Right now there’s only one test and it is testing Upload action. Notice how image files are loaded from TestPhotos folder to file streams and how form data object is built using the file streams.

public class PhotosControllerTests : IClassFixture<WebApplicationFactory<Startup>>
{
    private readonly WebApplicationFactory<Startup> _factory;
 
    public PhotosControllerTests(WebApplicationFactory<Startup> factory)
    {
        _factory = factory;
    }
 
    [Fact]
    public async Task Upload_SavesPhotoAndReturnSuccess()
    {
        // Arrange
        var expectedContentType = "text/html; charset=utf-8";
        var url = "Photos/Upload";
        var options = new WebApplicationFactoryClientOptions { AllowAutoRedirect = false };
        var client = _factory.CreateClient(options);
 
        // Act
        HttpResponseMessage response;
 
        using (var file1 = File.OpenRead(@"TestPhotos\rt-n66u.jpg.webp"))
        using (var content1 = new StreamContent(file1))
        using (var file2 = File.OpenRead(@"TestPhotos\speedtest.png.webp"))
        using (var content2 = new StreamContent(file2))
        using (var formData = new MultipartFormDataContent())
        {
            // Add file (file, field name, file name)
            formData.Add(content1, "files", "rt-n66u.jpg.webp");
            formData.Add(content2, "files", "speedtest.png.webp");
 
            response = await client.PostAsync(url, formData);
        }
 
        // Assert
        response.EnsureSuccessStatusCode();
        var responseString = await response.Content.ReadAsStringAsync();
 
        Assert.NotEmpty(responseString);
        Assert.Equal(expectedContentType, response.Content.Headers.ContentType.ToString());
 
        response.Dispose();
        client.Dispose();
    }
}

For actions that accept only one file we need only one call to Add() method of formData.

Wrapping up

Integration tests mechanism in ASP.NET Core is flexible enough to support also more advanced scenarios like file uploads in tests. It’s not very straightforward and we can’t just call few methods of HTTP client to do it but it’s still easy enough once we know the tricks. If we keep test files in integration tests project then we don’t have to worry about getting files to machine where integration tests are running.



European ASP.NET Core Hosting - HostForLIFE.eu :: Javascript, CSS, HTML in ASP.NET Core

clock April 12, 2019 09:45 by author Scott

This article will teach you how to include and customize the use of static files in ASP .NET Core web applications. It is not a tutorial on front-end web development.

If your ASP .NET Core web app has a front end – whether it’s a collection of MVC Views or a Single-Page Application (SPA) – you will need to include static files in your application. This includes (but is not limited to): JavaScript, CSS, HTML and various image files.

When you create a new web app using one of the built-in templates (MVC or Razor Pages), you should see a “wwwroot” folder in the Solution Explorer. This points to a physical folder in your file system that contains the same files seen from Visual Studio. However, this location can be configured, you can have multiple locations with static files, and you can enable/disable static files in your application if desired. In fact, you have to “opt in” to static files in your middleware pipeline.

Configuring Static Files via Middleware

Let’s start by observing the Startup.cs configuration file. We’ve seen this file several times throughout this blog series. In the Configure() method, you’ll find the familiar method call to enable the use of static files.

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
   ...
   app.UseStaticFiles();
   ...
   app.UseMvc(...);
}

This call to app.UseStaticFiles() ensures that static files can be served from the designated location, e.g. wwwroot.

It’s useful to note the placement of this line of code. It appears before app.UseMvc(), which is very important. This ensures that static file requests can be processed and sent back to the web browser without having to touch the MVC middleware. This becomes even more important when authentication is used.

In the code below, you can see the familiar call to app.UseStaticFiles() once again. However, there is also a call to app.UseAuthentication(). It’s important for the authentication call to appear after the call to use static files. This ensure that the authentication process isn’t triggered when it isn’t needed.

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
   ...
   app.UseStaticFiles();
   ...
   app.UseAuthentication();
   ...
   app.UseMvc(...);
}

By using the middleware pipeline in this way, you can “short-circuit” the pipeline when a request has been fulfilled by a specific middleware layer. If a static file has been successfully served using the Static Files middleware, it prevents the next layers of middleware (i.e. authentication, MVC) from processing the request.

Customizing Locations for Static Files

It may be convenient to have the default web templates create a location for your static files and also enable the use of those static files. As you’ve already seen, enabling static files isn’t magic. Removing the call to app.useStaticFiles() will disable static files from being served. In fact, the location for static files isn’t magic either.

public class Program
{
   ...
   public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
      WebHost.CreateDefaultBuilder(args)
         .UseStartup<Startup>();
}

Behind the scenes, this method call sets the “content root” to the current directory, which contains the “wwwroot” folder, your project’s “web root”. These can both be customized.

WebHost.CreateDefaultBuilder(args).UseContentRoot("c:\\<content-root>")

WebHost.CreateDefaultBuilder(args).UseWebRoot("public")

You may also use the call to app.UseStaticFiles() to customize an alternate location to serve static files. This allows you to serve additional static files from a location outside of the designated web root.

...
using Microsoft.Extensions.FileProviders;
using System.IO;
...
public void Configure(IApplicationBuilder app)
{
   ...
   app.UseStaticFiles(new StaticFileOptions
   {
      FileProvider = new PhysicalFileProvider
         Path.Combine(env.ContentRootPath, "AltStaticRoot")),
         RequestPath = "/AltStaticFiles"
   });
}

Wait a minute… why does it look like there are two alternate locations for static files? There is a simple explanation:

  • In the call to Path.Combine(), the “AltStaticRoot” is an actual folder in your current directory. This Path class and its Combine() method are available in the System.IO namespace.
  • The “AltStaticFiles” value for RequestPath is used as a root-level “virtual folder” from which images can be served. The PhysicalFileProvider class is available in the Microsoft.Extensions.FileProviders namespace.

The following markup may be used in a .cshtml file to refer to an image, e.g. MyImage01.png:

<img src="~/AltStaticFiles/MyImages/MyImage01.png" />

The screenshot below shows an example of an image loaded from an alternate location.

The screenshot below shows a web browser displaying such an image.

Preserving CDN Integrity

When you use a CDN (Content Delivery Network) to serve common CSS and JS files, you need to ensure that the integrity of the source code is reliable. You can rest assured that ASP .NET Core has already solved this problem for you in its built-in templates.

<environment include="Development">
 <link rel="stylesheet" href="~/lib/bootstrap/dist/css/bootstrap.css" />
</environment>

<environment exclude="Development">
 <link
   rel="stylesheet"
   href=
https://cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/4.1.3/css/bootstrap.min.css
   asp-fallback-href="~/lib/bootstrap/dist/css/bootstrap.min.css"
   asp-fallback-test-class="sr-only"
   asp-fallback-test-property="position"
   asp-fallback-test-value="absolute"
   crossorigin="anonymous"
   integrity="sha256-eSi1q2PG6J7g7ib17yAaWMcrr5GrtohYChqibrV7PBE="/>
</environment>

Right away, you’ll notice that there are two conditional <environment> blocks in the above markup. The first block is used only during development, in which the bootstrap CSS file is obtained from your local copy. When not in development (e.g. staging, production, etc), the bootstrap CSS file is obtained from a CDN, e.g. CloudFlare.

You could use an automated hash-generation tool to generate the SRI (Subresource Integrity) hash values, but you would have to manually copy the value into your code. You can try out the relatively-new LibMan (aka Library Manager) for easily adding and updating your client-side libraries.

LibMan (aka Library Manager)

The easiest way to use LibMan is to use the built-in features available in Visual Studio. Using LibMan using the IDE is as easy as launching it from Solution Explorer. Specify the provider from the library you want, and any specific files you want from that library.

In the popup that appears, select/enter the following:

  • Provider: choose from cdnjs, filesystem, unpkg
  • Library search term, e.g. @aspnet/signalr@1… pick latest stable if desired
  • Files: At a minimum, choose specific files, e.g. signalr.js and/or its minified equivalent

 

For more on LibMan (using VS or CLI), check out the official docs:

Use LibMan with ASP.NET Core in Visual Studio: https://docs.microsoft.com/en-us/aspnet/core/client-side/libman/libman-vs

Use the LibMan command-line interface (CLI): https://docs.microsoft.com/en-us/aspnet/core/client-side/libman/libman-cli

Library Manager: Client-side content manager for web apps: https://devblogs.microsoft.com/aspnet/library-manager-client-side-content-manager-for-web-apps/

In any case, using LibMan will auto-populate a “libman.json” manifest file, which you can also inspect and edit manually.

{
  "version": "1.0",
  "defaultProvider": "unpkg",
  "libraries": [
    {
      "library": "@aspnet/signalr@1.1.0",
      "destination": "wwwroot/lib/signalr/",
      "files": [
        "dist/browser/signalr.js",
        "dist/browser/signalr.min.js"
      ]
    }
  ]
}

What About NPM or WebPack?

If you’ve gotten this far, you may be wondering: “hey, what about NPM or WebPack?”

It’s good to be aware that LibMan is a not a replacement for your existing package management systems. In fact, the Single-Page Application templates in Visual Studio (for Angular and React) currently use npm and WebPack. LibMan simply provides a lightweight mechanism to include client-side libraries from external location.

 



European ASP.NET Core Hosting :: Smart Logging Middleware for ASP.NET Core

clock March 13, 2019 09:44 by author Scott

ASP.NET Core comes with request logging built-in. This is great for getting an app up-and-running, but the events are not as descriptive or efficient as hand-crafted request logging can be. Here is a typical trace from a single GET request to /about:



If the request fails because of an error, you'll see instead:



While these fine-grained events are sometimes useful, they take up storage space and bandwidth, and add noise to the log.

Spreading the information across many events also makes it harder to perform some analyses, for example, the HTTP method and elapsed time are on different events, making it hard to separate the timings of GET and POST requests to the same RequestPath.

In production we want:

One "infrastructure" event per normal request, with basic HTTP information attached

Extra information to help with debugging if a request fails due to a server-side (5xx) error

The same format and event type for all requests, so that logs from both successful and failed requests can be easily grouped, sorted and analyzed together

Here's the format we're aiming for, expanded so that you can see all of the attached properties:

Instead of five infrastructure events + one application event, just a single infrastructure event is logged. This makes the application's own "Hello" event much easier to spot.

This post includes the full source code for the middleware, so you can take it and modify it to include the information you find most useful.

Step 1: Install and Configure Serilog

ASP.NET Core includes some basic logging providers, but to get the most out of it you'll need to plug in a full logging framework like Serilog. If you haven't done that already, these instructions should have you up and running quickly.

Step 2: Turn off Information events from Microsoft and System

Where Serilog is configured, add level overrides for the Microsoft and System namespaces:

Log.Logger = new LoggerConfiguration() 
    .MinimumLevel.Override("Microsoft", LogEventLevel.Warning)
    .MinimumLevel.Override("System", LogEventLevel.Warning)
    // Other logger configuration

These can be turned back on for debugging when they're needed.

If you're using appsettings.json configuration, check out the level overrides example in the README.

Step 3: Add the SerilogMiddleware class

The SerilogMiddleware class hooks into the request processing pipeline to collect information about the requests:

using Microsoft.AspNetCore.Http; 
using Serilog; 
using Serilog.Events; 
using System; 
using System.Collections.Generic; 
using System.Diagnostics; 
using System.Linq; 
using System.Threading.Tasks;

namespace Datalust.SerilogMiddlewareExample.Diagnostics 
{
    class SerilogMiddleware
    {
        const string MessageTemplate =
            "HTTP {RequestMethod} {RequestPath} responded {StatusCode} in {Elapsed:0.0000} ms";

        static readonly ILogger Log = Serilog.Log.ForContext<SerilogMiddleware>();

        readonly RequestDelegate _next;

        public SerilogMiddleware(RequestDelegate next)
        {
            if (next == null) throw new ArgumentNullException(nameof(next));
            _next = next;
        }

        public async Task Invoke(HttpContext httpContext)
        {
            if (httpContext == null) throw new ArgumentNullException(nameof(httpContext));

            var sw = Stopwatch.StartNew();
            try
            {
                await _next(httpContext);
                sw.Stop();

                var statusCode = httpContext.Response?.StatusCode;
                var level = statusCode > 499 ? LogEventLevel.Error : LogEventLevel.Information;

                var log = level == LogEventLevel.Error ? LogForErrorContext(httpContext) : Log;
                log.Write(level, MessageTemplate, httpContext.Request.Method, httpContext.Request.Path, statusCode, sw.Elapsed.TotalMilliseconds);
            }
            // Never caught, because `LogException()` returns false.
            catch (Exception ex) when (LogException(httpContext, sw, ex)) { }
        }

        static bool LogException(HttpContext httpContext, Stopwatch sw, Exception ex)
        {
            sw.Stop();

            LogForErrorContext(httpContext)
                .Error(ex, MessageTemplate, httpContext.Request.Method, httpContext.Request.Path, 500, sw.Elapsed.TotalMilliseconds);

            return false;
        }

        static ILogger LogForErrorContext(HttpContext httpContext)
        {
            var request = httpContext.Request;

            var result = Log
                .ForContext("RequestHeaders", request.Headers.ToDictionary(h => h.Key, h => h.Value.ToString()), destructureObjects: true)
                .ForContext("RequestHost", request.Host)
                .ForContext("RequestProtocol", request.Protocol);

            if (request.HasFormContentType)
                result = result.ForContext("RequestForm", request.Form.ToDictionary(v => v.Key, v => v.Value.ToString()));

            return result;
        }
    }
}

I've deliberately kept this to a single (somewhat ugly!) source file so that it's easy to copy, paste and modify.

There are a lot of design details and trade-offs involved. You can see that when a request is deemed to have failed, some additional information is attached, including the headers sent by the client, and the form data if any.

Step 4: Add the middleware to the pipeline

In your application's Startup.cs file, you can add the middleware either before or after the outermost exception handling components. If you add it before this, you won't get the full Exception information in any error events, but you will always be able to record the exact status code returned to the client. Adding the middleware into the pipeline inside the exception handling components (i.e., after them in the source code) will provide all exception detail but has to assume that the status code is 500 in this case.

public void Configure(IApplicationBuilder app, IHostingEnvironment env, 
                      ILoggerFactory loggerFactory)
{
    loggerFactory.AddSerilog();

    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
        app.UseBrowserLink();
    }
    else
    {
        app.UseExceptionHandler("/Home/Error");
    }

    app.UseMiddleware<SerilogMiddleware>();

    app.UseStaticFiles();

    app.UseMvc(routes =>
    {
        routes.MapRoute(
            name: "default",
            template: "{controller=Home}/{action=Index}/{id?}");
    });
}

Step 5: Profit!

Now you have a stream of request log events each with paths, status codes, timings, and exceptions:

We've seen how a simple customized logging strategy can not only produce cleaner events, but also reduce the volume of infrastructure log events.



About HostForLIFE.eu

HostForLIFE.eu is European Windows Hosting Provider which focuses on Windows Platform only. We deliver on-demand hosting solutions including Shared hosting, Reseller Hosting, Cloud Hosting, Dedicated Servers, and IT as a Service for companies of all sizes.

We have offered the latest Windows 2016 Hosting, ASP.NET Core 2.2.1 Hosting, ASP.NET MVC 6 Hosting and SQL 2017 Hosting.


Tag cloud

Sign in