How to Integrate Code with Code Snippets in Visual Studio

As I've noted in an earlier post, I don't use code snippets much (i.e. “at all”). One of the reasons that I don't is that I often have existing code that I want to integrate with whatever I'm getting from the code snippets library.

Some code snippets will integrate with existing code. If I first select some code before adding a code snippet, there are some snippets that will wrap that selected code in a useful way. For example, I might have code like this:

Customer cust;
        cust = CustRepo.GetCustomerById("A123");

I could then select the second line of the code and pick the if code snippet. After adding my code snippet, I'd end up with:

if (true)
        {
          cust = CustRepo.GetCustomerById(custId);
        }

That true in the if statement will already be selected, so I can just start typing to enter my test. That might mean ending up with this code:

if (custId != null)
        {
          cust = CustRepo.GetCustomerById(custId);
        }

You have to be careful with this, though -- most snippets aren't so obliging. If you do this with the switch code snippet, for example, it will wipe out your code rather than wrap it. Maybe I should go back to that previous tip on code snippets -- it discussed how to customize existing snippets (hint: you specify where the currently selected text is to go in your snippet with ${ TM_SELECTED_TEXT}).

Posted by Peter Vogel on 10/21/2019 at 12:06 PM0 comments


Calling .NET Methods With and Without Async

Let's say that you have an asynchronous method -- a method that looks something like this one that returns a Customer object wrapped inside a Task object:

public async Task<Customer> GetCustomerById(string custId) {

You can call this method with or without the await keyword. The syntax with the await keyword looks like this:

Customer cust = await GetCustomerById("A123");

Using the await keyword launches the method (and any code that follows it in the calling method) on a separate thread. When the method finishes running, the Customer object is pulled from the Task object and, in this case, stuffed into the cust variable.

The syntax without the await keyword looks like this:

Task<Customer> cust = GetCustomerById("A123");

With this syntax, you get back the Task object that manages the GetCustomerById method ... and that's it. You can now treat this cust variable as you would any other object: pass it to other methods, return it from the method with this code, store it in a global variable, and so on. When you're ready to run the Task in the cust variable, you can do asynchronously by calling the cust variable's Start method.

This code will start the GetCustomerById method running but go right on to the next line of code following the Start method:

cust.Start();

Alternatively, you can retrieve the Customer object returned by the method synchronously by reading the cust variable's Result property.

This code will cause processing to stop dead on this line of code until the GetCustomerById method managed by the Task object returns a Customer object:

Customer custResult = cust.Result;

There's more that you can with a Task object than just call the Start method and read the Result property (in fact, you'll probably use them together). But my point is that it's worth remembering that if you want the Task object associated with your async method, you can have it.

Posted by Peter Vogel on 10/17/2019 at 1:15 PM0 comments


Upgrading to ASP.NET Core Version 3.0: Top Tips

So you got excited about ASP.NET Core and started building an application in ASP.NET Core 2.0, 2.1, or 2.2. Now you're wondering how much work is involved in migrating that application to Version 3.0 which came out in late September.

If you've got a vanilla application the answer is ... it's not that painful. For example, to upgrade to Version 3.0, you just need to go into your csproj file and strip out almost everything to leave this:

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

And I do mean "almost everything." For example, any Package Reference elements that you have that reference Microsoft.AspNetCore packages can probably be deleted.

In ConfigureServices, you'll replace AddMvc with one or more of these method calls, depending on what technologies your application uses:

  • AddRazorPages: If you're using Razor Pages
  • AddControllers: If you're using Web services but not Views
  • AddControllersWithView: If you're using Controllers and Views. This also supports Web services so don't use it with AddControllers

In the Startup.cs file's Configure method, you'll change the IHostingEvnvironment parameter to IWebHostingEnvironment. Inside the method, you'll replace your call to UseMvc with:

  • UseAuthorization and UseAuthorization: Assuming that you're using authentication, of course
  • UseCors: If you want to support Cross-Origin Requests
  • UseEndPoints

With UseMvc gone, you'll need to move any routes you specified in that method into UseEndPoints. That will look something like this:

app.UseEndpoints(endpoints =>
    {
      endpoints.MapControllerRoute("default", "{controller=Home}/{action=Index}/{id?}");
    });

Those changes are all pretty benign because they all happen in one file. The other big change you'll probably have to make (especially if you've created a Web service) is more annoying: NewtonSoft.Json is no longer part of the base package. If you've been using NewtonSoft's JSON functionality, you can (if you're lucky) just switch to the System.Text.Json namespace. If you're unlucky, you'll have some code to track down and rewrite throughout your application.

Sorry about that.

There's more, of course, and there's a full guide from Microsoft. If you've got a relatively straightforward site, though, these changes may be all you need to do.

Posted by Peter Vogel on 10/14/2019 at 2:48 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 10/10/2019 at 10:33 AM0 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/17/2019 at 8:57 AM0 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/16/2019 at 11:04 AM0 comments


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


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


.NET Insight

Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.

Upcoming Events