This constructor instantiates BIP-39 (and 32) from a given mnemonic string, it first validates the string which requires converting the words to the entropy, computing its checksum and comparing it with the given checksum. The part of the code I posted is what you want (from mnemonic to entropy which can be converted to hex).
There is no public method for this since this not needed in any real world scenario, however you can copy the code and add a final line at the end using the ToBase16() extension on the entropy like string hex = entropy.ToBase16();

There is no code for it yet, I'll have to read how it works and then implement it.

Take index of each word (an integer), convert it to binary, drop the highest bits and only keep the first 11, repeat this for each word and concatenate the bits to each other. Assume 1, 2 and 3 are the bits (0 or 1) of first, second and third word respectively:
https://github.com/Autarkysoft/Denovo/blob/c5e741f76aa9318fc853b75f7a5270effebcc4ba/Src/Autarkysoft.Bitcoin/ImprovementProposals/BIP0039.cs#L121-L167

I could implement ECIES if you are stuck.

I prefer videos myself, there is a free course by Microsoft here: https://channel9.msdn.com/Series/CSharp-Fundamentals-for-Absolute-Beginners
There are paid ones on Udemy which I hear are good.
For XAML: https://docs.microsoft.com/en-us/dotnet/desktop/wpf/fundamentals/xaml?view=netdesktop-5.0
For MVVM (an architectural pattern that goes well with XAML and C# following the IoC principle): https://www.tutorialspoint.com/mvvm/index.htm
For everything else just Google or feel free to ask me, I'll answer to the best of my abilities.

If you want to become familiar with XAML (the language used in UI) you could start a WPF project and then use the designer to simply draw any item such as a button (like you'd do in MS paint) then look at the XAML code that it generates. It may seem overwhelming at first but eventually you'll just type all of that in a much cleaner and more flexible way.

Yes, it is a text-only interface similar to command line in windows. Technically this is a UI (user interface), but is not a GUI (graphical user interface).

You should be able to migrate the app to .net 5: https://docs.microsoft.com/en-us/dotnet/desktop/winforms/migration/?view=netdesktop-5.0

If this is a new project and if you are new to c# and .net I strongly suggest getting more familiar with XAML instead of winforms. The later is windows only and is old and limited while the former is a lot better and there are UI projects such as Avalonia that run on any OS.
If you want to try things out then using a console app is the easiest way to go, otherwise if you want UI install Avalonia and start from there. There is also WPF which is windows only but is ported to .net core and .net too.

Are you sure you set it to .net core 3.0 and not .net framework 3.0?
Try creating a new project like this:

If you get the "same error" saying "...into a project that targets '.NETFramework,Version=v4.7.2',..." it means you have not changed your target framework. Go to your project properties (select the project from solution explorer then from menu Project > {project name} properties) then in Application tab you should see a Target framework combobox where you can select the available frameworks. You can also manually modify your .csproj file if you are familiar with it, I'm already using the package in another project of mine targeting netcoreapp3.1 like this:
https://github.com/Coding-Enthusiast/FinderOuter/blob/b35b843987541dac24f8577342d287fd49f9dad7/Src/FinderOuter/FinderOuter.csproj#L58

No version of .net framework would work, they are kind of obsolete. There are certain improvements that were added to .net core and are present only in .net standard 2.1 which I'm taking advantage of in the library, so you have to target .net core 3.0+.

That error is because .net standard 2.1 (the library's target framework) is not compatible with the very old .net framework 4.7.2, you should upgrade to .net core 3.0+ (3.1 is LTS). See this table on MSDN.

Yes it is, you can find it in my signature too. Keep in mind that the library is in beta and you can find my versioning convention here

This is a known bug with old visual studio, it will be fixed if you upgrade to VS2019. Until then check out this SE reply which should help.

The conversion is pretty simple and straight forward. As you already know you treat the entropy (your hex) as an octet string and have to select 11 bits at a time. It appears that NBitcoin uses .net's BitArray class which I find very inefficient way of working with bits so I simply put the bits with the padding in a uint[] and then select the bits from there. You can see it here with sufficient comments.

What you want can be achieved from the following single line method:

Since fPowNoRetargeting is set to true for RegTest the nBits (target) never changes in blocks. I don't think you can change this anywhere apart from editing the code itself.

It is because you have been applying BIP-34 wrongly. The block height has to be pushed with the minimal number of bytes:
Since BIP-34 activates at block 500 on RegTest, this is ignored on all blocks from height 1 to 499 and from block height 500 it starts being enforced and the invalid push is rejected.

Technically you shouldn't even build the mnemonic itself while performing brute force and it is not stored anywhere, only a bit string for each round is constructed on the fly and discarded/changed for next step.
For instance I allocate about 300 bytes per core when recovering BIP-39 or Electrum mnemonics in FinderOuter which keeps being reused.

I believe Coinomi sorts the words alphabetically in the second window which for all intents and purposes makes it scrambled and impossible to recover due to enormous number of possible combinations to check.

It is not easy to guess the problem you are having without seeing the block header you submitted, but one similar mistake I was making when I wrote my miner in early stages was that I was changing the difficulty of the already mined block which in turn changed the hash that was found and made it incorrect.

You also keep saying "leading zeros", we don't deal with "leading zeros" at all in difficulty. Instead we deal with numbers. 05 is bigger than 03 but both have 1 leading zero, which could be another reason why your block was rejected.
You have to convert your hash to an integer in little-endian format and your target to its 256-form and then compare these two integers.

Also if you want to get rid of the complications and high difficulty of TestNet simply use RegTest instead. The difficulty is already low and you can mine the blocks in a blinking of an eye. Then submit it to your local blockchain and see if it is accepted or not.

It does not support it yet, since I'm still working on issue #9 haven't been able to add any new features.
Recovery is quite fast though (~1 second for 1 missing word), the whole thing (2048 * 24) shouldn't take more than 10 seconds if the path is hardened which I believe it is for Ledger Nano.

Most alternative nodes are either built on top of bitcoin core or are translated line-by-line from bitcoin core which means they do exactly what core does.
I sent the tx to the nodes with the following user agents, some of them rejected it but most didn't reply (same behavior as core since reject messages were removed):

If you had the IP address of any of the nodes that accept this transaction you could directly send the tx to them without needing to go through a block explorer.
P.S. The IP address shown on blockcypher (3.95.194.185) is not reachable.

I dug around in the code again today and I believe this is where the paths are set:
https://github.com/spesmilo/electrum/blob/1c07777e135d28fffa157019f90ccdaa002b614e/electrum/keystore.py#L984-L1003

It is not testing your wordlist. Tools such as travis-ci are "hosted continuous integration service" which are automatically called each time there is a new commit (or if it is set, a new pull request) and they run a script (the .yml file) that is sent to their server on each call to run. The script is usually defined to build and run tests but it can be anything.
For example I use it to build my projects on Linux-x64 and also run all my tests there; it helps catch any problems with the build or any bugs in the code that tests can catch.
In case of bips they are running this script that performs some basic checks.

The derivation_and_script_type_dialog seems to be called when the wallet is being created using a hardware wallet not from an Electrum seed phrase. That is why path for eg. 'standard', 'legacy (p2pkh)' is being set to m/44'/0'/0' and I know for a fact that it is m/0 for Electrum mnemonics.