A standard practice to create repository should always be;
Main branch should always have a .gitignore and readme file.
Create a working branch from main
Develop feature in your working branch
Before committing, do a merge from remote main to working branch and resolve any conflicts in working branch. This will help you to get team changes merged into your working branch.
Commit your changes. Create a PR and you are done.
Recently I came across an issue where existing projects were showing .vs folder checked-in and being tracked. Developers were having code conflict problems and were not able to create PR request.
Here is the work around to add gitignore file in existing solution using Visual Studio.
Remove .vs folder from main branch and working branch. If there are PR policy in place, disable that for fixing this. After .vs folder removal, enable PR policy.
Open Visual Studio and make sure it’s connected to Git branch. Click on Git->Settings.
This will add gitignore file in the root of project folder. Switch to Git changes window in your working branch and commit / sync your changes.
Now we need to stop tracking all .vs folder changes that’s been created on developer machines to build and run the project. Use these magic commands, one time only;
For added piece of mind, sync your main branch and do a merge from main branch to work branch locally. Resolve any cache files and conflicts. You might need to run above three command again.
After this, Create PR and it should merge with main branch. This will take your pain away.
If there are two endpoint with same route, .NET Core Web API will throw request matched multiple endpoints error. Here is an example;
// api/menus/{menuId}/menuitems
[HttpGet("{menuId}/menuitems")]
public IActionResult GetAllMenuItemsByMenuId(int menuId)
{
....
}
// api/menus/{menuId}/menuitems?userId={userId}
[HttpGet("{menuId}/menuitems")]
public IActionResult GetMenuItemsByMenuAndUser(int menuId, int userId)
{
...
}
This is impossible because the actions are dynamically activated. The request data (such as a query string) cannot be bound until the framework knows the action signature. It can’t know the action signature until it follows the route. Therefore, we can’t make routing dependent on things the framework doesn’t even know yet.
Long and short, we need to differentiate the routes in some way: either some other static path or making the userId a route param. However, we don’t actually need separate actions here. All action params are optional by default. Therefore, we can just have:
[HttpGet("{menuId}/menuitems")]
public IActionResult GetMenuItemsByMenu(int menuId, int userId)
And then we can branch on whether userId == 0 (the default). That should be fine here, because there will never be a user with an id of 0, but we may also consider making the param nullable and then branching on userId.HasValue instead, which is a bit more explicit.
We can also continue to keep the logic separate, if we prefer, by utilizing private methods. For example:
// Register swagger generator, you can define multiple documents here
services.AddSwaggerGen(s =>
{
s.SwaggerDoc("v1", new OpenApiInfo
{
Title = "FOO API",
Version = "v1"
});
var xmlFile = $"{typeof(Presentation.AssemblyReference).Assembly.GetName().Name}.xml";
var xmlPath = Path.Combine(AppContext.BaseDirectory, xmlFile);
s.IncludeXmlComments(xmlPath);
});
Edit project .csproj file and add / change these nodes:
<PropertyGroup>
<!--
Make sure documentation XML is also included when publishing (not only when testing)
see https://github.com/Azure/service-fabric-issues/issues/190
-->
<GenerateDocumentationFile>true</GenerateDocumentationFile>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
<DocumentationFile>bin\$(Configuration)\$(AssemblyName).xml</DocumentationFile>
</PropertyGroup>
This also works with .NET Core 3.1. more info can be found here.
So version 16.17.0 is the LTS version. Download and use this version using nvm;
> nvm install 16.17.0
> nvm use 16.17.0
I tried to use ng –version command on my computer but it didn’t work. I needed to re-run this command for angular cli installation;
> npm install -g @angular/cli@13.0.1
restart your computer and run this command again to check Angular CLI version;
> ng --version
This time installation is successful with this message;
Path Variables
If nvm doesn’t work, add it to the environment variable. Press win+I on windows 11. Under About -> “Device specifications” box, click on “Advanced system settings” and select environment variables.
Add nvm.exe to “User variables for admin” section. Here are the values;
Restart your computer. Open command window and run following command any where;
If all commands run successfully, We are ready to rock-n-roll with Angular 13 and .NET 6.
Creating test project using Visual Studio 2022
Microsoft has a template, ASP.NET Core with Angular, to create .NET core project with Angular. It’s a single project template with front-end and back-end project. We will not be using this template for our test project. We will create two projects, front-end and back-end and connect those projects.
Create front-end project, e.g. Foo, using “Standalone Typescript Angular Project” template. Create back-end web API project, e.g. FooAPI, within same solution. Double click on launchsettings.json file and change ports to 5001 for https and 5000 for http.
On front-end project, under /src/proxy.conf.js, make sure the port is configured to be 5001. This is the port kestrel web server is listening for incoming requests.
Angular development port configuration are in /.vscode/launch.json file. If you don’t see it, it might be hidden. Usually it’s mapped to HTTPS on port 4200.
Last step is to setup startup project for this multi-project solution. Right click on solution and click on “Set startup project”. Change startup project from “single startup project” to “multiple startup projects” and select “start” for each project. Move FooAPI project on top so it can start first.
Do a quick test run of these multi-projects in Debug mode by pressing F5. Visual Studio will launch 3 process;
ASP.NET Core Server (Kestral or IIS Express)
Angular Live Development Server (using “ng serve” command from the Angular CLI)
Web Server (Google or Edge)
We will be seeing this basic page;
Angular component performing a simple data fetching task from ASP.NET Core Web API project. A small but good working example without any boilerplate code / extra fluff.
A sample diagram how these 3 process interact with each other;
All components are working as expected.
Update Angular Version
To update angular version within project workspace, run this;
ng update @angular/core@17 @angular/cli@17
Angular version information is located in package.json. To see which application is targeting which Angular project, refer to package.json file.
