This is just a code snippet here, I don't think OP maintains it. I wouldn't expect an update.
You should try using active projects that can be found on GitHub (https://github.com/search?q=bitcoin+language%3Ac%23).

Feel free to take a look at my project Bitcoin.Net, it is in beta.
Examples of creating some addresses:
https://github.com/Autarkysoft/Denovo/blob/642103ca8e7693c02c1867202c3cc1a8fa31ab50/Src/Autarkysoft.Bitcoin/Encoders/Address.cs

I have had a windows-only desktop app for a long time now and a while ago I decided to expand to multiple platforms including Android but got busy doing a million other things that couldn't start the journey and while the project I currently work on would eventually have all those options too but it is at least a year away from being complete.

If you are familiar with .Net and C# you could use my code as an starting point. Since the code is very loosely coupled I don't think the migration is going to be that hard, these would be the steps:
- Change the target framework to .Net core (v 2.2 or better yet use the latest v 3.1)
- Swap all the views with Xamarin forms which are using pretty similar XAML syntax so that conversion should also be easier
- Add a new Balance and Price APIs to support LTC. This may be harder since it would require changing the wallet file and how addresses are stored to figure out which is which!

That's in my TODO list (already have 1 issue that turned into a PR for a tiny fix), but first I'll have to go through all tests and familiarize myself more with core's code. Another issue is core being in c++ and me not knowing anything about the language.

I've traced it all the way to this line:
https://github.com/bitcoin/bitcoin/blob/24f70290642c9c5108d3dc62dbe055f5d1bcff9d/src/script/script.cpp#L278
that is called by GetSigOpCount a bunch of lines above this which is called by GetTransactionSigOpCost from tx_verify.cpp
And to me it looks like a broken script such as
is counted as 20 SigOps. Is my interpretation correct? (Obviously OP_DIV is disabled and 0xff is not an OP at all).

PS. SigOpCount tests of core needs a lot more cases, right now they seem to only test the elementary standard scripts only.

Short answer is it's impossible to recover this private key since the number of possible keys to check is enormous.

You'll need to construct and compute 1,449*10¹⁸ hashes, in comparison current total bitcoin hashrate (the entire bitcoin mining power) is about 100*10¹⁸ and that is hash of a rather fixed input that doesn't have the same additional computation step on each round. That means even if you had all the ASICs operating today and had a way of modifying them to compute the hash you want, you still wouldn't even be able to go through 5% of the cases.

On top of that since the number of missing characters is huge, the number of correct results is going to be large and in order to go through all of them there is another bottleneck which is computation of public key and if needed the address to compare with an input (FinderOuter doesn't do that in current version).

---

PS. I don't want to get your hopes up but there may be a small chance if you have your public key. I still haven't looked into the algorithm (Pollard's kangaroo) but it may be possible if we could get a manageable range of keys from what you already have.

---

---

Merging 2 consecutive comments

Assuming the "txn file" was created by Electrum and the transaction is unsigned you may want to look here: https://bitcointalk.org/index.php?topic=5082785.0
There are both privacy and security concerns:
Privacy: you are revealing your entire list of past, present and future public keys (hence addresses).
Security: revealing a single private key from that wallet some day will reveal all your private keys.

Version 0.2.0 released.

• New BIP: Passphrase protected private key (BIP-38)
• New hash algorithm: Murmur3
• Improve Address and Signature classes
• Various code improvements and additional tests

Version 0.2.0 is released.
https://github.com/Coding-Enthusiast/FinderOuter/releases/tag/v0.2.0.0
See changelog for more details.
Most notable changes are:
- Replacing backend with the well tested Bitcoin.Net library which improves performance and fixes some bugs
- Added 2 new features: recovering Base-58 addresses and BIP-38 encrypted keys
- Fix some bugs including a bug that prevented the FinderOuter from running on Ubuntu 20

It is marked as withdrawn. I haven't seen any project that uses this proposal. If I can find any, I would implement it.

Another major usage is for physical backups and cold storage where users print their keys or master keys. Those backups also must be encrypted for extra security. BIP38 comes in here but there is no standard for encrypting extended keys or mnemonics which is what nearly all wallets use these days.

That can't be categorized as encryption though.

That is in my to-do list. Hopefully I can implement that too by the end of this year.

I'm implementing encryption proposals in Bitcoin.Net but I've only been able to find BIP38. So I was wondering if there are anything else (doesn't have to be a BIP), maybe something that covers encryption used for mnemonics.

If you want to focus on bitcoin then there really isn't that much to learn about P2P protocol. It has two pretty simple parts:
- the handling of sockets which can be done by the framework or any library out there (eg. since you mentioned VB, the .Net framework/core has TCP clients that is a wrapper around sockets and make it easy to use)
- parsing, handling and responding to received message buffers

If you want to learn more and don't use wrappers or libraries and focus on Sockets directly then you'll have to look elsewhere since it is not bitcoin related anymore. Start from creating a server-less messenger app. I see on your GitHub account you have a similar project, work on that first.

The important topics in bitcoin are 1) blockchain (blocks, transactions and scripts) and 2) cryptography (hash algorithms, elliptic curve cryptography)

As I'll be adding some experimental ideas to Bitcoin.Net library I'll also share them here with more details and rationals for discussion.
The first one is replacing Base-58 with Bech-32 encoding
Direct link to the code: https://github.com/Autarkysoft/Denovo/blob/master/Src/Autarkysoft.Bitcoin/Experimental/Bech32PrivateKey.cs

Here is an example with a random key:

Note that key is encoded the same way an address would be encoded (version byte is added separately as a 5-bit value instead of 8-bit).

If you know of any work done similar to this idea please post it here.
I'm addressing some of the problems with current encoding of private keys: 

1) Using Bech32 encoding instead of Base58 
While writing a private key recovery tool I've felt how hard it is to come up with an optimized algorithm to recover a key that is missing a couple of characters (eg. a damaged paper wallet). That is not true with Bech32 being a multiply of base-2 algorithm is inherently faster, and the checksum is not a bottleneck since it is not a hash algorithm. Bech32 also has the benefit of having error detection.   

2) Script (address) type
Currently when a user imports/sweeps a private key in a wallet client, that client either has to explicitly ask user for the script type (like Electrum) which means user is exposed to complications and has to be familiar with script types; or the wallet has to construct all script types and scan the blockchain for all of them (like bitcoin core) which adds more burden on the client. 
If the encoding included a script type that becomes so much easier. 

