That's good to hear you at least found a version to work for you. I'm not sure why this would be the case. However on Windows there has been a (LimeWire) history of something like this happening where one version works better than another.

The only thing that is not working properly is either your UPnP or port forwarding or you have not given a Windows firewall exception, however this rule should already exist from your previous version. "You are behind a firewall and support firewall transfers." You will get better search and overall performance if you can instead get it to be like mine "You are not behind a firewall"; your WireShare would be able to join the DHT for superior searches and communicate via UDP which is where most communication between programs happens. 70% dropped messages via your connected ultrapeers is notably high. There will also be some other firewalled hosts you will not be successful for downloading from when your WireShare is firewalled.

I suspect your port forwarding might have an error somewhere. Does the port forwarded match with WireShare's connection port? Did you set up a static ip address? Did you set the port forward rule to your computer and not accidentally set it to another device on your LAN? (I've made this error a few times, mainly because my multiple Windows & Linux have obscure ID's)

I removed the previous exceptions to start fresh, probably that's the reason. The screenshot shows the window after starting wireshare right after installation, not adding anything to firewall exception.
However, I found this while looking at Windows 10's firewall exception list from
Control Panel\System and Security\Windows Defender Firewall\Allowed apps
Note this is not the advanced settings page where all the rules are showing.
Also a question here - do I have to allow for both Outgoing and Incoming connections? Or just outgoing?

EDIT: The checkbox is left for PRIVATE and right for PUBLIC. Only private is checked.

AFAIK you don't need Public, even if I did enable it for WSHR. Inbound Rules are sufficient. Check to be sure there's two for WireShare; one will be for UDP and the other for TCP as can be seen in the rule's properties, Protocols & Ports. It will also say it applies to all ports which is handy if you choose to change the port.

Alright, I'll set it up.
EDIT: I must be doing something wrong...
I checked the inbound rules - there were 2, one for each protocol, UDP and TCP. So I set an outbound rule, for any protocol - still behind a firewall.
I deleted all the rules and created a new one, inbound, any protocol and I'm still behind a firewall. The only firewall running is Window's.

EDIT2: I added manual port forwarding on the router, still shows behind firewall.
I also tried running WSHR as admin, no luck.

EDIT3: So, the issue is not Window's firewall, I turned it off just for testing purposes and it still shows me behind a firewall...

EDIT4: Tried WSHR 5.6.5 - working (same issue though, behind firewall)
WSHR 5.6.6 - still not working xD
I think the issue is the installer - the 5.6.6. installer has the shield icon from Windows while the 5.6.5 and previous don't. Even though I did run the installer as administrator. But I might be wrong about this assumption.

May I ask what connection equipment you are using? Brand and model router, etc.

Sorry, been away for a couple of hours.
The router is TP-Link TL-WR940N

According to https://portforward.com/tp-link/ that model is not listed but the others appear similar to each other referring to the process as Virtual Server. Double-check the setting to be sure it includes both UDP and TCP or All (protocols.)

Have you checked the UPnP section in the router's control panel to be sure it's enabled? You can switch WSHR between either UPnP and Manual PF to see if either works to fix the firewalling issue.

Are you certain you set up a static address?
https://portforward.com/networking/s...windows-10.htm the first three segments of the address need to match the router's address, but the last number must be different. In your case it looks like your present internal address is 192.168.0.104 and the router's address is 192.168.0.1 which looks fine. Without a static address, if there is more than one device on the LAN utilising the router, then each time you reboot your computer you can potentially get a different address and the port forward rule no longer works. Port forward rules are set to specific addresses.

Do you use any other 3rd party security software such as firewall or anything that might be affecting WSHR's performance? At least your WSHR can connect, but something is probably blocking the incoming UDP messages.

I don't use any 3rd party software that might block WSHR.
I double checked the UPnP and it has 2 forwards for both protocols.
The IP is correct, it doesn't change....
I think the router has a built in firewall...I might try to disable that and see if that works...but isn't the port forwarding made for that situation specifically?

EDIT: I disabled the SPI Firewall in the router's settings but I'm still showing behind a firewall....now it's starting to get frustrating because I don't know what can cause this...
I disabled Windows Firewall....I disabled router firewall and I'm still behind one? what the hell.

Lets hope my question is easier than evils ; is wireshare 5.6.6 compatible with my hp windows 10 desktop computer .

I recall having a firewall issue with Win 10 after Win OS update earlier last year. I cannot recall what I did to fix it though. It is looking like a Win 10 issue with the firewalling.

My ignorance: I found this note about allowing apps through Win 10 firewall online:
"Select Private if want the app to communicate in the local network. Or select Public when the app needs to communicate through the firewall on the internet. You can select both options as needed."
My firewall rules are Private & Public. However since you tried disabling the firewall, this is obviously not the issue.

No reason why it should not be compatible with any Win 10 system. I tested WSHR out on Win 10 with both failure and success as mentioned in post #19. Though there's apparently different Win 10 variations. However evil4ever's experience is 5.6.6 would not connect. Different hardware, Win 10 variations including 32 & 64-bit, & desktop/laptop, and personally customised variations between everybody's system can sometimes mean different results for running particular versions of software.