dotnet 2.0 final
- Thread starter karlotta
- Start date
I just want to repeat what I wrote in another thread regarding Net 2.0, or .Net in general.
I was excited and installed .Net 2.0 "for fun" and even made a manual restore point to revert back to should my "experimentation" lead to trouble. I had .Net 1.1 + hotfix already installed and installed .Net over/alongside it. All was well. However, I wanted to test if .Net applications would break (nHancer, in this case) if only 1.1 was present. I uninstalled 1.1 and sure enough it broke. I am not sure if it was only the application that broke for 1.1 (it requires 1.1, or so it says) or all of .Net because I had no other .Net 2.0 specific app test with. So, I decided to roll back using System Restore. This is where I ran into trouble.
I managed to get myself in a situation where the system thought 1.1+hotfix was installed (rolled back), but it didn't work. I could not uninstall or reinstall/repair .Net 1.1 because the application was on a network drive that was not attached (I think this is due to having installed 1.1 from Windows Update). So, I had to go through a manual procedure of deleting files and altering the system registry to make my beloved little PC understand that .Net was, in fact, not installed and needed to be.
I now have .Net 1.1 + hotfix back and working. I have not bothered reinstalling 2.0 because I have no application that needs it. However, the system seemed quite happy having both 1.1 and 2.0 installed together. That never seemed to be a problem.
Just a word of caution for those looking to experiment. There are two or three MS KB articles related to this problem and some MSDN blog entries (probably by the person who created the KB article). I don't have the URLs handy at the moment, but know that they are out there should you run into this problem. However, the actual fix is a bit beyond either article and you have to use them together with a bit of simple thinking applied. Nothing too strenuous once you figure it out, but it could cause a lot of pain if you are not comfortable with such operations or not authorized to make them. Play safe.
I was excited and installed .Net 2.0 "for fun" and even made a manual restore point to revert back to should my "experimentation" lead to trouble. I had .Net 1.1 + hotfix already installed and installed .Net over/alongside it. All was well. However, I wanted to test if .Net applications would break (nHancer, in this case) if only 1.1 was present. I uninstalled 1.1 and sure enough it broke. I am not sure if it was only the application that broke for 1.1 (it requires 1.1, or so it says) or all of .Net because I had no other .Net 2.0 specific app test with. So, I decided to roll back using System Restore. This is where I ran into trouble.
I managed to get myself in a situation where the system thought 1.1+hotfix was installed (rolled back), but it didn't work. I could not uninstall or reinstall/repair .Net 1.1 because the application was on a network drive that was not attached (I think this is due to having installed 1.1 from Windows Update). So, I had to go through a manual procedure of deleting files and altering the system registry to make my beloved little PC understand that .Net was, in fact, not installed and needed to be.
I now have .Net 1.1 + hotfix back and working. I have not bothered reinstalling 2.0 because I have no application that needs it. However, the system seemed quite happy having both 1.1 and 2.0 installed together. That never seemed to be a problem.
Just a word of caution for those looking to experiment. There are two or three MS KB articles related to this problem and some MSDN blog entries (probably by the person who created the KB article). I don't have the URLs handy at the moment, but know that they are out there should you run into this problem. However, the actual fix is a bit beyond either article and you have to use them together with a bit of simple thinking applied. Nothing too strenuous once you figure it out, but it could cause a lot of pain if you are not comfortable with such operations or not authorized to make them. Play safe.
I think JAVA is great, but there have been far more security updates and fixes to Java than to .NET in the same period. As for documentation I'd say MSDN Library and http://msdn.microsoft.com/netframework/ are pretty damned detail, given that every class, property and method is covered in massive detail, with loads of online tutorials. I would say, though, that Java has a better community surrounding it.Saem said:
Diplo said:
Umm, that's a good thing! Assuming that MS and Sun put out roughly the same quality software, Sun has fixed more bugs. Honestly, I think this entire, x program has had more updates/fixes therefore it's buggy, reasoning to be nothing short of silly -- sorry, I'm seriously allergic to that line of thinking. I think it makes more sense that the company/organisation has been far more diligent with fixing things, they have a better quality product.
At the end of the day, I think Sun puts out better code but that's my subjective BS based on my intuition. Yeah, I realise the nature of the fixes, response time and possibly
The same view is hoisted upon others as people try to argue that firefox is more insecure because it has more fixes against it. Heh, I could be wrong headed, but doesn't that sound daft?
Or, it could equally mean that there were simply less bugs to fix. The fact is, you don't know. However, arguing that more fixes means less bugs is clearly a fallacy. The best you can say is that company Y fixed more bugs than company X, but that is pre-supposing that both products have the exact same number of bugs and therefore this is a good thing. But equally it could simply mean there are just more bugs, period.Saem said:
.NET is an interesting API, but I think in many ways it missed the target completely.
For example, if you want to handle keyboard input, you need to use the Keys enum. It contains many things, and there are many associated methods and properties, except... the actual char you would want to put on the screen. You have to convert the value first to an int32, then do your calculations, then convert it to a char and then to a string. I want my char back! I really don't like functions that consist for the most part of conversions!
Keys.A.ToString() will give you "65", so if you would want to print, say, a number typed on the numeric pad (myKey), you need to do:
Convert.ToChar(Convert.ToInt32(myKey) - Convert.ToInt32(Keys.Numeric0) + Convert.ToInt32(Keys.D0)).ToString()
to be able to print it on the screen...
Edit: For another example: try to write a file to LPT1:. If you want to do it by the books, you cannot, because the only thing associated with that is a CGI device to print stuff to a printer (a printer driver). You're specially forbidden to treat it as any stream.
For example, if you want to handle keyboard input, you need to use the Keys enum. It contains many things, and there are many associated methods and properties, except... the actual char you would want to put on the screen. You have to convert the value first to an int32, then do your calculations, then convert it to a char and then to a string. I want my char back! I really don't like functions that consist for the most part of conversions!
Keys.A.ToString() will give you "65", so if you would want to print, say, a number typed on the numeric pad (myKey), you need to do:
Convert.ToChar(Convert.ToInt32(myKey) - Convert.ToInt32(Keys.Numeric0) + Convert.ToInt32(Keys.D0)).ToString()
to be able to print it on the screen...
Edit: For another example: try to write a file to LPT1:. If you want to do it by the books, you cannot, because the only thing associated with that is a CGI device to print stuff to a printer (a printer driver). You're specially forbidden to treat it as any stream.
Last edited by a moderator:
Why not just do this?DiGuru said:
Code:
protected override void OnKeyDown(KeyEventArgs keyEvent)
{
string keyval = keyEvent.KeyCode.ToString();
}Besides, 99% of the time when you are reading keyboard input in an app you simply just want to do something when a key is pressed, not echo it's value. Methinks you are being a touch pedantic
I can't test that now, but I'm pretty sure that will give you the name of the thing. Like, Keys.Numpad8.ToString() gives "Numpad8", not "8".Diplo said:
So, depending, converting the value of Keys.Numpad8 can result in:
104
"104"
#8
"Numpad8"
and probably some other values.
Besides, 99% of the time when you are reading keyboard input in an app you simply just want to do something when a key is pressed, not echo it's value. Methinks you are being a touch pedantic
Perhaps. But then again, I like things simple. That every object now has a ToString method (even the ones where that makes no sense) with multiple results can be very nice, but I really want to be able to use the simple things, like plain chars without having to dig through multiple objects to find them, as well. KISS. I don't want endless routines cascading through many objects when I want to do a simple thing.
Last edited by a moderator:
Yes, it will, since you need to be able to differentiate between numpad keys and normal numeric keys. One simpler way to get just the number as a string would be:DiGuru said:
Code:
Keys.Numpad8.ToString().Replace("Numpad","")I've got this .NET 1.1 application running on my laptop, but when I install it on the computer from the client, it throws up an exception right away: System.TypeInitialization exception.
This happens on the very first line of the program (checked it with remote debugging), at which point my largest class (that actually runs all parts of the program) is initialized. The first line of the constructor isn't executed, so it looks like I'm missing some component that is referenced in my program.
Does anyone knows of a good way to track what component(s) is (are) missing and need to be installed?
Btw, it uses a National Instruments DAQmx card, attached to various machines, so it's pretty hard to debug. But all the DAQmx stuff is installed, so that shouldn't be a problem.
I'm not very used to these kind of problems, with Delphi all my executables are fully self-contained.
This happens on the very first line of the program (checked it with remote debugging), at which point my largest class (that actually runs all parts of the program) is initialized. The first line of the constructor isn't executed, so it looks like I'm missing some component that is referenced in my program.
Does anyone knows of a good way to track what component(s) is (are) missing and need to be installed?
Btw, it uses a National Instruments DAQmx card, attached to various machines, so it's pretty hard to debug. But all the DAQmx stuff is installed, so that shouldn't be a problem.
I'm not very used to these kind of problems, with Delphi all my executables are fully self-contained.
Diplo said:
Well, yes and no. I do agree that it catches most bugs and is a very good thing. I like Delphi best, which is very strict. But that allows you to get to the actual data directly as well.
I think the main problem is, that almost everything is generalized and works with plain object types (variants) or abstract enums. The positive thing about that, is that all comparable objects have the same properties and methods, so you can guess how they are called and how they function.
But at the same time, most containers accept any kind of data. It's (as an example) pretty hard to make a list (like the Delphi TStringList), with many properties and methods, that only accepts strings and still uses the .NET classes. And so the general methods support any data, and it depends on the context which specific method from what class is actually used. Which is again a form of automatic type casting.
Last edited by a moderator:
DiGuru said:
Char has an explicit cast operator to and from the Keys enum from memory.. so (char)e.KeyCode should be '8' if memory serves.
hence C++.net
List<string> ?
when making a generic (template) you can be even more specific than that.. such as only allowing class's implementing X interface, etc. .NET generics are very powerful things.
that is usually casued by something going amiss in a static class constructor. Take a look at the InnerException (which shoud definitly be set to something)
.Net has extensive xml-based in-code documentation (even forcable by the compiler) out of the box, all integrated into intellisense, etc. Java has had many competing tools that do the same thing such as xdoclet... but none really compare to the native xml doc that .net languages support (esecially in terms of ease of use). The quality of the documentation in the .net class library I feel is far superior to that of java. Also .net documentation integrates with IDE's better.
For a comparison...
the String class:
java:
http://java.sun.com/j2se/1.3/docs/api/java/lang/String.html
.NET:
http://msdn2.microsoft.com/en-us/library/System.String
and
http://msdn2.microsoft.com/en-us/library/system.string_members
compare something simple, for example the String(Char[]) constructors in each... There isn't really any contest, 2 sentences in java, about 3 pages in msdn...
A few things I want to say about .net compared to java...
Just remember, when comparing java to .net, java is a language with a class library. .NET is a platform that includes a class library (which in my opinion is superior).
Many people assume .NET is microsofts attempt to clone java. Well, no, not true. See it turns out Microsoft started the design of .NET approximatly 15 years ago. Hang on, java has been around about 12 years... hmm..
C# is the .net language most comparable to java (ignoring J#), although I'd say it almost has more in common with C++, and in my opinion it trumps java in every way. There is still an *awful* lot that the .net platform can do that C# does not expose (functional programming and SQL-like querys for example will arrive in C# 3.0). Taken on top of things like properties, delegates, good generics, attributes, etc, and C#/.net already useful-feature-wise has a significant advantage over java.
When directly comparing the java and .net libraries, it's my feeling that java is bloated and poorly designed, it's been a get-it-out, patch-it-later attitude. Where .NET has very strict style, naming and general design guidelines and quality control that get strictly inforced. Java I feel is quite loose in comparison.
The core java class lib is ok, but it's definitly not wonderful. There are far too many problems with general contradiction of the conventions, and also a somewhat unplanned feel. The simplest example I can think of is trying to write text to the console. This originally required 4 objects in Java (although with current versions this is less, as they have added more 'simplifing' objects - ie more bloat). The collections set, while now adequate, has been pretty poor the entire time. The original java collections were flat out crap, the full set of java collections in 1.2 (?) were definitly extensive, but their design was shocking. The stack class was just a vector with push/pop methods added (ie, stack extends vector). Granted things have changed (and there are now *far* too many collection related classes/interfaces), but still, it's taken them 10+ years and still java does not compare to .net generic collections (which are brand new). - imo java generics are appauling but thats another matter.
Don't even get me started on Swing, J2EE, etc. Possibly some of the most poorly designed APIs in recent history. Yet unfortunatly this isn't exactly uncommon in java.
simple case in point:
in .NET, fixed length array-style items have a 'Length' property. variable length items have a 'Count' property. In java this can be one of the folowing (and more): getLength(), GetLength(), length(), getSize(), size(), getCount(), count(), getItemLength(), get... etc etc.
Also I feel the .NET namespace naming convensions are far better. All standard stuff is stored in System, so thats almost always the first place you look.
For example, I recently wanted to find a mutex in java. In .NET thats System.Threading.Mutex. Easy. Logical. In java it turns out there isn't a mutex pre- java 1.5, the 1.5 mutex... well, I can't actually find it anymore.. it was buiried so deep, and in some obscure place that didn't really make any sense. Ohh well.
Also it simply comes down to bugs in the software. I have *countless* times been stumped by something completly whacky happening in java. Possibly the most rediculous is in Swing, where when you are using a GridBagLayout (ohh god! the horror) attached to a panel, even if you tell it explicitly to make the grid exacting pixel-by-pixel sizes, it still may resize itself without warning. The solution? well, turns out the only way to get around this bug is:
panel.SetPreferredSize( panel.GetPrefferedSize() );
Yup. Great. Obvious.
*sigh*
and don't get me started on J2EE. The weeks of my life wasted on that stinking pile of....
but I should stop myself. I don't want to start a java - .net flame war. These things are just personal preference. I've just had far too many bad experiences with java to even consider it anymore. Both are very capable tools, I just feel .net is the better one.
Last edited by a moderator: