Hi Jay,
Is the next Framework 1.2 or 2.0? I have seen references to both.
I have no idea, your guess is better than mine
I would expect it will be a new install, as the primary rational is to avoid
DLL hell. When you start adding major functionality such as Generics & 64
bit support you are courting DLL hell if you think you can pull off an
update.
64 bit support is a long way off yet isn't it? I mean we are yet to have 64
bit operating systems and the like, or is that what the next Framework is
going to be aimed for? If that is the case they are not going to have
anywhere near the number of developers that they have for 32 bit until at
least a couple of years after it's release.
(Nintendo 64 bit owners saying, "Hey, N64 was 64 bit long ago, PC's are
sh1t!".)
^ Go away you stupid people
Remember updates are really only useful when apply bug fixes, not
introducing new functionality. If they update 1.1 with new functionality
(changed parameters for example) how are existing 1.1 apps suppose to react?
Fail? I hope you agree that having existing apps fail really is not an
option!
Well, 1.1 suggest to me that it was a minor change and shouldn't actually
break any compatability. If on the otherhand it was 2.0, I would have
presumed a completely new version that was incompatible with 1.0. I
understand that their enthusiasm may have got the better of them by
releasing 1.0 when they did.
Do you want to by a new development system each time a new framwork comes
out? That's goes against good programming practices really, but doesn't
suprise me as it is all money at the end of the day, and pretty much
guaranteed it is!
Remember Microsoft centered the Framework around side by side installs, to
maximize the chances that existing apps do not fail.
On the other hand, I believe I am right in saying that new processors
incorporate the previous design in order to maintain compatability. I know
that this is not the same as it is hardware, but technically software *can*
be designed in a very similar fasion. It is slightly confusing have
multiple frameworks on a system and I can imagine that it could cause
nightmares in it's own right, if they were totally separate you would not
have to install them in any particular order, so they must be linked in some
way or another, if only by the registry.
I would expect people will have upto 3 Frameworks on their system. If they
have the current version their programs with continue to run, if they have
the original version their newer programs might run assuming they did not
use anything in the newer framework. Which is true today with 1.0 & 1.1
That's a little, if not extremely impractical. Imagine having more than one
DirectX installed on your system! you wouldn't expect that, yet
fundamentally it should be done in the same way as DirectX, newer version
relace older yet open up new features, sometimes a break in compatability
occurs but that's to be expected. At the moment you can actually improve
the performance and reliability of some DirectX software by upgrading your
version of DirectX, now *that* seems very sensible to me.
Which means you can "replace" 1.0 with 1.1 and every thing should continue
to run, there are a few minor gotchas as identified on the gotdotnet page
referenced in the above URL. I would expect the next version will be able to
"replace" 1.0 & 1.1 with the similar minor gotchas. By replace I mean
uninstall previous and install the next version.
Yup, I am actually testing my software in exactly that way now. I have
another system setup with XP Pro and version 1.1 of the Framework. I have
come across a few glitches which have forced me to reconsider some elements
but other than that it has been pretty smooth. But this is not the
question, the question is development, I *want* to use VB.NET Standard 2002
for version 1.1 of the Framework, that would be great but I don't understand
why you can't, the IDE refers to the SDK for information and surely the SDK
can be modified, what else does the IDE use from the Framework? I'm
interested to know, surely it isn't hardcoded, or maybe elements such as
syntax changes in VB.NET and the like where DLL's would need replacing I
suppose, but then again, that is the IDE and *not* the Framework where those
changes are incorporated.
I would expect VS.NET 2003 to remain to be hard coded to 1.1, I would also
expect you will need to use VS.NET 2004 to program the next version of the
Framework, however I expect there will continue to be an option under
Project Properties to change which version the program expects to run
under.
Where is this option? Is it in 2002?
I would hope, but do not expect that VS.NET 2004 supports changing which
compiler (1.0, 1.1, or current) you use. However I question what the real
benefit is. (which is why I don't expect to get that option ;-))
It's a shame that Microsoft haven't marketed this slightly differently,
having an IDE as a product and language plugins to go with it. Purchasing
VB.NET could see you getting the IDE and the VB.NET plugin, but then they
would be too scared that people would distribute the plugins easier as they
would be very small in comparrison to the entire IDE.
As well as having a "Check for Updates" button that could potentially do
something. If Microsoft had acted sooner we could all have Service Pack 1
for 2002, including slight lanuage changes to VB.NET and the like, but that
would have lost them much much money, hence it was never done. I look
forward to the day someone releases information on the net on how to get
version 1.1 of the Framework running glitch free with 2002, there will be
much rejoycing.
Nick.
--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
"No matter. Whatever the outcome, you are changed."
Fergus - September 5th 2003
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\