You're Using HttpClient Wrong

There's a very good chance that, every time you need to access a Web Service, you've been creating an HttpClient object and then throwing it away. Unfortunately, that's bad for your application because you can run out of WebSockets (yes, even if you call the object's Dispose method before discarding it). Though, I have to admit, you'll only have this problem if you use the HttpClient a lot. Still, it's a bad idea to keep creating and destroying it.

In the .NET Framework, the intent was for you to create the HttpClient once in your application and use it over and over. To do that you'll have to declare your HttpClient object as a global or static variable. That creates its own problems, of course.

In ASP.NET Core, however, you have a better option: the HttpClientFactory. The HttpClientFactory provides you with HttpClient objects but takes responsibility for managing the resources that the clients can use up. Think of it as "connection pooling for Web Services."

The first step in implementing this tactic is to create an HttpClientFactory object in your project's Startup class in the ConfigureServices method and add it to your application's services collection. All you need is this code (and, yes, I realize that the method's name doesn't do a good job of reflecting what it does):

services.AddHttpClient();

Then, in the constructor for any controller that needs an HttpClient, you can ask for the factory by its interface (IHttpClientFactory). This following example grabs the HttpClientFactory out of the services collection and stuffs it into a field to be used by the methods in the controller:

public class TodoListController: Controller
{
  public TodoListController(IHttpClientFactory factory, ... )
 {
  this.factory = factory;

Now, whenever you need an HttpClient object, you just get it from the factory's Create method, like this:

HttpClient hc = factory.CreateClient();

Posted by Peter Vogel on 09/12/2019 at 12:27 PM0 comments


How to Create New Code Snippets from Existing Ones in Visual Studio

I'm not a big user of code snippets, but I know developers who are. I've noticed those developers often don't use the default value supplied for the variable part of the snippet (What! All your connection strings aren't in a variable named "conn"?). If you're one of those people or you'd just be happier with a couple more variations on the code snippets that come with Visual Studio, here's how to make that happen.

The first step is to open the Code Snippets Manager (it's on the Tools menu). The next step -- and the hardest part -- is finding the code snippet you want to change. Once you find that snippet in the manager, click on it and then look at the top of the dialog. There's a Location textbox there and in it you'll see the file path to the file that holds the code snippet. Copy that file path (sadly, Ctrl_A won't work but clicking at the start of the path and using Shift_End will).

Once you've copied the path, close the Code Snippets Manager and, from the File menu, select Open > File. Paste the file path you copied into the File Name textbox and hit the <Enter> key. You'll be looking at your code snippet in a Visual Studio editor tab.

Before you make any changes, from the File Menu select the Save ... As menu choice. It's hard to see that choice because the file name -- which is very long -- is inserted into the middle of the menu choice name. If it's any help, the Save ... As choice is the second of the two choices that begin with "Save." Once you've found it, save your file under a new name. Now, if you render the snippet inoperable, you'll still have the original to fall back on and can try again.

You will, of course, want to change the code in the snippet (otherwise why are you reading this?). But make sure that you also change two things in the XML headers at the top of the file. First, change the shortcut to (a) something you'll remember to type when you want this snippet, and (b) something that no other snippet is using. Second, change the snippet's title element to something you'll recognize in the Code Snippet Manager. If you're a decent human being, you'll also change the author tag to your name.

Posted by Peter Vogel on 09/01/2019 at 6:32 PM0 comments


How to Efficiently Validate Against Cross-Site Request Forgery Attacks in ASP.NET Core

If you're worried about CSRF (Cross-Site Request Forgery) attacks (and you probably should be), then you've already added the code to your Views that adds an anti-forgery token to the data that the browser sends back to the server. If you're using HTML Helpers, that code looks like this:

@Html.AntiForgeryToken()

If you're working in ASP.NET Core and have enabled Tag Helpers, then you don't even need to use that code -- the <form> element has a tag helper associated with it that adds the field automatically.

The issue is that, in your HttpPost methods, you need to check that you get that token back. That is easy to do in both ASP.NET MVC and ASP.NET Core: You just add the ValidateAntiForgeryToken attribute to your methods. There was always, of course, the danger that you'd miss adding it to one of your HttpPost methods, which would be ... unfortunate. It would be easier just to add the attribute to your controller class. The problem with that solution is that you'd be incurring the cost of checking for the token with every request, not just with the HttpPost methods.

If this worries you (and you're using ASP.NET Core), then you can add the AutoAntiForgeryToken to your controller classes, like this:

[AutoAntiForgeryToken]
public class TodoListController: Controller
{

This attribute checks only the dangerous methods (that is, only methods that aren't a GET or one of the other methods you never use: TRACE, OPTIONS and HEAD). You'll get all the protection you need and none that you don't.

Posted by Peter Vogel on 09/01/2019 at 6:32 PM0 comments


How to Handle Multiple HttpClients in the Same ASP.NET Core Application

It's not impossible that you're accessing several different methods from the same Web Service in your application. If so, and if you're using the HttpClientFactory (and you should be), you have an opportunity to centralize some of your code.

In your Startup class, you should be calling the AddHttpClient method, which, despite its name, actually adds an HttpClientFactory to your application's services collection. As part of that method, you can pass the AddHttpClient method a string and a lambda expression. In the lambda expression you can provide the code to configure the HttpClient objects created by the factory. When it comes time to create an HttpClient object, you can use the string you provided to get the configuration you specified.

This code, for example, passes the AddHttpClient method the name "phvis" and specifies how the BaseAddress on the HttpClient should be set when this factory is used:

services.AddHttpClient("phvis", hc =>
{
    hc.BaseAddress = new Uri("https://phvis.com/");
});

Now, when you go to create an HttpClient, you can use "phvis" to get a client that's configured for my site. As an example, this code retrieves an HttpClient configured for phvis.com (see my earlier tip on how to retrieve the factory from the services collection so that you can use it here):

var client = factory.CreateClient("phvis");

Because the client has its BaseAddress property already set, you only have to specify the back part of the service's URL when making a request. This example joins a relative URL passed to the GetAsync method with my earlier BaseAddress to send a request to https://phvis.com/Customer/A123:

var response = await Client.GetAsync("/Customer/A123");

And, if you're accessing multiple Web Services, there's nothing stopping you from setting up multiple named clients, each with their BaseAddress set for the various services you're using.

Posted by Peter Vogel on 09/01/2019 at 6:32 PM0 comments


Logging vs. Reporting Exceptions in Visual Studio

In an earlier tip I disagreed with one of Microsoft's recommendations for handling exceptions. I figure I'm on a roll, so here's another objection to some Microsoft advice on handling errors.

In Microsoft's reference documentation for the Exception object's ToString method, Microsoft recommends using Exception object's ToString method to report errors. The Remarks section of the documentation says that the exception's ToString method "returns a representation of the current exception that is intended to be understood by humans."

That's true if, I guess, by "humans," you actually mean "developers."

Let me make my point. Here's what you'll find in the DivideByZeroException object's Message property:

Attempted to divide by zero.

Here's what's returned by the ToString method:

System.DivideByZeroException: Attempted to divide by zero. at CustomerManagement.CreditManagement.CreditManagement_Load(Object sender, EventArgs e) in C:\\Users\\peter\\Source\\Repos\\Customers\\CustomerManagement\\CreditManagement.cs:line 30

Don't get me wrong: I think that the output of the ToString method is a great thing to put into your application's log file. I also think that inflicting that on a defenseless user is just mean. I think what's in the Message property is what you should give to the user.

Having said all that, however, I'm not suggesting you ignore Microsoft's advice on the Exception object's ToString method. The Remarks also say "The default implementation of ToString obtains the name of the class that threw the current exception, the message, the result of calling ToString on the inner exception, and the result of calling Environment.StackTrace." Precisely because it does make a good log file entry, I think you should be making sure that's what the ToString method does when you create your own custom exception object.

Posted by Peter Vogel on 06/03/2019 at 8:32 AM0 comments


Making Views Serve Two Roles in ASP.NET Core

I hate creating two or more Views that share a lot of HTML because it doubles my maintenance burden by forcing me to keep the two Views in sync. The usual reason I'm doing this is because I have single page that's supporting two user roles and I need to suppress or include some HTML based on the current user's authorization level.

While I try to avoid adding code to a View because I can't automate testing that code, I've been known to put code in Views to conditionally generate HTML to support multiple roles in a single View. The logic is usually pretty simple (a call to some IsInRole method), but it's mixed in and scattered through the HTML that makes up the View.

ASP.NET Core gives me a new tool to use that allows me to tailor a single View for multiple purposes while centralizing my code: The IgnoreSection method. The IgnoreSection method, in a View, allows me to tell the layout View to not pick up a specific section.

For example, I can now put all my command buttons in a section of my View, like this:

@section UpdateButtons { <input type="submit" value="Update" name="Update"/> }

Presumably, the layout View used by this View would incorporate the section into the page with a line like this:

@RenderSection("UpdateButtons", false)

But I want this View to be used both by guests (who aren't allowed to update data) and employees (who are). In ASP.NET Core, I can now suppress the section from being displayed by the layout View by passing the name of the section to the IgnoreSection method.

For example, this code in my View ensures that the UpdateButtons section won't be sent to the user if the user is in the "guest" role:

@if (User.IsInRole("guest")) {
  @IgnoreSection("UpdateButtons")
}

What I like about this is that I can put this logic in the code block at the top of my View instead of scattering it throughout my View. I can also now control what each user sees just by moving HTML in and out of the appropriate sections or by adding and removing sections in my if statement.

There's also a new IgnoreBody method that suppresses a layout View's RenderBody method, but I'm not clear when I'd want to use that. You may have a better imagination than I do, of course.

Posted by Peter Vogel on 05/31/2019 at 8:43 AM0 comments


How to Use Regular Expressions in Visual Studio Find

I have to admit that I've never really understood regular expressions. But if there was any reason that I was going to learn to use them, it would be when doing searches in Visual Studio.

For one thing, regular expressions are easy to invoke when doing a search: When you press Ctrl_F to get the Find dialog box, all you have to do is click the asterisk (*) to the left of the of scope dropdown list to start using regular expressions in your search.

I think, for example, I'm ready to start using the period (which matches a single character) in my searches. That would let me (for example) search for any string that begins with a and ends with p that has only one character in between (a.p). I not only understand this, but it's also easy to extend: Looking for a and p with two characters in between is a..p.

Where I could see being even more successful is by using Replace in Files more. When you open Replace in Files there's a Use Regular Expressions option tucked in under Find Options. Checking off that option enables the button at the end of the "Find what" text box. I like that button because clicking on it produces a quick study guide for regular expression newbies like me. I could do this.

I mean: it's certainly possible that I could learn something new. Unlikely, but possible.

Posted by Peter Vogel on 05/30/2019 at 11:02 AM0 comments


How to Build .NET Strings at Run Time

You want to put together an error message that includes information from the Customer object that caused the problem. Since you're not repeatedly modifying a single string variable, using StringBuilder would be overkill. You still have three options.

Your first option is the most obvious: Concatenation. Here's some code that assembles a message from constant string and some values:

string msg = "Customer " + cust.Id + " has an invalid status " + cust.Status;

Your second option is to use the string class's Format method. You're probably used to seeing this syntax because there are lots of functions that use string.Format under the hood to build strings. With the Format method, you provide your constant string as your first parameter. Inside that string you put place holders (marked with curly braces: { }) where the variable data is to be inserted. The Format method will insert the values from the following parameters into the place holders.

Here's my message with the Format method:

string msg = string.Format("Customer {0} has an invalid status {1}.", cust.Id, cust.Status);

Your third option is string interpolation. This is the newest mechanism and is what all the "hip and happening" developers use. It looks much like using the Format method, but the placeholders now hold the values to be inserted into the string. You need to flag the string with a dollar sign ($) to tell C# that the curly braces are to be treated as placeholders rather than included in the string:

string msg = $"Customer {cust.Id} has an invalid status {cust.Status}.";

Posted by Peter Vogel on 05/29/2019 at 12:54 PM0 comments


Skip the 'Do You Want to Run the Last Successful Build?' Question when Debugging in Visual Studio

When I pressed F5 to start debugging and Visual Studio found a compile-time error, nothing irritated me more than the dialog box Visual Studio popped up that asked, "There were build errors. Would you like to continue and run the last successful build?"

Let me be clear: No, I didn't want to run "the last successful build." I never wanted to run "the last successful build." Who in the world would want to run "the last successful build?" Like any other rational human being in the world, I wanted to run the version of the code with the changes I had just finished making ... well, after I fixed the compile errors, I mean.

So I turned that idiot message off.

If you also want to get rid of that message, then go to Tools | Options | Projects and Solutions | Build and Run. In the right-hand panel under "On Run, when build or deployment errors occur," change the selected item in the dropdown list to Do Not Launch. Now, when you have build errors, Visual Studio will just sit there. You'll have to get into the habit of checking your Error List to find out why you're not in debug mode but, for me, that didn't take me very long.

Posted by Peter Vogel on 05/08/2019 at 12:01 PM0 comments


Reporting Exceptions Well in Visual Studio

Microsoft has some "best practice" advice to share on how to handle exceptions (a topic I've discussed elsewhere). The Microsoft article is well worth reading ... but there's one piece of advice that I disagree with (talk about hubris, eh?).

One of Microsoft's recommended practices is that you should prefer to throw a built-in Exception class rather than your own, custom Exception class. The problem I see with this is that the built-in Exception objects return, at best, the technical reason for the exception (for example, "Division by zero"). Creating your own exception object allows you to specify the business reason for the failure (for example, "Customer has no sales orders").

Personally, I think that the message with the business reason is more useful both to the user faced with the message and the developer who has to fix the problem. Instead, I recommend using a custom exception object and tucking the original Exception into your custom Exception object's InnerException property. That gives you the best of both worlds.

Posted by Peter Vogel on 04/26/2019 at 3:51 PM0 comments


Pulling Objects from Web Services with ReadAsAsync

In an earlier post, I discussed the three objects that Microsoft has provided for calling Web Services: HttpWebRequest, WebClient and HttpClient. At the time, I suggested WebClient was the simplest solution, unless you wanted to take advantage of HttpClient's asynchronous processing.

I've reconsidered that choice since then and I'm currently using HttpClient almost exclusively. Part of the reason is that HttpClient gives me the ReadAsAsync method. To understand why I like that method so much, you have to compare it to the alternatives.

Here's how to get a list of Customer objects out of the response from a Web Service using the traditional ReadAsStringAsync method:

HttpClient hc = new HttpClient();
HttpResponseMessage customersRm = await hc.GetAsync(url);
string customersString = await customersRm.Content.ReadAsStringAsync();
List<Customer> custs = JsonConvert.DeserializeObject<List<Customer>>(customersString);

Now here's the code using ReadAsAsync (even the method name is shorter!):

HttpClient hc = new HttpClient();
HttpResponseMessage customersRm = await hc.GetAsync(url);
List<Customer> custs = await customersRm.Content.ReadAsAsync<List<Customer>>();

The only problem is that you don't, in .NET 4.5 or later, get ReadAsAsync without some work -- you'll have to add the Microsoft.AspNet.WebApi.Client NuGet package to your project to pick up this extension method. I think that's worth doing.

Posted by Peter Vogel on 04/25/2019 at 8:58 AM0 comments


Finding Layout Views in ASP.NET Core

The biggest change in handling Views in ASP.NET Core is that you can now have more than one _Layout.cshtml file in your project and your Views will pick the one "closest to them." In ASP.NET MVC, you set a View's Layout property to the full path name of the Layout file to be used, like this:

@{
  Layout = "~/Views/Shared/_Layout.cshtml";
}

In ASP.NET Core, you can set the Layout property to as little as the name of the file. This, for example, is perfectly OK:

@{
  Layout = "_Layout";
}

When you don't provide a path name to your layout View, ASP.NET Core first goes looking for the layout in the same folder as the View that requested it. Only when ASP.NET Core doesn't find a file with the right name "locally" does ASP.NET Core go on to the /Shared folder to find a "global" layout View.

This means that you can set the Layout property in your _ViewStart.cshtml file to a default value "_Layout" but have Views in different folders pick up different layouts. This can mean a lot fewer Views having to override that default setting for the Layout property: If all the Views for a Controller share a layout View, you can just put that layout View in the Views folder for that Controller's Views.

Posted by Peter Vogel on 04/04/2019 at 9:39 AM0 comments


.NET Insight

Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.

Upcoming Events