How does it help?

The client wanted the ability to read the email inbox, import the order to the system and then send the email with the order details generated to the sales representatives.

With regular mail reading API’s the process would have been as follows. First the email is read, secondly the order is imported, and finally a new function is called that sends a new email with new order details to the sales representative. In this case the details of the requester are saved and reused for sending the confirmation email.

Using the EWS managed API, a more efficient solution was developed. The email was directly forwarded from the email inbox, without the need to create a separate email for the order confirmation. The confirmation email is created directly from the received email object, as is the forwarded email to the sales representative. The following code sample shows how the forwarded email is created and sent:

ResponseMessage responseMessage = message.CreateForward();
responseMessage.ToRecipients.Add(email.FromAddress);
responseMessage.BodyPrefix = messageBodyPrefix;
responseMessage.Send();

In the code snippet above, “message” is the object which contains all the details of the order email and we use it to create the new forward email without saving any details to the local system or variables.

Similarly, we can use reply functionality of the API to maintain the email conversation chain by using the following code:

bool replyToAll = true;
ResponseMessage responseMessage = message.CreateReply(replyToAll);

string emailbody= “Please find the attachment below.”;
responseMessage.BodyPrefix = emailbody;
responseMessage.Send();

Setting the “replyToAll” variable to true specifies that mail will be forwarded to all the recipients who were present in the original conversation. The text contained in the variable “emailbody” will be on the top of the email body of the conversation.

Additional features of EWS managed API

EWS provides useful features for dealing with emails with invalid delivery email addresses. The postmaster bot may send a mail delivery failure email to the same inbox, which can cause issues with the importing of other orders. These issues can be resolved in EWS by checking the subject lines, and automatically deleting delivery failure emails, or moving them to a separate folder. These orders can then be separately corrected and resent without interfering with the remaining orders in the inbox.

The following code sample can be used to move all the email items from the inbox to the “DidNotDelivered” folder:

Folder rootfolder = Folder.Bind(service, WellKnownFolderName.MsgFolderRoot);
rootfolder.Load();
foreach (Folder folder in rootfolder.FindFolders(new FolderView(100)))
{
FindItemsResults findResults =
service.FindItems(WellKnownFolderName.Inbox, new ItemView(10));
// The if below checks if the folder “DidNotDelivered” is present in the email box
if (folder.DisplayName == “DidNotDelivered”)
{
var fid = folder.Id;
foreach (Item item in findResults.Items)
{
item.Load();
item.Move(fid);
}
}
}

This is how EWS helped us simplify the processing of emails with minimal lines of code.

We hope that this article gives you some useful ideas for dealing with Microsoft Exchange using EWS. If you are having issues, feel free to get in touch with us at https://www.metasyssoftware.com/dot-net

ANTS Profiler

ANTS Profiler can be used on any .Net application, either web based or in Windows to identify slow processes. We have found that it is useful both at the development stage, and the QA stage. Using the tool involves starting up the ANTS Profiler, and navigating through the app to view the pages with slow performance. Once the profiling is complete, we can dive deeper into the processes that the profiler identifies as slow.

To give you an idea, here are some examples of performance issues we were able to identify and address:

1. The first step we took when analyzing a slow app using the ANTS tool, was to check the database calls. The profiling showed that certain stored procedures were taking a lot of time. The problem was addressed by rearranging joins used in the stored procedures, and selecting only those columns necessary for the output. This significantly improved the rendering time for the page.
2. The profiling also showed that in a single page, there were multiple stored procedure calls which were increasing the database hits and slowing down the app. To overcome this problem, we combined multiple stored procedures into one, which improved the page performance.
3. It was further identified that whilst rendering the page, multiple JavaScript and CSS files were getting loaded, making rendering very slow. The ANTS Profiling helped identify the slowest web requests. This allowed us to use the bundling concept to group files together in order to reduce the number of web requests, thereby improving the speed of rendering.

New Relic

New Relic is another commercial tool which can be used to analyze performance once an app has already been launched. It provides real-time data of user experience with the application in the production environment, which is extremely useful to optimise the process of improving application performance.

To give you an idea of how New Relic can be used, below are some insights we gained from New Relic when trying to improve a customized web application.

