|
1 | 1 | In this post, we will explore how to deal with references to older 3rd party packages.
|
2 | 2 |
|
3 | 3 | When dealing with older .NET applications, there is a good chance the application will be referencing a number of 3rd party packages. It is worth reviewing each of these packages to check for the following:
|
4 |
| --Is there a newer version of the package avaiable? Older versions may no longer be supported, or in the case of some web frameworks they may not work in new browsers. |
5 |
| --Is the package available on Nuget? |
6 |
| --Are there better options for the packages |
| 4 | + |
| 5 | +- Is there a newer version of the package avaiable? Older versions may no longer be supported, or in the case of some web frameworks they may not work in new browsers. |
| 6 | +- Is the package available on Nuget? |
| 7 | +- Are there better options for the packages |
7 | 8 |
|
8 | 9 | #.NET Packages
|
9 | 10 | In BugTracker.NET, we have identified 3 different packages that were being referenced: log4net, Lucene.NET and SharpMimeTools. All appear to be very out-of-date so let's take a look at what we can do to upgrade these.
|
@@ -98,7 +99,8 @@ A more modern and active project appears to be [ElasticSearch / NEST](https://gi
|
98 | 99 |
|
99 | 100 | By decoupling the web application from the search server, we are able to independently scale the web server and the search server. We could add web server nodes without effecting the search. Likewise, we could add search nodes without effecting our web server nodes.
|
100 | 101 |
|
101 |
| -****REWORD****Also, using Lucene.NET and storing the search index in the App_Data folder does not made the application very 'cloud-ready'. |
| 102 | +Also, using Lucene.NET and storing the search index in the App_Data folder does not made the application very 'cloud-ready'. |
| 103 | +In modern application deployment scenarios, such as deploying to the cloud, we want to maintain a separation between application and the infrastructure serving this data out. This allows us to scale them independently and reduces the chance of a catastrophic failure: if the web server gees down we can quickly start up another to replace it. In fact on Azure it is highly inadvisable to store anything more than transient cache data on the web tier. The Azure infrastructure will, from time to time, remove your web server node and replace it with an equivalent one in order to apply patches. While your code will be automatically redeployed any data it may have written to the local machine will be lost. |
102 | 104 |
|
103 | 105 | Giving the scalability concerns and some bad patterns identified in the BugTracker search code, it will be best to move the implementation to use ElasticSearch / NEST instead.
|
104 | 106 |
|
@@ -172,5 +174,47 @@ Our new search implementation is now complete. We can delete my_lucene.cs and re
|
172 | 174 |
|
173 | 175 | [View the commit](https://github.com/dpaquette/BugTracker.NET/commit/fdc471e0ce4900573d61e8873e2c662f94a62dce)
|
174 | 176 |
|
| 177 | +###SharpMimeTools and Pop3 |
| 178 | +SharpMimeTools is an open-source MIME parser / decoder. BugTracker usies this library to parse information from incoming emails and to format email messages when sending bug notifications. |
| 179 | + |
| 180 | +It is unclear if BugTracker is referencing the latest version of ShareMimeTools because assembly is version 0.0.0.0. SharpMimeTools is not available in NuGet and according the the [SharpMimeTools website](http://anmar.eu.org/projects/sharpmimetools/), the latest news was in 2006. This is probably a good time to start looking for an alternative, more actively supported library. |
| 181 | + |
| 182 | +After a quick search on NuGet, we found that [OpenPop.NET](https://www.nuget.org/packages/OpenPop.NET/) seems to be a popular option. In fact, we can also use OpenPop.NET to replace a large block of [Pop3 code](https://github.com/dpaquette/BugTracker.NET/blob/3c64d84de9af96763713eae862d2b2eeeb1cf665/src/BugTracker.Web/btnet/POP3Client.cs) that was downloaded from CodeProject in 2003. |
| 183 | + |
| 184 | +After further review of the usage of POP3Client and SharpMimeTools has revealed a serious design problem. BugTracker is attempting to run a recurring background task in the web application that pools for email in a pop3 account. This type of polling code would be better suited as a Windows Service, Scheduled Task or Azure Web Job. It is the type of work that should run out-of-process as it is dangerous and difficult to consistently run [background tasks in a web application](http://haacked.com/archive/2011/10/16/the-dangers-of-implementing-recurring-background-tasks-in-asp-net.aspx/). |
| 185 | + |
| 186 | +Luckily, there is already a Windows Service and Console Application that also implements this email polling logic. Let's include these existing projects in the BugTracker.NET solution. |
| 187 | + |
| 188 | +[View the commit](https://github.com/dpaquette/BugTracker.NET/commit/ee6a479ffed16bae588e945a831ab117e075fea3) |
| 189 | + |
| 190 | +Next, let's delete the experimental code in BugTracker.Web and move the inlined C# code in insert_bug.aspx code to a code-behind file. |
| 191 | + |
| 192 | +[View the commit](https://github.com/dpaquette/BugTracker.NET/commit/b73a0a3d61db538b138d3c8d6bdaca08a5924ddb) |
| 193 | + |
| 194 | +The code in the console application polls for email using Pop3Client, then from any new email found it creates new bugs by posting the raw email message to insert_bug.aspx. Insert_bug.aspx then uses SharpMimeTools to parse the email message and create a new bug. Let's refactor the code in the console application to use OpenPop.NET. |
| 195 | + |
| 196 | +We will need to install the OpenPop.NET package in the btnet_service and btnet_console projects: |
| 197 | + |
| 198 | + Install-Package OpenPop.NET |
| 199 | + |
| 200 | +[View the commit](https://github.com/dpaquette/BugTracker.NET/commit/3438da9cf977dfaea2d9b8c23a109fe932a596de) |
| 201 | + |
| 202 | +Now we can refactor the polling code in POPMain.cs to use OpenPop.NET and delete Pop3Client.cs. |
| 203 | + |
| 204 | +Testing the pop3 functionality is a little tricky as we need a pop3 server to talk to. I followed the instructions on Peter Kellner's blog to [setup a local test instance of hmailserver](http://peterkellner.net/2012/03/11/how-to-setup-your-own-pop3imap-email-server-for-local-development-testing/). |
| 205 | + |
| 206 | +The code is still a little messy, but we have managed it clean it up a lot by getting rid of the custom Pop3 implementation. We deleted about 600 lines of code in this commit and have moved to a Pop3 implementation that is likely more standard and is definitely more trustworthy. |
| 207 | + |
| 208 | +[View the commit](https://github.com/dpaquette/BugTracker.NET/commit/337646cbdcdfb566a1edb9e994c190a899caa202) |
| 209 | + |
| 210 | +Now, the last step is to replace any use of SharpMimeTools from BugTracker.Web. Let's add a reference to OpenPop.NET to the BugTracker.Web project, then remove reference to SharpMimeTools. Since this was the last reference to SharpMimeTools, we can delete the file from the references folder. |
| 211 | + |
| 212 | +Again, the code is not as clean as it could be but we have made a major improvement. We deleted over 200 lines of rather obscure mime parsing code from Mime.cs. |
| 213 | + |
| 214 | +[View the commit](https://github.com/dpaquette/BugTracker.NET/commit/0ed3d6e0ceff535fa9e57fe0cda534b2f689edc7) |
| 215 | + |
| 216 | +While we are in the mood to delete some code, it looks like we had the source code from SharpMimeTools hanging around. We won't be needing that anymore so let's delete it. |
| 217 | + |
| 218 | +[View the commit](https://github.com/dpaquette/BugTracker.NET/commit/e3d6b4144d6e1d893e247dbc90a870b4ff860258) |
175 | 219 |
|
176 | 220 | #JavaScript Libraries
|
0 commit comments