evoscan .net framework??
Thread Starter
Joined: Apr 2003
Posts: 1,580
Likes: 0
From: Houston, TX
evoscan .net framework??
says I need version 1.1.4322 or somethin like that... can someone get me w/ a link please... I've fiddled around the stupid pages that it sends you to and downloaded 2.0... didn't work. Then looked for the 1.1.4322 in specific and only found several 1.1's... no specifics. I don't even know what the heck a .net framework is! lol. Help me out here. (and why isn't .net 2.0 backwards compatable so that evoscan works w/ it?)
Ya know, I never really understood why its not backward compatible either..
You should be able to search Microsoft or Download.com.. or use windows Update to get the .net packages..
I usually develop to the lowest common denominator, but thanks to .NET every time I use the older versions of stuff to keep the best compatibility, it breaks when someone only has the newest (and most will have it if they use windows update)
Just look for the most recent V1.1.xxxx build and install that, it should work fine..
You should be able to search Microsoft or Download.com.. or use windows Update to get the .net packages..
I usually develop to the lowest common denominator, but thanks to .NET every time I use the older versions of stuff to keep the best compatibility, it breaks when someone only has the newest (and most will have it if they use windows update)
Just look for the most recent V1.1.xxxx build and install that, it should work fine..
I do think that the author of Evoscan should really use the most current .NET libraries, but there were some changes to the communication routines so its possible it was necessary for him to do that.
He really should be embedding .NET into his app, offering a full install with the .net library in the package, and then just a runtime install package (small file download)
He really should be embedding .NET into his app, offering a full install with the .net library in the package, and then just a runtime install package (small file download)
Originally Posted by MalibuJack
I do think that the author of Evoscan should really use the most current .NET libraries, but there were some changes to the communication routines so its possible it was necessary for him to do that.
He really should be embedding .NET into his app, offering a full install with the .net library in the package, and then just a runtime install package (small file download)
He really should be embedding .NET into his app, offering a full install with the .net library in the package, and then just a runtime install package (small file download)
.Net v1.1 only has the following requirements: Windows 2000; Windows 98; Windows 98 Second Edition; Windows ME; Windows NT; Windows Server 2003 Service Pack 1 for Itanium-based Systems; Windows Server 2003 x64 editions; Windows XP; Windows XP Professional x64 Edition
.Net v2.0 requires: Windows 2000 Service Pack 3; Windows 98; Windows 98 Second Edition; Windows ME; Windows Server 2003; Windows XP Service Pack 2
the correct links for each version are
v2.0
http://www.microsoft.com/downloads/d...displaylang=en
v1.1
http://www.microsoft.com/downloads/d...n#Requirements
Originally Posted by chrisw
most developers target v1.1 for maximum coverage. At the very minimum, he should put a link to a place where it can be downloaded.
.Net v1.1 only has the following requirements: Windows 2000; Windows 98; Windows 98 Second Edition; Windows ME; Windows NT; Windows Server 2003 Service Pack 1 for Itanium-based Systems; Windows Server 2003 x64 editions; Windows XP; Windows XP Professional x64 Edition
.Net v2.0 requires: Windows 2000 Service Pack 3; Windows 98; Windows 98 Second Edition; Windows ME; Windows Server 2003; Windows XP Service Pack 2
the correct links for each version are
v2.0
http://www.microsoft.com/downloads/d...displaylang=en
v1.1
http://www.microsoft.com/downloads/d...n#Requirements
.Net v1.1 only has the following requirements: Windows 2000; Windows 98; Windows 98 Second Edition; Windows ME; Windows NT; Windows Server 2003 Service Pack 1 for Itanium-based Systems; Windows Server 2003 x64 editions; Windows XP; Windows XP Professional x64 Edition
.Net v2.0 requires: Windows 2000 Service Pack 3; Windows 98; Windows 98 Second Edition; Windows ME; Windows Server 2003; Windows XP Service Pack 2
the correct links for each version are
v2.0
http://www.microsoft.com/downloads/d...displaylang=en
v1.1
http://www.microsoft.com/downloads/d...n#Requirements
Plus, people who are updating their windows XP on a regular basis probably have .NET 2.0 installed (and 1.0 and 1.1 is likely too)
I used to always develop to for the masses, unfortunately with .NET, it lead to more support headaches then its worth, and 2.0 has been out long enough that many of the people who have any .NET variant on their system would have gotten the 2.0 as one of their updates.
The reality is at one time programming for the least common denominator was worthwhile.. Now its inconvenient and usually impractical. From a social standpoint, people with older OS's and using unsupported or out of support versions of windows don't make good customers. I take this from experience.. And the x64 stuff just isn't in wide enough use yet for these types of programs. (I do work with Server specific apps that are x64 and Itanium targetted)
I would say if I was still working as a professional programmer I would probably feel differently and be in an environment where it was easier to develop and support. But as an individual, I can understand that the author chose his platform and libraries for HIS convenience, the fact that it has use to others in the community are a bonus for him.
I do think EvoScan is a good program, but its starting to go in a direction that I don't think is useful for its original purpose.. I'd much rather have a simple logger that I had sourcecode to that I can modify for my specific needs, which was what this originally promised, than pay extra for a bunch of gages I won't ever use.
I probably would have used a different programming platform than vb.NET anyway, first because it has too many library dependencies I don't like dealing with, second because its the kind of code that can not currently be crosscompiled (unless there is any confirmation that Visual studio and the .NET libraries have had Linux support added
) I usually use Delphi, and an older version at that, for apps like this. As long as the calls you make aren't hardware dependent or OS Specific, you can get the code to run under almost any OS now.
Plus .NET assemblies are easy to disassemble into source code which you need to add obfuscation tools, or compile the .NET into a PE with a third party tool, which sometimes breaks the app depending how its code.
The .Net runtime will always have to change a little going forward. Method's become deprecated, methods get changed etc (JVM does the same thing...I dunno if you have ever compiled old Java code on a new JVM but do it with a -deprecate and see how much methods on the code are about to be tossed...well if it compiles
). I mean its quite possible that in a lot of cases even though the program is compiled with the wrong version of .Net that it would probably work with a different version. But unfortunately MS can't afford to take that risk and hence why if it don't match that error is thrown up and the proggie dies.
That being said, if evoscan is written using just core CLR stuff..there is the MONO project:
http://www.mono-project.com/
Which is making good progress and has come a long way from whence it started. Once its just core stuff it shouldn't be too hard to port it over there as necessary.
Obfuscation with any JIT language is always going to be weak though. All it does is make the thing harder to read...with enough patience you can still figure out whats going on. But considering if you go this route you'd want a good obsfucator those are quite pricey to...and not sure how much they really gain you anyway.
Fully compiled proggies don't stop you from doing that either...if you read flat assembly its all irrelevant right?
). I mean its quite possible that in a lot of cases even though the program is compiled with the wrong version of .Net that it would probably work with a different version. But unfortunately MS can't afford to take that risk and hence why if it don't match that error is thrown up and the proggie dies.That being said, if evoscan is written using just core CLR stuff..there is the MONO project:
http://www.mono-project.com/
Which is making good progress and has come a long way from whence it started. Once its just core stuff it shouldn't be too hard to port it over there as necessary.
Obfuscation with any JIT language is always going to be weak though. All it does is make the thing harder to read...with enough patience you can still figure out whats going on. But considering if you go this route you'd want a good obsfucator those are quite pricey to...and not sure how much they really gain you anyway.
Fully compiled proggies don't stop you from doing that either...if you read flat assembly its all irrelevant right?
Thread Starter
Joined: Apr 2003
Posts: 1,580
Likes: 0
From: Houston, TX
Originally Posted by chrisw
Trending Topics
Originally Posted by MalibuJack
I do think that the author of Evoscan should really use the most current .NET libraries, but there were some changes to the communication routines so its possible it was necessary for him to do that.
He really should be embedding .NET into his app, offering a full install with the .net library in the package, and then just a runtime install package (small file download)
He really should be embedding .NET into his app, offering a full install with the .net library in the package, and then just a runtime install package (small file download)
Yeah I will try and upgrade it to .net 2.0 for the Full Release of EvoScan v1.0 and it will include OpenPort and EvoScan Cable drivers along with the .net framework
Originally Posted by honki24
just downloaded this one, hope it works.
I will put this info on the download page, so it gets read.
Thread
Thread Starter
Forum
Replies
Last Post









