Bharat Gupta

In-Memory Caching in ASP.NET MVC Core

bharatgupta04 — Sun, 18 Dec 2016 22:30:05 GMT

Cache is one of the reliable ways to prevent to retrieve the Data from data source that does not change frequently. Caching keeps a copy of data in a location that can be accessed more quickly than the source data. ASP.NET Core has rich support for keeping data in memory on the local server, which is referred to as in memory caching.

Troubleshoot and debug web applications

Bharat Gupta — Sun, 27 Nov 2016 19:15:05 GMT

The developer who has never had to troubleshoot or debug an application is a rare person indeed. Even the best-planned projects can experience situations in which something does not work as expected. Troubleshooting and debugging an application is a normal process when creating or modifying an application. Fortunately, Microsoft Visual Studio presents many ways to trace through your code while the application is running. Traces can help you understand what is occurring inside your application. The ability to capture and identify errors in both development and production environments is a powerful tool that will help ensure that ASP.NET MVC correctly manages application. Design an exception handling strategy Exceptions are a standard part of applications. Even if your software is error free, your application can throw exceptions or experience other problems due to external factors, such as improper data input or network problems. As you design your ASP.NET MVC application, you should consider potential problem points, such as calling a web service for data or accessing files on a file share, and determine what you will do when an error occurs. Also, consider whether you will notify users and, if so, what you will display in a message. You also need to choose recovery options to keep your application in a normal running state and the kind of diagnostic information you should capture. Handling exceptions across multiple layers There are different places in an application in which you can throw an exception, and what you do with those exceptions will be affected by where the exceptions were thrown. When you are writing an application that enforces separation of concern, determining how best to manage errors is complicated by this separation. If all work is done in the same layer, managing errors is easy because you do not have to negotiate boundaries. However, multiple layers’ complicate things and require you to understand layer rules. A layer should know only about the layer it communicates with, and it should have no knowledge about layers that might be calling it. A traditional three-tier application, shown in Figure, has a data layer, a business layer, and a user interface (UI) layer. The data layer doesn’t know anything about the other layers, the business layer knows about the data layer but nothing about the UI, and the UI layer knows only about the business layer but not the data layer. [caption id="attachment_125" align="alignnone" width="300"] Traditional three-tier application[/caption] Because of the relationships between the layers, errors in the data layer will make no contextual sense in the UI. They do, however, make sense to the business layer. This shows one of the primary architectural considerations when needing to handle exceptions across multiple layers. A layer should ensure that no errors pass through. The business layer, for example, should capture all data layer errors. It should do whatever work needs to be done as a result of those exceptions and determine whether an exception should be sent to the UI for rendering to the user. Consider this example: A user comes to your website and attempts to log in. Your website, or your complete ASP.NET MVC application, is acting as the UI layer in an n-tiered application and calls the business layer with the login information. The business layer reaches out to the data layer to determine whether there is a match. However, the database server is down, so when the business layer makes its call, it gets an error. There are several choices at this point. You can pass the error up to the UI layer, or analyze it in the business layer and decide what to tell the UI layer. Perhaps your application throws an EntitySqlException or SqlException. Does your user need to know that information? Probably not, so it would make sense to capture the error when you get it and then log it. However, because it is a fatal exception, you need to tell the user something. It would be reasonable to throw a new custom exception such as a DatabaseException. Because this would no longer be a data layer exception, it would be sensible for the user interface to manage it. The same approach is appropriate when working within your ASP.NET MVC application. Model errors, for example, should be managed by the controller. If work needs to be done to manage the error, logically it should be managed in the controller. Controller errors are usually propagated out of the controller and into the processing layer. You will typically be catching and managing these errors through the use of MVC-specific error handling protocols. Displaying custom error pages, creating your own HTTPHandler, and setting Web.config attributes Although IIS comes with default error pages, it is rare for those pages to look like they belong to an application and to provide the appropriate level of information to the users. Developers customize the error pages as part of their error management and handling process. You need to determine which errors will have custom pages and what kind of information should be displayed on the pages. When implementing custom error pages, there are at least two primary error pages: one to handle 404 Page Not Found errors and a more generic error display page. However, your application might need to display different information based on the error condition or the portion of the site the user is visiting. You can create these pages as you would any other ASP.NET MVC page: with a view and a controller. You can also pass in a model from your error handler that contains the error information to display information that might be useful to display to the user. Let’s look at an MVC application with a standard routing construct. In this series of examples, we use a controller called ErrorManagerController that has various action methods for each of the HTTP statuses, such as Status400, as well as a default general action method of ServerError to manage the display of custom error pages. The Global.asax page is one of the ways you can support custom error pages. Because the ASP.NET MVC framework is based on ASP.NET, there are some shared features, especially in the Global.asax file. The Application_Start method is the most common one used in both ASP.NET and ASP.NET MVC. You can also use the Application_Error method, a global error handler that is called when an unhandled error makes it through the application stack. You can manage an error using the Application_Error method in the Global.asax file. The method gets the last exception on the server, logs the information, clears the error, and then forwards the user back to the custom error page. In this case, the user is just redirected to the ErrorManager controller’s ServerError method. However, more logic could be put into the method to redirect the user to more applicable error pages. This decision could be based on the type of error as well as whether you need to pass the error to the controller, in which it can determine what, if anything, should be displayed to the user. You can also set error information in the Web.config file by adding error nodes to the section of the area. The following example redirects the appropriate status code to the indicated URL: The customErrors element has two attributes that are of interest: mode and defaultRedirection. There are three values for mode: On, Off, and RemoteOnly. On and Off specify whether custom errors should be used. RemoteOnly specifies that custom errors are displayed only to remote users while standard error pages are shown to local users. RemoteOnly is the default setting. The defaultRedirection attribute gives an overall handler. If an error occurs that is not handled with a more specific error element, this is the URL that will be presented to the user. HTTP 500 errors are generally handled through other means than configuration, such as filters or OnException handlers. You must set in the section of Web.config as well. Handling first chance exceptions First chance exceptions are exceptions before they have been handled by an error handler. Every error that occurs in an application begins the error-handling process as a first chance exception. You should try to detect first chance exceptions during the development process to determine how and why they are occurring. You can also capture exceptions during the application runtime and evaluate them at that point. To configure Visual Studio to detect first chance exceptions, ensure that the Thrown box is checked for the Common Language Runtime Exception row in the DEBUG Exceptions dialog box, as shown in Figure. FIGURE Enabling detection of first chance exceptions in Visual Studio When you make this selection, every exception thrown while running in debug mode will be captured by the debugger. You can examine the exception as soon as it is thrown to find and manage other exceptions that might be handled but should not be occurring, or to trace the error through the application flow to ensure that it is properly handled. Figure shows the outcome of an exception. As soon as it is thrown, the debugger catches the exception and displays it. The ability to catch first chance exceptions in Visual Studio is a significant advantage. It helps you find problems that might be mistakenly hidden, such as those handled by an empty catch block or those that are entirely mishandled. Because exceptions affect performance, you can find errors that are being handled but should not be occurring, such as when trying to parse an object. You can identify those items and correct them, by changing the Parse method to a TryParse method, for example. Capturing first chance exceptions in the debugger gives you the opportunity to manage and control exceptions before they make it to the production environment. However, that does not mean you can find all errors. An unexpected condition in production can cause a special error condition that did not occur during development. Fortunately, you can catch first chance exceptions in your ASP.NET MVC application by inserting code in the Global.asax file. Demonstrates how to handle FirstChanceExceptions in your application by setting the event handler. Using first chance exception functionality enables you to add logging or some other error management technique into your application that will be called whenever an exception in your application is thrown. This is just a notification, however, and it can cause its own set of issues. You also have to be careful when managing code within the FirstChanceException method because an error in that method causes a FirstChanceException to be called. This results in a StackOverflow exception because of the recursive calling of FirstChanceException. The notification of the error does not do or allow anything to handle the error; it is simply a notification that the error has occurred. After the event, has been raised, and after the application calls the event handler, the application will continue to process the error normally. The Common Language Runtime (CLR) will also suspend thread aborts while the notification event is being processed, so the thread cannot be affected until after the handler has completed processing. There are several ways to use first chance exception handling in your ASP.NET MVC application. The first is as a universal logging processor that standardizes logging efforts. However, you must be sure to handle the error. It might be appropriate to manage the work being done in the first chance exception handler through a configuration setting. This way you can control the risk of using first chance exception notification by enabling it only when needed.

