On the target machine I have not changed anything except the attempt to install the net framework runtime 4.6.1. How fair it is of course. But since there is 4.8 on the client, the setup stops saying that there is no point in installing 4.6.1. I don't understand, however, for what reason if the software works very well on the machine I develop, on other clients it gives errors. I was wondering if it was appropriate to install the NF 4.6.1 Developer Kit.
Thanks so much
There is no point in trying to guess what the problem is. You need to find out exactly what is causing the failures. You cannot make changes to the system until you know exactly what the problem is. Also, the .NET frameworks are forward compatible (mostly), so an application built on 4.6.1 should run on 4.8.
I would like to expose a problem, I hope you can help me.
I have a fully functional exe on the machine where it was developed, but malfunctioning with Debug JIT message series on normal W10 64 clients with latest updates. Going to check the .Net Framework versions installed on the clients, I find 4.8.
What is the exception logged? "FileNotFound"?
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
I could tell you that you are right, but the point is this: why shouldn't I trust an obfuscator especially those with paid license?
The obfuscators issue is a real dilemma. I've tried dozens of them, free and licensed, but none and again none have ever worked 100%. I thought I had found one for a fee but with the possibility of testing it. This is what it produced: A software that only works as a facade, but when it comes to handling large amounts of code, libraries and functions in general, IT SHALL FAILED! Gentlemen let's face it: obfuscators for .NET don't work. Or at least they don't work for large amounts of code to manage. End.
Thanks a lot to everyone.
You don't run the obfuscator on every .exe and .dll (assemblies) in your app. You only run it on the assemblies you want to protect, but only if those assemblies can even have the obfuscator run on them. If not, you have to consider moving the code that's making the obfuscated version fail to another assembly.
I understand very good that you prefer VB instead of C# - for me it's the same - but I have learned how to make VB-Code from C#-Code. The easiest way is to use the (FREE) Telerik-Converter in the Internet. But Basicly : both languages are using the .Net-Framework and there is no real difference between the use of a Framework-method with C# or VB, If you once realize this you don't have much problems with the code-conversion ...
Give it a try ...