This is a code-review according to request on Kodapor; https://www.facebook.com/groups/utvecklare.stockholm/permalink/1692522717463460/

The opinions below are mine alone and any action is at the discretion of the reader. The review is what you could expect as a professional developer in a team I mentor.

Project structure

I would consider moving sample files to a separate folder to keep the root folder as possible.

Git

It is common practice to call the default branch master in git, not dev. By following accepted standards it is easier for new developers to find and understand your code.

Code review

Command line tools are expected to have parameters for input and output file names, or read from stdin and write to stdout directly. To require the user to execute the program from the same folder as the input files, and require specific filenames makes the program less useful.

Command line tools are expected to end without the user pressing a key. That way one output can easily be piped to the next tools input.

It is good practice not to let applications end with a crash. After successfully logging in the outer catch-block you should end the program with an exit-code != 0, i.e. Environment.Exit(1); instead of throw ex;.

In case you actually need to throw an exception from inside a catch-block, you should never rethrow with throw ex;, since that effectively throws away the original stackframes. Rather, throw the existing exception with just throw;, or throw a new exception with something like throw new ApplicationException('oops!', ex);. See https://exceptionalcode.wordpress.com/2010/04/13/net-exceptions-throw-ex-is-evil-but-throw-is-not-that-innocent/

There is really no need to cast strings to string by adding .ToString() at the end. This notion makes the code harder to read and me as a reader to think there is something going on that I don't understand.

Modularize yor logic a lot more. You may want to read up on the Single Responsibility Principle, which is the first part of SOLID; https://en.wikipedia.org/wiki/Single_responsibility_principle

• Move reading of json-objects into its own class. Use filename as a method parameter. Consider creating one generic method for reading both files.

• Create a new class for writing objects to xml. Both filename and actual object to serialize should be method paratmers - unless writing to stdout instead...

You should avoid manually serializing xml with XmlWriter. XmlWriter is fast but very verbose to write; it becomes error prone, hard to read and complicated to extend in the future. It is great for writing large amounts of data to a stream without keeping the entire source in memory though.

Instead of XmlWriter, consider assembling all data to be serialized in an outer object and use XmlSerializer (System.Xml.Serialization.XmlSerializer) to write to xml. The file format is then declared like how you already declared how the json files are deserialized.

Final thoughts

I think it is better to leave out fields like clearingNumber from the xml output instead of writing artificial strings like N/A. Those artificial strings makes it harder to deserialize correctly and will likely come back and bite you one day...