Cross-platform ASP.NET Core Debugging with Visual Studio Code

CheapASPNETHostingReview.com | Best and cheap ASP.NET Core 2.0 hosting. It’s been a year since ASP.NET Core and Visual Studio Code became available and early adopters have endured CLI changes and RC changes. If you’ve held off getting into ASP.NET Core for these reasons you are probably now curious about the cross-platform capabilities of Visual Studio Code. It appears as if things are (mostly) stable before RTM for .NET Core and ASP.NET Core later this month. So, how hard is ASP.NET Core debugging in Visual Studio Code on both Windows and OS X? As it turns out, it is not that difficult. There are a few minor details involved, but I’ve written this post to show you how easy it is to get started. There are plenty of screenshots to document the process. You’ll need Visual Studio 2015. You’ll also need Visual Studio Code installed on both a Windows machine and a Mac to get started. I’m assuming you have a minimum amount of experience with Visual Studio Code.

Code sharing steps

Since we will be sharing the same code between platforms, set up a common location using your favorite source code control. I like to use Git and Bitbucket for this purpose.

Creating the solution from a template

To get up and running fast, I chose the Visual Studio 2015 template “ASP.NET Core Web Application (.NET Core)” because of the ease of use in creating a project. Yes, this seems like cheating, but at the moment there isn’t a comparable feature for Visual Studio Code. Yes, there are Yeoman generators for ASP.NET Core but I felt the basic template in Visual Studio 2015 was more accessible to a .NET developer and didn’t require installing Yeoman.

Step 1: Open Visual Studio 2015, add a new project type “ASP.NET Core Web Application (.NET Core)” and give the project a name.

Step 2: Select “Web Application” and choose the type of Authentication.

Authentication Choices:

No Authentication – this is the option we will be choosing for this post since we are focused on setting up debugging.
Individual User Accounts – this adds the ASP.NET Identity Framework and EntityFramework.

Using this cross-platform will be the subject of another post.

Work and School Accounts – this uses Windows Active Directory. We won’t be using it for this post. There is advice to be found online for adding your Mac to AD if you want to pursue this option.
Windows Authentication – This will not work for our cross-platform debugging.

The resulting folder structure as seen in Visual Studio 2015. We can now open the project folder under “src” in Visual Studio Code.

Setting up ASP.NET Core debugging in Visual Studio Code on Windows

If you haven’t installed the C# Debugger extension for Visual Studio Code, do that now. The extension and installation instructions can be found here.
In Visual Studio Code, open the project folder under “src” that contains the code. For the demo this folder is “Tag.AspNetCore”.
When you first open the folder, or the first time you try to debug, you will be prompted to add required assets.

Select Yes and a “.vscode” folder will be added with a tasks.json file. This is the “Task Runner” file. We will edit that in a few steps.

Now, Select the Start Debug button and you will notice the message that we have “No Configuration” and there is a red notification symbol on the Settings button.

Select the Settings button and you will be prompted to “select environment” – choose “.NET Core”.

This will create a launch.json file for you that contains the confugrations for debugging.

Edit the json file. It contains three configurations: “.NET Core Launch (console)”, “.NET Core Launch (web)”, and “.NET Core Attach”. We won’t need the console configuration so you can remove it if you wish. We do need to update the web configuration’s “program” entry to point at the .dll that will be built.

Note: If you forget to edit this and try to debug, you will receive the following error:

Once you change the program path and save this file, these configurations will be presented in a dropdown to the right of the “Start Debugging (F5) button”. Select “.NET Core Launch (web):

If you set breakpoints and try to debug again, you will find that your breakpoints will not be hit and you get the message:

To fix this we will need to update the project.json file to tell the build process to produce a .NET Core compatible output.

Edit the json file to add “debugType”: “portable” to “buildOptions”.

*Note: this step is one that may change by RTM as project.json will be going away and it’s features added to a csproj file. This is somewhat controversial. You can read up about that here.

After following those steps, you should be able to repeat step #3 above to start the debugger and the project will launch and open a window in your default browser. Now, we are debugging ASP.NET Core code in Visual Studio Code!

Upload your code to your source code control (GitHub, Bitbucket, etc.) where we will be able to access it for the next section.

Setting up ASP.NET Core debugging in Visual Studio Code on OS X

If you haven’t installed the C# Debugger extension for Visual Studio Code, do that now. The extension and installation instructions can be found here.
Download the code you placed in source code control in the last section into a repository location. Then, open the project folder under “src” in Visual Studio Code.
Select Debug View:

Make sure the configuration “.NET Core Launch (web)” is selected. Start a debugging session by pressing the Start Debug button:

At this point, the web page should launch for you successfully, and you can debug the project just like you can on Windows.

ADDING PACKAGES AS YOU DEVELOP: A DIFFERENT APPROACH WITH VISUAL STUDIO CODE

Visual Studio developers have become accustomed to the NuGet Package Manager interface and the Package Manager Console. That isn’t available in Visual Studio Code. Here is what you would have to do:

To add a new package, you will have to add the package name and version number in the pjson file.

*Note: this step is one that may change by RTM as project.json will be going away and it’s features added to a csproj file. This is somewhat controversial. You can read up about that here.

Use the dotnet CLI command “dotnet restore”.

Final thoughts

Overall, cross-platform ASP.NET Core debugging using Visual Studio Code works well. The only disappointment seems to be the lack of support for NuGet packages within Visual Studio Code. I would like to see the dotnet CLI support package installation.

My only question for the development community is; now that you know cross-platform development and ASP.NET Core debugging can be done, do you want to do it for an ASP.NET Core website? Or, does it seem that all this was made possible just to prove it could be done? Let me know in the comments.