1. The data showed us that as the number of users increases, the rendering time for the page increases as well. It was able to give us a lot of insight into how CPU and memory is used by the application.
2. The data also showed us which pages are most viewed, allowing us to focus on improving the performance of these pages. It also showed us on which pages errors were most frequently encountered, as well as the time taken for web requests and database calls on these pages. These were then fine-tuned to significantly minimize the frequency of errors.
3. The tool gives us analytic information about the most frequently used browsers and devices used to access the web application. This information helped us focus the application implementation in order to improve the user friendliness on those browsers and devices.

Improving the app performance in terms of speed and user friendliness will improve the user experience and thereby significantly increase web traffic. Although working on application performance can be a pain, ignoring it is not advisable for any developer. The use of these tools can be very helpful at different stages: ANTS Profiler is most useful at the development environment and for QA, whereas New Relic is most useful in the production environment to analyse the user data.

MetaSys has extensive expertise in improving application performance, including the use of the different tools, some of which have been described in this article. Feel free to contact us for help with improving your application performance. For more info https://www.metasyssoftware.com/dot-net

We have experienced difficulties in both these areas using the Entity Framework, and in this article, I will be describing the cause of the issues, and the solutions that we at MetaSys came up with. If you are having performance issues with Entity Framework, this article might provide some useful insight and suggestions.

Our issues with the  Entity Framework:

Let me quickly brief you about how we started using Entity Framework. We started application development of a .NET web application roughly 10 years ago. At the time, Entity Framework was a new concept introduced by Microsoft. Its purpose was to allow the developer to more easily write SQL queries including calculations, it also simplified CRUD operations and handled results into objects. We used Entity Framework for our web application, and during initial testing, everything was working very well.

The performance issues arose after the client started using the application, particularly as the amount of data in the database started growing. We used the Ants Profiler tool to identify the root cause of poor performance. It showed us that stored procedures were executed fast without any significant delay, but with the Entity Framework code, it was taking a long time to render data on a page.

Another issue was that the SQL database for the application had more than 300 tables. Updating the Entity model with a change in any of the tables would take a very long time. It was also difficult to merge changes of only one developer, or only one module, as it would update the entire Entity model. This made it a challenge to release the application module-wise.

MetaSys Approach :

To overcome performance issues, we first tried to change some of the settings of EDMX, and secondly updated the Entity Framework to the latest version. Neither made much difference to the performance. In the meanwhile, the applications database size and complexity kept on growing, as the application grew.

Eventually, we replaced the Entity with ADO.NET, and we immediately saw a significant improvement in performance. The difficulty we faced with the conversion was how to handle the ADO.NET result into objects. We resolved this using the open-source Dapper ORM. Dapper is a framework for mapping relational object models. Like Entity Framework, It eases the handling of data in objects and supports multiple data query results. This solution not only improved the page loading time, but as there was no need to update the entity model, the developer’s time also reduced significantly.

So far we have found that using ADO.Net with Dapper ORM solved all the problems we experienced with the Entity Framework.

About Us:

Our team of Dot Net developers have experience of building Dot Net solutions using Microsoft technologies for more than two decades using VB to latest .Net Core applications. For more info. https://www.metasyssoftware.com/dot-net

This article details such an integration project. Our Dot Net application team helped a client integrate InBody technology into their application. 

InBody devices offer detailed measurement of body composition balance, including key health factors such as protein, minerals, BMI and body fat percentage. Our project revolved around integrating the InBody 570 device with a .Net application. The solution we implemented involved the .Net application listening to the serial ports attached to the device for the duration of the test. After receiving a data stream from the InBody device, relevant data is extracted using indices of specific data factors mentioned in the InBody 570 technical documentation. Key settings required by the .Net application include baud rate, parity, data bits, and stop bits. The InBody technical specification includes more details about the values of these settings.  Once the data stream is received, and the data factors are extracted, the data was saved in an SQL server database. The .Net web application reads this data from the SQL server database and displays it to the user. 

Key Challenges

The idea is that the application can be used by the fitness facility subscribing to the application and having an InBody machine. The application runs on a laptop or desktop computer connected to the Inbody machine. However, one challenge was that there is no guarantee that the computer is always connected using the same port. If the computer had more than one port on which the device stream can be received, then we had to lock and keep listening to all available ports. Our solution to these issues was to program the app to lock and keep listening to all available and open ports of the laptop and as soon as we receive either data stream or exception, we unlock all ports locked by the .net application. It is important to note that only that process which has locked the serial port can unlock it, no other process can forcibly remove that lock. In the event that the process which locked the port gets terminated, one is left with only the option of system reboot in order to unlock that port.