SharePoint 2013 App: Workflow with Custom Task Outcomes

bharatgupta04 — Sat, 27 Apr 2013 07:39:08 GMT

In SharePoint 2013, there are many scenario in which use want to customized task form based upon business requirement. By default SharePoint provides “Approve” and “Reject” button at the bottom of your task form. So In this blog post I will explain you how we can create our own custom button for the workflow task form

By performing some simple steps we can achieve the functionality to create custom button at the bottom of task form.

Step 1: Open Visual Studio 2012, Create new project by selecting Apps for SharePoint 2013 and select the “SharePoint - Hosted” apps and click on finish.

Step 2: Create a new site column with name “CustomTaskOutCome” of type OutcomeChoice.

Step 3: Create Custom Content type and inherit from task as per shown in below screen

Step 4: Now we need to add the “CustomTaskOutCome” site column and exiting “WorkflowInstanceId” field to the newly created content type.

Note: OOTB SharePoint workflow task content type is made up of these field and inherit from task content type.

Step 5: Create an Custom list instance based on existing Task list template as shown in below screenshot.

Step 6: To make our custom content type to be available for the list we need to add the content type binding to the list instance. So that at the time of list creating content type will automatically attached to list.

Step 7: Now we need to create the workflow so that we can perform action based upon our custom task outcome.