3) Locktime!
Another burden on both clients and users (specially full node users) is the time consuming need for a re-scan of the entire blockchain to find the historical transactions that belong to an imported key. 
A timestamp can make that process a lot shorter. 
Using locktime (similar to last 4 bytes of any transaction) the key string (aka WIF) could include either a block height or a date-time value of when the key was created. 

I created a desktop app a couple of years ago to do this, it has been supporting bech32 addresses as soon as I found a block explorer API that supported it (Jan 2018): https://bitcointalk.org/index.php?topic=1616888.0

I guess because I usually expect certain things to be strict specially when it comes to evaluating scripts.
This is not the first time I'm surprised by such rules though.

Basically this test vector: https://github.com/bitcoin/bitcoin/blob/b6a5dc90bfd4640cf9f914e59bf8e21cd265b51e/src/test/data/tx_valid.json#L185-L188

It is spending a P2SH output with the redeem script of it being:
OP_2 <invalid_pub><Pub><Pub> OP_3 OP_CheckMultiSig
The first push which is supposed to be a public key is an invalid public key (it is a DER encoded signature) and despite that OP_CheckMultiSig passes successfully!
Is this another bug at protocol level? Also is it the same for SegWit scripts?

Did you try to build the project from source code and faced difficulties or did you try to run the compiled version (the 27 MB file called v0.1.2.0.zip) and had problems?
And please mention the difficulties you encountered explicitly so that I could improve the project and make things easier.

Tiny version update (V. 3.2.1). Fixed some bugs with the APIs and removed the dead ones. Now we have only two and both support Bech32 addresses.

PS. I may continue back-porting features to this project but my focus is going to be on my new project, Denovo, which would eventually be a much more advanced version of this project.