If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#61
|
|||
|
|||
"Brian" wrote in message
... "Sean Hederman" wrote in message [Snip] You may be right, but it does look like MS is doing a good job of keeping the frameworks versioning tight so far, so I'd say that this comment is a bit premature. As is yours, because it hasn't been through enough versions or major upgrades yet to give real headaches. Microsoft's track record with other products suggests that major upgrades always break something that used to work. Of more concern, however, is the situation when the beast is, say, 5-10 years old and developers have to target an unpredictable heterogeneous population of framework versions and need to make their app work with all of them. It's a problem that Access developers struggle with (hence the OP's comments), and I don't expect it to be any different with the dotnet framework. But one of the design goals of the .NET framework is to help resolve this exact issue. [Snip] You attack a straw man. It was the OP who introduced the term "freestanding" to describe a dotnet app, not me. I was merely pointing out the error in his interpretation. In any case, there are lots of genuine binary programs on my computer. Freestanding they may not be in an absolute sense, but, being real binaries, they are of a quite different nature to a dotnet app (or, indeed, an Access app or a VB6 app). Actually most VB6 apps are genuine binary programs. The default compilation option is native image not pcode. Anyway what's so holy about binary programs? .NET winds up JITting the IL to binary, so once that's done once, you effectively do have a binary app. I suggest you write some C++ code and some C# code and compare the two final binaries. You'll find that the machine instructions are very similar. [Snip] As to your assertion about people nicking your code, have you ever tried to work out what's happenning in a large undocumented, uncommented piece of source code? Not fun, and certainly not easy. I've done it lots. Quite enjoy it, actually. Good for you, I hate it. I like my code nicely commented and with good semantic naming. |
#62
|
|||
|
|||
"Sean Hederman" wrote in message ... "Brian" wrote in message ... "Sean Hederman" wrote in message But one of the design goals of the .NET framework is to help resolve this exact issue. Setting goals is one thing, achieving them is quite another. I don't suppose anyone ever started out with any product *intending* to cause version issues. Anyway what's so holy about binary programs? As someone who does much of his work in Access, it is highly unlikely that I would claim there is anything holy about binaries, and I think you will find that I indeed made no such claim. As I keep saying, I was simply explaining/illustrating the OP's error in assuming that a dotnet app was in some sense independent of a runtime environment and hence immune to version problems. Good for you, I hate it. I like my code nicely commented and with good semantic naming. Indeed, but there is a certain satisfaction in successfully completing a detective mission. I just love problem solving, I'm a weirdo, I like support work! Don't get me wrong, I'm not totally anti dotnet, I can see that there is merit in some of the things Microsoft has tried to achieve. However, for a pure (Windows) database app of any size up to less-than-massive, I consider that Access is so much more productive a development technology that it is crazy, and possibly dishonest, to use anything else - and before anyone starts screaming again about the limitations of the mdb file as a backend database, let me say again, I KNOW, you hear me, I KNOW: Access apps can be developed very satisfactorily indeed with a SQL Server backend, lotsa stored procedures and so on, and this is what I often do. This is not a criticism specifically of dotnet - I held the same opinion about VB6 and predecessors - rather, it is a recognition of the special qualities that Access brings to the table through it's status as a product totally dedicated to one kind of app i.e. the Windows database app. I myself invested in VS.Net as soon as it was out, and have several times embarked on developing apps using it. However, on each occasion, I have got so frustrated at the shortcomings, flaws and downright bugs I found that I gave up and went back to VB6. Such as? I hear you asking. Well, here's just one tiny, tiny example: the Windows Forms combo box control. A right Friday afternoon job if ever I saw one. Why the hell doesn't it expose a border style property? And why the hell doesn't it autocomplete (something combo boxes have been doing since about Babbage's time)? OK, one of the fantastic things about dotnet is that it's so easy to roll your own controls, so you can get round cock-ups like this (anyone want an autocompleting combo box with a border style property? I've got one knocking around somewhere), but when you find and have to resolve something like this every hour or so projects begin to look unfeasibly expensive. OK, these things will get resolved (maybe they already have been, I haven't looked at the thing for ages), but at the moment I'm pretty grumpy about what seems to me to have been something of a waste of cash! |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Access Error Message when opening database | eah | General Discussion | 3 | January 26th, 2005 10:04 AM |
Images in a database | Franz | General Discussion | 10 | October 7th, 2004 09:35 AM |
Access XP Compared to Access 2003 | Mardene Leahu | New Users | 1 | October 1st, 2004 05:11 AM |
Upload Image | Jason MacKenzie | General Discussion | 1 | September 1st, 2004 04:38 AM |
Error while running Access MDE | Hemil | General Discussion | 2 | June 21st, 2004 01:03 PM |