Prasanna Kumar Raparthi

Yes, I'm Krishna Kumar. I have six years of experience. I'm mostly into.NET. I have skills such as C#, ASP.NET, ASP.NET MVC.NET course, and Entity Framework. Along with that, I have UI experience with HTML and Angular. From the cloud perspective, I have experience with AWS and Azure. Yeah, that's all about myself.

In dotnetcore, instead of creating multiple objects one at a time, we can inject the dependency in the controller so that you don't have to create an outage object every time. The difference or the advantage that we get with that is we can have a different type of database connectors being injected instead of us using that and creating an object in different methods. For example, if you want to have Microsoft SQL as a database, then we can inject the SQL connectors inside the constructor. And if you want to have MySQL or Postgres, then we can use its respective database connectors and inject those in the dependencies or constructor. So that specific type of based on the constructor type, we can call respective methods and use the connection strings.

So, bootstrap is mainly used for UI elements, where we can style and have it in all we can also have dynamic styling applied via bootstrap. And there can be multiple advantages of using bootstrap by making use of exact or jQuery or any other JavaScript languages.

Yeah. So, I mean, CIC, there's nothing but the continuous integration and continuous deployment. So when we use dot net code as an application, we need to build an application into DLLs, and then we would be using that. So in our local, we can build that, and ID takes care of the running of the application. But when we want to deploy that or host that application in IIS, then we need to make sure it's built successfully and deploy successfully. So to do all this, we can make use of CICD. And the basic implementation of CICD is first, we would be creating a build pipeline wherein we can make sure the code quality is good by introducing SonarQube or any other tools during the build process. And once the build is successful, we would be getting the artifacts, and we can deploy that using the release pipelines or making use of continuous deployment features. So using Git, we can make use of the build, we can build a code and create the artifacts. And once we create the release pipeline, you can use either Azure or TeamCity, we can deploy that at specific respective locations so that it can be run. And coming to database schema changes, there can be multiple ways. It can be done via scripts and run, or make the execution of the scripts via database change log as a tool, or we can also do that via code if it is a model first approach in dot net. But mostly, if it is a script-based changes or database first changes, then we can go with database change log as a tool to deploy the schema changes.

In.NET Core, we can handle exceptions via using try catch blocks. And in order to not expose the sensitive information, we can override certain exceptions and use our own specific exceptions and through a common exception message or minimize the system information and show a generic exception. That can be done by using the interface and writing custom exceptions, and that can handle sensitive database information to not be exposed. And we can also use a generic exception, and instead of throwing the entire stack trace, by throwing the sensitive information to the end user, we can just show a common exception message or generic exception.

So, when we're migrating from a.NET application to.NET Core, the major challenge would be that the legacy code might be in.NET with BizTalk, or if it's in C#, then it can be Entity Framework. In Entity Framework, it would have a web.config and Program.cs files, where all the settings would reside in the web.config, and the application would start from the app's App.xaml.cs file. However, to migrate into.NET Core, we would have to move the startup code into the Program.cs file, or we can make use of separate files to start up and call those files via Program.cs. Because in.NET Core, the starting point is from Program.cs. Data migration from MySQL to Microsoft SQL involves a couple of tools where we can migrate from one database tool to another database tool. Alternatively, we can export the data from MySQL as a SQL file, and then import that into Microsoft SQL so that the schema would remain the same and the data would be imported successfully.

So in the SQL script, we are trying to fetch the name and the maximum salary from the employees, based on grouping the department, but it would throw an exception because we are trying to find a name after doing a group by. So in this case, when we are doing a group by department, we won't be having any names. Either we can correct it by displaying the department and the maximum salary as the maximum salary from employees group by department having count of stars greater than 5.

So, I mean, here we have a number list where there can be duplicates within the list, and then we have made the numbers distinct, and converted it into two lists. But we are not returning the distinct numbers. Instead, we are returning the same numbers, hence the bug. So we can actually return the distinct numbers, and that would actually return our distinct list of numbers.

I'm not sure about this signal and how it reacts.

So, when we are interacting with web BPA's, we have to make sure that CSP headers are present within the request. And also, for additional security, APIs that are being used by specific rules or specific users, we can add authorization to those APIs by using filters authorization filters. And, yeah, I think we can add that. We can also make sure that the APIs, when we pass the user credentials, the request that we get within the body is a valid user or coming from a valid user with a valid JWT token.

So, setting the DevOps workflow in a.NET Core project, we can at least from the AWS side, in AWS also, we have CICD. And then Azure also, we have Azure CICD tools. We can make use of them. First, it would be the same process. 1st, we would have to create a build pipeline, and then we will have to create a release pipeline. And within the build pipelines, we can add multiple tools like SonarLint, SonarQube, or any other tools which test the code and the build quality. And then we can have certain gates where when we want to have deployment or when we want to have a specific branch related bills, we can have those gates added. And once we create any PR, if we have to configure an automatic build or only after merge if we want to merge those changes, that also can be done via AWS or via Bitbucket. We can set up those gates so that the build would be executed only after it gets merged. And testing and deployment can be done at least by using the.NET test cases that we have, a unit or integration test. So that can be run within the build pipeline itself. And once those tests are run, we can make sure we can make the build as successful so that it can be deployed via the release pipelines.