Step 8: Select the type of workflow as a list and click on Next.

Step 9: Provide the name of list where we need to run the workflow. Also make sure Task list will point to list which we have created and select finished.

Step 10: This is very important point because we need to attached the task activity to our custom content type.

ContentTypeId: This should be the id of content type which you have created.
OutComeFIeldName: This should point to your custom site column which you have created.

Step 11: Now we need to deploy the solution to our O365 site. After deployment we need to add new item to custom list to run the workflow. Workflow will create the task and assigned to user.

Step 12: Once task is created and edited by user. You will see there will be three button

So you will see in below screenshot that workflow is acting upon custom column.

Hope this will help.. :)

SharePoint 2013 App Model: How to view list, list settings inside app

bharatgupta04 — Sun, 10 Mar 2013 13:05:00 GMT

Tip#1: SharePoint hosted app

Microsoft bring with new development approach “app” framework in SharePoint 2013 and whenever a new version of SharePoint brings a new development approach, developer often face some internal challenges.

In SharePoint 2013 each app create a new “app web” inside the “host web”. SharePoint App web does not own setting page or any navigation to traverse to list, list settings.

In this blog post I will provide you some useful tips about app model

View List and List Settings: In normal scenario when we create any list using SharePoint host apps, there is no default option to see the list and go to list settings

I have created the list with Name “QuickStatus” but there is no option for directly go to the list and view the content.

Conclusion:

In order to go to the list directly type the name of the list after your app name

Example: “https://app-guid.contosoapps.com/sites/sphostedapps//Lists/QuickStatus/Allitems.aspx”

To View List Settings Click on the “Modify View” from the ribbon. You will see the “Settings” link on the top as shown in below screen. Click on the link and you will redirect to setting page.

You can also directly open in the browser by specifying the URL as shown in below screen by specifying the list id.

Hope this will help!

Create Cascading Dropdown in Browser enabled InfoPath form using InfoPath 2010

bharatgupta04 — Thu, 07 Mar 2013 10:24:20 GMT

In this post you will learn how we to create the cascading dropdown in browser enabled InfoPath form. As many of us know that in Office InfoPath 2007 it is very difficult to create the cascading dropdown without writing any single line of code but in InfoPath 2010 we can create without any code.

First create one List in SharePoint 2010 named with “CascadingDemo”. Create two column named with “Organization” and “Department”. Insert some sample data into the list as show in the screen:

In this list we have some organization that have different department. For example OrganizationA has two department like DepartmentA and DepartmentB. and OrganizationB has three department like DepartmentA, DepartmentB and DepartmentC.

Now we need to design the InfoPath form. So We need to Open the Microsoft InfoPath Designer 2010 and create a blank form. Make sure that form has “Web Browser Form”. See the screen shot below:

Now we need to create the Secondary Data Source to connect to SharePoint list.

Click on the data tab and then click on “From SharePoint List” under the ribbon.

Provide the name of the site where you want to connect to the SharePoint List.

Now we need to select the list from where we want to fetch the data.

Now we need to select the column from which we need information. So I selected the organization and department. And sorting the data by the Organization in ascending order. Then click next.

Provide the name of the Data Connection and click on finished.

Now create the form which contains the two dropdown one for Organization and one for Department.

Now we need to bind the dropdown with the Secondary Database.

Select on the Organization dropdown and go to the “Dropdown List box properties”. Bind the dropdown with the secondary data source. See the screenshot for more information.

Now our main work begin from here to bind the “Department” dropdown. So that value shall be displayed based on the selection of “Organization” dropdown.

Select the “Department”dropdown and go to the properties. Select the secondary data source. Expand the “entries” section and select the “Department” node. Now most of us know that filter is not supported into the browser enable InfoPath form in MOSS 2007. but in SharePoint 2010 we can filter the data. So select the Department node and click on the filter data.

Now click on the “Add” button. and specify the filter condition.

Select if “Organization” is equal to “Select the field or group”. Click on the “Select a field or group” section from the dropdown.Refer the screenshot as display below:

Now select the “Main” from the dropdown and select the organization node then click on the ok button.

So we have set the rule that Select the department if “Organization” from the secondary data source is equal to “Organization” of main data source.

Now we are assuming that you have basic knowledge of the InfoPath form so you know the steps to publish the form.

For publishing the form you can go under the file tab and from the info section you can click the “Published the form”. and follow the instruction and form will be published into the SharePoint library. Here I have given the library name as “CascadingDemoSampleLib”.

Click on the New document so you will see the InfoPath form. Please see the screen shot :

So We can create the cascading dropdown without writing any code in InfoPath designer 2010. This is possible due to filter support in InfoPath 2010 for browser enabled form.

I hope you will enjoy this.