How To Route Constraints In ASP.NET Core

CheapASPNETHostingReview.com | Best and cheap ASP.NET Core. Route Constraints can be a handy way to distinguish between similar route names, and in some cases, pre-filter out “junk” requests from actually hitting your actions and taking up resources. A route constraint can be as simple as enforcing that an ID that you expect in a URL is an integer, or as complicated as regex matching on strings.

An important thing to remember is that route constraints are not a way to “validate” input. Any server side validation you wish to occur should still happen regardless of any route constraints set up. Importantly, know that if a route constraint is not met than a 404 is returned, rather than a 400 bad request you would typically expect to see from a validation failure.

Type Constraints

Type constraints are a simple way to ensure that a parameter can be cast to a certain value type. Consider the following code :

[HttpGet("{id}")]
public string Get(int id)
{
	return "value";
}

[HttpGet("{id}")]

public string Get(int id)

{

return "value";

}

At first glance you might assume that if you called “/api/controller/abc” that the route would not match – It would make sense since the id parameter is an integer. But infact what happens is that the route is matched and the id is bound as 0. This is where route constraints come in. Consider the following :

[HttpGet("{id:int}")]
public string Get(int id)
{
	return "value";
}

[HttpGet("{id:int}")]

public string Get(int id)

{

return "value";

}

Now if the id in the URL is not able to be cast to an integer, the route is not matched.

You can do this type of constraints with int, float, decimal, double, long, guid, bool and datetime.

Size Constraints

There are two types of “size” constraints you can use in routes. The first is to do with strings and means you can set a minimum length, max length or even a range.

[HttpGet("{id:minlength(4)}")]
public string Get(string id)
{
	return "value";
}

[HttpGet("{id:minlength(4)}")]

public string Get(string id)

{

return "value";

}

This sets a minimum length for the string value. You can also use maxlength to limit the length.

Alternatively, you can set how many characters a string can be within a range using the length property.

[HttpGet("{id:length(2,4)}")]
public string Get(string id)
{
	return "value";
}

[HttpGet("{id:length(2,4)}")]

public string Get(string id)

{

return "value";

}

While that’s great for string variables, for integers you can use the min/max/range constraints in a similar fashion.

[HttpGet("{id:min(1000)}")]
public string Get(int id)
{
	return "value";
}

[HttpGet("{id:min(1000)}")]

public string Get(int id)

{

return "value";

}

Regex Constraints

Regex constraints are a great way to limit a string input. By now most should know exactly what regex is so there isn’t much point doing a deep dive on how to format your regex, just throw it in as a constraint and away it goes.

[HttpGet("{id:regex(\\d-\\d)}")]
public string Get(string id)
{
	return "value";
}

[HttpGet("{id:regex(\\d-\\d)}")]

public string Get(string id)

{

return "value";

}

It is worth noting there for whatever reason, the .NET core team added another handy “quick” way of doing alpha characters only instead of regex. There you can just use the constraint of “alpha”.

[HttpGet("{id:alpha}")]
public string Get(string id)
{
	return "value";
}

[HttpGet("{id:alpha}")]

public string Get(string id)

{

return "value";

}

How To Create Help Desk Web Application using ASP.NET Core

CheapASPNETHostingReview.com | Best and cheap ASP.NET Core hosting. Suppose you work for a small to midsize company that employs 50-100 workers. The Help Desk — a subsidiary of the Information Services Division — is in charge of trouble tickets regarding general PC issues such as email, viruses, network issues, etc. Initially, the Help Desk team stored this information in Excel spreadsheets, but as the company has grown, managing these spreadsheets has become tedious and time consuming.

The Help Desk has asked you to devise a more efficient solution that could be developed internally, saving the company money. As you start to think about it, the following requirements are apparent: fields for the submitter’s first and last name, as well as their email address. You’ll also need combo boxes for indicating ticket severity (low, medium, high), department, status (new, open, resolved), employee working on the issue, as well as an area for comments. Of all the solutions available, creating an internal help desk Web application with ASP.NET is relatively simple.

In the following article, we’ll see how to implement these features in an ASP.NET help desk Web application using a database-driven approach,
Creating the JavaScript File
Because creating the JavaScript file is the easiest of the work left, we’ll do this next. From the Solution Explorer, follow these steps:

Creating the Help Desk Class

Now that we have our data coming in, we need to be able to record a help desk ticket submission. We need to create an event handler in a class to handle it. Let’s first create a help desk class by doing the following:

Right click the project solution.
Choose Add>New Item.
In the Add New Item window, select Class.cs.
In the name text field, type “HelpDesk” and then click Add.

Double click HelpDesk.cs from the Solution Explorer, which will show the empty class as shown below:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
namespace HelpDesk
{
    public class HelpDesk
    {
    }
}

using System;

using System.Collections.Generic;

using System.Linq;

using System.Web;

namespace HelpDesk

{

public class HelpDesk

{

}

We need to import three libraries as shown below:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Data;
using System.Configuration;
using System.Data.SqlClient;
namespace HelpDesk
{
    public class HelpDesk
    {
    }
}

using System;

using System.Collections.Generic;

using System.Linq;

using System.Web;

using System.Data;

using System.Configuration;

using System.Data.SqlClient;

namespace HelpDesk

{

public class HelpDesk

{

}

The first library (System.Data) allows us to work with stored procedures in ADO.NET, the second (System.Configuration) allows us to reference a connection key from configuration file and the last (System.Data.SqlClient) one allows us to connect to SQL Server.