Another issue is that the same app was required to integrate with another measurement device manufactured by InBody, the BPBIO 320. This device reads systolic blood pressure, diastolic blood pressure and pulse, and we modified the .Net app to work with both InBody devices. We used a condition-based code, which looks at application settings and accordingly saves the data in either the production or the staging environment. The BPBIO 320 requires a different baud rate to that of InBody 570, therefore we adapted the application so that the user enters the test type, and then the baud rate is automatically set up by the software. We also process information contained within the data stream that indicates status such as “Measurement started”, “Measurement interrupted due to use of the stop button”, and “Measurement interrupted due to error”.  These cases are handled in the application and clear information is passed on to the user.  

We used a PuTTY tool to simulate the device stream in the development environment, as the physical device was not always available. Device testing was performed after development was complete, and we made the necessary changes to the application before the launch.

We will be glad to help anyone interested in doing similar kinds of integrations in their software. For more info https://www.metasyssoftware.com/case-study-dotnet

Our experience with wkhtmltopdf

In the past, we generally used wkhtmltopdf to implement pdf functionality in our web applications. It was a practical choice, as it is an open-source tool with which we have extensive development experience already. The converter tool is given a destination file path and a URL of the report web page. Since the download button is contained within the generated report in web page form, the pdf conversion adds an unnecessary report generation step. To avoid this inefficiency, we wanted to explore different pdf converter options.

Our experience with NReco

We came across a library in a NuGet package called .Net Reusable Components (NReco), which contains a collection of reusable components for the .NET platform including a pdf conversion tool. The only input the tool requires is either a URL to the web page or the report contents as an HTML string. NReco is easier to implement, requiring only two to three lines of code. Even reports containing charts and images created using a third-party tool can be rendered to a pdf without additional coding. All CSS, fonts and images in HTML are supported by the NReco conversion tool.

The NReco tool is easy to install, and performs efficiently, taking much less time than wkhtmltopdf to generate a pdf. Although we currently only use NReco for pdf conversion, many other tools are available.

A major advantage of NReco, is that it supports both the .Net framework and .Net Core. Since we are looking to upgrade a number of our applications to .Net Core, it saves us considerable development time if we can use the existing code for pdf conversion.

To conclude, using NReco instead of wkhtmltopdf for pdf conversion has many benefits including easy implementation, performance, and compatibility with .Net Core.

About us

Our team of .Net developers have successfully delivered applications using ASP.Net Core, .Net & ASP.Net framework, Visual Studio, Microsoft SQL Server, Team Foundation Server, Javascript and JQuery. For more info – https://www.metasyssoftware.com/dot-net

Case study

Our client wanted a way to efficiently track day to day reporting, check the status and progress of different tasks, and financial metrics like revenue, costs and profit-loss data. Previously, they had to access several different reports to analyse the overall business performance. We built a dashboard that allowed them to visualise the day to day business activities on a single screen, saving time and energy.

We decided to use Google Charts for a number of reasons:

• Google Charts are a good tool for visualization as the graphics are highly interactive.
• There is a large gallery of chart types that allow for a lot of customisation for representing different kinds of data.
• It is compatible with different browsers.

Technology and Implementation

For the implementation of the dashboard we used jQuery and ASP.net. These technologies are easy to use, and allow for easy rendering of the page. Furthermore, Google Charts have an inbuilt library in jQuery.

Implementation steps of Google chart in ASP.NET

Before the implementation, all the Google Chart Libraries and the visualization API need to be loaded. The following procedure was used to include a chart in ASP.net:

1. Create an html div to hold the chart as per our requirement.
2. Ajax call for loading data in the chart
3. Call the Visualization API before assigning it to the chart and set the chart options like legends and axis titles
4. Assign the div id to the chart
5. The call to the chart depends on the chart type (barchart, donut chart etc.).
6. Call the draw method of the Google chart and set the chart option.

Chart examples

Donut Chart:

Stack Chart:

Matching client requirements

Our main challenge was to modify the chart to meet the clients needs.  For example, the client specified that the revenue chart was to be displayed in a rectangular format without a legend, or axes. We identified the “Timeline chart” as the most appropriate chart option amongst the templates although it still required customization. We modified the inbuilt generated SVG code from JavaScript by specifying the position and width and by hiding the x- and y-axes to match the client requirements.

If you are interested in a similar implementation of data visualisation, feel free to contact us. Our team has extensive experience in handling diverse custom ASP.NET application projects. https://www.metasyssoftware.com/contact

Like many others, we have been working on MVC 5 based web applications since 2013. With Microsoft planning significant investment into the open-source development platform .Net core, we saw the advantage of migrating our current applications to the new platform sooner rather than later.
The first version of .Net Core 1.0 was released by Microsoft in 2014, followed by several versions, most recently .Net 3.1.1 in January 2020. At the time that we started the migration in 2019, we found .Net 2.2 to be a stable version with a well-developed community advanced enough to answer our queries. The web application that we decided to convert to .Net Core was developed in 2017 on the .Net 4.5.1 MVC platform.

Initial considerations
Evaluating the conversion risk is an essential first step before convincing the client to invest in the new technology. Several factors need to be considered, including the project timeline, the scale of the project and the available resources. Using a team that has worked with the technology for at least a year or two is the best option for reducing risk in such a conversion project. A great option is using interns as an additional resource, as the project provides them with the excitement of learning something new.

HOW to start?
The first step is to check the old application with the tool called NET Portability Analyzer Tool. This tool analyzes assemblies and provides a detailed report on the .Net APIs that are missing for the applications or libraries to be portable on .Net Core. It is not a tool which will automatically convert the .NET MVC app to a .NET Core, but it is a useful initial guide towards identifying the portable and non-portable items.
The tool details are available on the Microsoft website:
https://docs.microsoft.com/en-us/dotnet/standard/analyzers/portability-analyzer
The tool can be downloaded using the link: https://marketplace.visualstudio.com/items?itemName=ConnieYau.NETPortabilityAnalyzer

The screenshots below show some of the tool outputs:
Portability Summary

Details

Missing Assemblies

Creating the new project
It is not useful to open the entire MVC project as a .Net Core project immediately in Visual Studio (VS) 2017, as it will result in a huge list of errors that are difficult to address one by one. A better approach is to create an empty project and copy a few models, controllers, views or corresponding files at a time into the newly created .Net Core project in the VS 2017 environment. After each addition, build the project, analyze and fix the errors.
What were my next steps? Let me give you some technical bullets here.
One of the important steps is to move the connection strings settings from Web.Config to JSON settings in the file named as AppSettings.JSON .
It is necessary to add a middle layer file for the session and call it in the StartUp.cs file. so that all the session objects set on the Global. asax file that do not exist on the .Net Core project will go into the middle layer file and register as a service in StartUp.cs. The Session dependency is included by adding AddSession into ConfigureServices of StartUp.cs
Convert all of your class libraries created separately to .Net standard Class Libraries wherever required by creating a .NET Standard Project and add the references wherever required for the new .NET Core Web App project you have created.
All static files like Images, icons, CSS, JS, email templates need to be copied into WWWRoot. The file locations have to be changed across the project wherever they are referenced.
The Route.config file should be replaced by adding the MapRoute in the StartUp.cs file.
We can create Set and Get extension functions Like SetObject and GetObject for handling session operations as shown below

We have two parts in our project Web App and Web API so we have to add the DI (Dependency Injection) for calling WebAPIClient and HostingEnvironment (IWebAPIClient webapiclient, IHostingEnvironment env)

What can be done on SSL redirection?
We have to add following setting in AppSettings.json file

Also we have to add following code in Startup.cs

Third party Dlls
Every project has some third party Dlls used in the project for a specific purpose. For our application, the third party Dlls like EPPlus, ICSharpCode.SharpZipLib library worked on the .NET Core project without any issues. However, it is possible that certain third party tool kits are not compatible with .NET Core. Some can be downloaded from NuGet or by contacting a third party vendor.
There may be instances where third party assemblies used in the project do not work and cannot be bought from third party vendors. In this case, I would recommend finding a solution that omits the tool altogether. It pays to think of this early whilst updating any web app that might be migrated in the future. This way incompatible third party Dlls can be avoided in favor of compatible tools, in order to save work at the migration stage. One such example is Nreco PDF to Image renderer, which has a version that is compatible with .Net Core available from a third party vendor.

The technical points in this article refer to architectural changes, I will cover the common conversion issues and deployment in the next article so stay tuned…

For more details regarding the kind of ASP web application projects which we handle https://www.metasyssoftware.com/case-study-dotnet