Building a Dynamic Currency Converter Server
When you build a web‑based currency converter, the most common approach is to embed a fixed list of rates into the application. Those rates are typically read from a local XML file that you update manually or on a regular schedule. The downside is that if you need the freshest data or if you want to keep the converter lightweight, you have to write a routine that fetches the rates from an external source, parses them, and writes a new XML file that the application can consume. In this guide we walk through that whole process, from the web scraper that pulls the rates from a public exchange‑rate service to the C# DLL that packages the data and finally the ASP.NET Web Forms page that performs the conversion.
The data source we use is the PACIFIC Exchange Rate Service, which publishes daily rates for more than 240 currencies. The website presents the rates in an HTML table; our scraper will extract the table rows using regular expressions, then produce a clean Rates.xml file. Because the XML is the only thing the Web Forms page needs, the rest of the application stays simple and maintainable. We also provide a command‑line executable that can be scheduled in Windows Task Scheduler to run every evening, ensuring that the converter always shows the latest rates without manual intervention.
Below you’ll find the key components: a DLL that performs the extraction and conversion logic, a small executable that drives the DLL and writes the XML, and an ASP.NET Web Forms page that loads the XML and performs the user‑initiated conversion. Each piece is written in plain C# 7.0, uses the .NET Framework’s standard libraries, and can be compiled with the same command script that ships with the source.
By the end of this walkthrough you’ll have a ready‑to‑deploy currency converter that updates itself automatically, an XML format that can be extended or replaced, and an ASP.NET page that demonstrates how to bind data to controls, sort it, and display results in a user‑friendly way. You can then take this foundation and plug in additional features, such as a history log, different base currencies, or an API endpoint for other services to consume the rates.
Creating the CurrencyConverter.dll Component
The first step is to write a small library that can be called from both the console program and the ASP.NET page. The library’s public surface is intentionally narrow: it accepts a URL that points to an HTML page, downloads the content, extracts the rows that contain currency names and rates, and returns a collection of To keep the extraction logic fast and easy to maintain, we use a single regular expression that matches all Below is the core of the Rate objects. The Rate class is a lightweight DTO with two properties, Currency and Exchange
<td> elements inside the table. The pattern <td.?>(.?)</td> captures the inner text of each cell while ignoring any attributes. Because the table has a predictable number of cells per row (currency name, full name, and the exchange rate), we can iterate over the matches in groups of three, creating a new Rate each time.CurrencyConverter class. Notice how we avoid any third‑party libraries; the entire implementation relies on System.Net.Http for downloading and System.Text.RegularExpressions for parsing.
Because the library is compiled into a DLL, the consuming code can reference it without pulling in unnecessary dependencies. The console program below demonstrates how to call The XML format that the Web Forms page consumes is deliberately simple: a root element The console application ExtractRates, then pass the result to an XML writer that will generate Rates.xmlGenerating the Rates.xml File on the Fly
<Rates> containing a list of <Rate> nodes, each holding a <Currency> and an <Exchange> element. The XmlTextWriter class from System.Xml makes it straightforward to write well‑formatted XML.BuildXML stitches the two pieces together. First it constructs a CurrencyConverter instance, then it calls ExtractRates with the PACIFIC URL. Once the list of rates is in memory, we open an XmlTextWriter, write the start document, add the root node, iterate over the rates, and close the writer. The resulting Rates.xml file contains all 242 entries sorted exactly as they appear on the source page, which is why we later sort them in the ASP.NET page.
Running BuildXML.exe from the command line updates Rates.xml instantly. The compile.bat script bundled with the source compiles CurrencyConverter.cs and BuildXML.cs into the DLL and the console executable. Scheduling this script to run nightly keeps the converter data fresh without any manual clicks.
Integrating the XML with an ASP.NET Web Form
The final piece is the Web Forms page that shows the converter to users. The page’s code‑behind does two main things: it loads Because the XML file is small and the dataset is held entirely in memory, the page performs the lookup quickly. The use of a Rates.xml into a DataSet, sorts the table by currency name, and binds the result to a ListBox. When the user selects a currency and enters an amount, the button click handler looks up the selected currency’s exchange rate, multiplies it by the amount, and displays the result in a Label
DataView to sort the rates demonstrates a clean separation between data retrieval and presentation logic.
The code‑behind file is the heart of the conversion logic. The Page_Load method checks IsPostBack; on the first load it pulls the XML, creates a DataView sorted by currency, and binds the view to the list box. The btnConvert_Click method fetches the selected currency from the list box, retrieves the corresponding exchange rate, and calculates the amount. A small try/catch block handles format errors so the page never crashes if the user enters a non‑numeric value.
Deploying the compiled DLL, the console executable, and the ASP.NET files to a web server creates a fully functional currency converter. Users can pick any of the 242 currencies, enter an amount, and get an instant conversion based on the latest rates pulled from the PACIFIC service. The whole system remains small and straightforward to extend; for example, you could replace the HTML scraper with a REST API call, add caching to reduce load on the external site, or even expose the XML as a public endpoint for other applications.
No comments yet. Be the first to comment!