Hi there,
Has anyone any ideas if the next Framework will be an update to version
1.1 or another completely new install so that people have 3 Frameworks on
their system? And can VS.NET 2003 be set to use any Framework other than
1.1?
Nick.
--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
"No matter. Whatever the outcome, you are changed."
Fergus - September 5th 2003
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
23  1760 
"Nak" <a@a.com> schrieb Hi there,
Has anyone any ideas if the next Framework will be an update to
version
1.1 or another completely new install so that people have 3
Frameworks on their system? And can VS.NET 2003 be set to use any
Framework other than 1.1?
I don't remember if it contains the information you are looking for, but you
could have a look here: http://msdn.microsoft.com/vstudio/pr...o/roadmap.aspx
--
Armin
"Nak" <a@a.com> wrote in message
news:eu**************@TK2MSFTNGP11.phx.gbl...
.. . . Has anyone any ideas if the next Framework will be an update to
version 1.1 or another completely new install so that people have 3
Frameworks on their system?
Not counting the Beta releases, /every/ version of the Framework
stands on its own. And yes; you'll have as many versions installed
as your application-base requires.
And can VS.NET 2003 be set to use any Framework other than 1.1?
No. If you uninstall v1.1, Studio curls up in a heap and dies, unable
to find its compiler! It is supposedly possible to write code (in Studio
2003) that will run on v1.0 of the Framework - never tried it though.
HTH,
Phill W.
Hi there, Not counting the Beta releases, /every/ version of the Framework
stands on its own. And yes; you'll have as many versions installed
as your application-base requires.
I was hoping this wasn't going to be the case. What a bad design in
programming!
No. If you uninstall v1.1, Studio curls up in a heap and dies, unable
to find its compiler! It is supposedly possible to write code (in Studio
2003) that will run on v1.0 of the Framework - never tried it though.
LOL, one of lifes little mysteries, I never will understand why they made it
like they did, oh hang on, yes I will, how much does VS cost again? ;-)
Nick.
--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
"No matter. Whatever the outcome, you are changed."
Fergus - September 5th 2003
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
"Phill. W" <P.A.Ward@o-p-e-n-.-a-c-.-u-k> wrote in message
news:bn**********@yarrow.open.ac.uk... "Nak" <a@a.com> wrote in message
news:eu**************@TK2MSFTNGP11.phx.gbl...
. . . Has anyone any ideas if the next Framework will be an update to
version 1.1 or another completely new install so that people have 3
Frameworks on their system?
And can VS.NET 2003 be set to use any Framework other than 1.1?
HTH,
Phill W.
Hi there, http://msdn.microsoft.com/vstudio/pr...o/roadmap.aspx
I've checked that page out before and I don't recall it having any info
regarding this, though I may be wrong.
Anyway, as usual, just curious :-)
Nick.
--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
"No matter. Whatever the outcome, you are changed."
Fergus - September 5th 2003
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
> LOL, one of lifes little mysteries, I never will understand why they made it
like they did, oh hang on, yes I will, how much does VS cost again? ;-)
We can only hope that Whidbey will be able to target whatever framework(s)
are installed on the system. I'd hate to have to pay to upgrade for every
version of the framework.
--
Chris
To send me an E-mail, remove the underscores and lunchmeat from my E-Mail
address.
Nick,
Is the next Framework 1.2 or 2.0? I have seen references to both.
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.
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!
Remember Microsoft centered the Framework around side by side installs, to
maximize the chances that existing apps do not fail. http://msdn.microsoft.com/library/de...dexsidenet.asp another completely new install so that people have 3 Frameworks on
their system?
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.
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.
And can VS.NET 2003 be set to use any Framework other than
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.
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 ;-))
Just a thought
Jay
"Nak" <a@a.com> wrote in message
news:eu**************@TK2MSFTNGP11.phx.gbl... Hi there,
Has anyone any ideas if the next Framework will be an update to
version 1.1 or another completely new install so that people have 3 Frameworks on
their system? And can VS.NET 2003 be set to use any Framework other than
1.1?
Nick.
--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ "No matter. Whatever the outcome, you are changed."
Fergus - September 5th 2003
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
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.
--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
"No matter. Whatever the outcome, you are changed."
Fergus - September 5th 2003
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
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.
And can VS.NET 2003 be set to use any Framework other than 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.
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 ;-))
Just a thought
Jay
"Nak" <a@a.com> wrote in message
news:eu**************@TK2MSFTNGP11.phx.gbl... Hi there,
Has anyone any ideas if the next Framework will be an update to
version 1.1 or another completely new install so that people have 3 Frameworks
on their system? And can VS.NET 2003 be set to use any Framework other
than 1.1?
Nick.
--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ "No matter. Whatever the outcome, you are changed."
Fergus - September 5th 2003
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
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
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Just a thought
Jay
"Nak" <a@a.com> wrote in message
news:eu**************@TK2MSFTNGP11.phx.gbl... Hi there,
Has anyone any ideas if the next Framework will be an update to
version 1.1 or another completely new install so that people have 3 Frameworks
on their system? And can VS.NET 2003 be set to use any Framework other
than 1.1?
Nick.
--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ "No matter. Whatever the outcome, you are changed."
Fergus - September 5th 2003
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Ignore this one OE has a habbit of sending messages half way through writing
them, something is afoot :-p I have posted again with the complete reply.
Nick.
--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
"No matter. Whatever the outcome, you are changed."
Fergus - September 5th 2003
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Nick,
In VS.NET 2003 you can use "Project - Properties - Common Properties -
Build" to select which version of the runtime to use. It will default to
1.1, however you can click the Change button to select
- Microsoft .NET Framework v1.1 (default)
- Microsoft .NET Framework v1.0 (advanced)
- Microsoft .NET Framework v1.1 and v1.0 (advanced)
Be certain to read & understand the warning!
You program is still compiled with V1.1 compiler & references, however
basically your app.config/web.config is modified to reference the earlier
version of the runtime.
You can open the app.config in the root of your project to see the changes
that it made.
I would expect the above dialog to be extended for Whidbey (VS.NET 2004) and
the next version of the Framework.
Hope this helps
Jay
"Nak" <a@a.com> wrote in message
news:eF**************@TK2MSFTNGP12.phx.gbl... Hi Jay,
<<snip>> 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?
<<snip>>
Nak,
You can purchase Windows Server 2003 64-bit versions, today! http://www.microsoft.com/windowsserv...t/default.mspx
Whidbey will have 64-bit support when it ships. Your current apps can be
configured to run under either 64-bit or 32-bit Framework without
recompiling! anywhere near the number of developers that they have for 32 bit until at
least a couple of years after it's release.
Ah! you're missing the beauty of .NET! ;-)
All 32 bit .NET developers are automatically 64 bit .NET developers, from
the point of view of C# & VB.NET there is NO "real" difference!
Remember .NET developers normally (should) develop to the CLR & BCL not
Win32. Not Win32 in that you should limit & isolate any Win32 API calls.
An object reference is still an object reference, an Integer is still a
System.Int32, a Double is still a System.Double, a Windows Form is still a
System.Windows.Forms.Form, a DataSet is still a System.Data.DataSet...
The only real change is System.IntPtr & System.UIntPtr, on 32bit .NET IntPtr
is 32 bit, on 64-bit .NET IntPtr is 64-Bit. Obviously there will be concerns
with PInvoke, however if you encapsulated and isolated your Win32 calls to
one or two classes (like a good OOP developer should), then that should be
minor also.
See the following MSDN TV article for details:
http://msdn.microsoft.com/msdntv/epi...B/manifest.xml
Hope this helps
Jay
"Nak" <a@a.com> wrote in message
news:ub**************@TK2MSFTNGP10.phx.gbl... 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
<<snip>>
Hi there, You can purchase Windows Server 2003 64-bit versions, today!
ACK, but that is a server, not meant for home use, as I am developing for
the average user and not businesses. And in my honest opinion, the majority
of users are going to be home users.
Whidbey will have 64-bit support when it ships. Your current apps can be
configured to run under either 64-bit or 32-bit Framework without
recompiling!
Sounds cool
Ah! you're missing the beauty of .NET! ;-)
LOL
An object reference is still an object reference, an Integer is still a
System.Int32, a Double is still a System.Double, a Windows Form is still a
System.Windows.Forms.Form, a DataSet is still a System.Data.DataSet...
LOL, I didn't think this was going to change number bases! More precision
is the result.
The only real change is System.IntPtr & System.UIntPtr, on 32bit .NET
IntPtr is 32 bit, on 64-bit .NET IntPtr is 64-Bit. Obviously there will be
concerns with PInvoke, however if you encapsulated and isolated your Win32 calls to
one or two classes (like a good OOP developer should), then that should be
minor also.
ACK, I'm viewing the video too.
"like a good OOP developer should"
Good OOP would have been 1 IDE being updated with service packs and no
having to have 2 Frameworks on a computer.
Nick.
--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
"No matter. Whatever the outcome, you are changed."
Fergus - September 5th 2003
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Nak, An object reference is still an object reference, an Integer is still a
System.Int32, a Double is still a System.Double, a Windows Form is still
a System.Windows.Forms.Form, a DataSet is still a System.Data.DataSet...
LOL, I didn't think this was going to change number bases! More precision
is the result.
I'm not following you. Specifically "more precision is the result", are you
saying you expect more precision under 64-bit .NET or no you don't?
Remember 64-Bit .NET is going to have the same "precision" as 32-bit .NET
for all data types (except IntPtr), what change you will notice is, that
things should be faster and you will have significantly more memory space
(tera bytes instead of giga bytes). I am excluding object reference as a
data type, as Object is the data type, the reference is how you get to that
object, the reference will be larger of course.
Hope this helps
Jay
"Nak" <a@a.com> wrote in message
news:eX**************@tk2msftngp13.phx.gbl... Hi there,
You can purchase Windows Server 2003 64-bit versions, today!
ACK, but that is a server, not meant for home use, as I am developing for
the average user and not businesses. And in my honest opinion, the
majority of users are going to be home users.
Whidbey will have 64-bit support when it ships. Your current apps can be
configured to run under either 64-bit or 32-bit Framework without
recompiling!
Sounds cool
Ah! you're missing the beauty of .NET! ;-)
LOL
An object reference is still an object reference, an Integer is still a
System.Int32, a Double is still a System.Double, a Windows Form is still
a System.Windows.Forms.Form, a DataSet is still a System.Data.DataSet...
LOL, I didn't think this was going to change number bases! More precision
is the result.
The only real change is System.IntPtr & System.UIntPtr, on 32bit .NET
IntPtr is 32 bit, on 64-bit .NET IntPtr is 64-Bit. Obviously there will be
concerns with PInvoke, however if you encapsulated and isolated your Win32 calls
to one or two classes (like a good OOP developer should), then that should
be minor also.
ACK, I'm viewing the video too.
"like a good OOP developer should"
Good OOP would have been 1 IDE being updated with service packs and no
having to have 2 Frameworks on a computer.
Nick.
--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ "No matter. Whatever the outcome, you are changed."
Fergus - September 5th 2003
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
* "Jay B. Harlow [MVP - Outlook]" <Ja********@email.msn.com> scripsit: Is the next Framework 1.2 or 2.0? I have seen references to both.
In one of the other public groups someone said that it's 1.2* "now" and it will
be 2.0 when released.
--
Herfried K. Wagner
MVP · VB Classic, VB.NET
<http://www.mvps.org/dotnet>
Herfried,
That makes sense.
Makes talking about it interesting, but it makes sense to number them that
way.
Thanks
Jay
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:bn************@ID-208219.news.uni-berlin.de... * "Jay B. Harlow [MVP - Outlook]" <Ja********@email.msn.com> scripsit: Is the next Framework 1.2 or 2.0? I have seen references to both.
In one of the other public groups someone said that it's 1.2* "now" and it
will be 2.0 when released.
--
Herfried K. Wagner
MVP · VB Classic, VB.NET
<http://www.mvps.org/dotnet>
On Thu, 23 Oct 2003 11:53:43 -0500, Jay B. Harlow [MVP - Outlook] wrote: You program is still compiled with V1.1 compiler & references, however
basically your app.config/web.config is modified to reference the earlier
version of the runtime.
This makes no sense to me. I choose to use a certain framework that's
installed, then the IDE should point to the correct compiler, intellisense
data, etc. Suppose I buy VS.Net 2004 but a little while after that, they
put out framework version 3.0. I should not have to upgrade my VS to use
the new framework. To my mind, VSNet should be a shell around the
framework. The only advantage to upgrading VS.Net would be to obtain any
new productivity enhancements that they care to add. But I should be able
to target any version of the framework.
Just my 2c
--
Chris
To send me an E-mail, remove the underscores and lunchmeat from my E-Mail
address.
Hi Jay, I'm not following you. Specifically "more precision is the result", are
you saying you expect more precision under 64-bit .NET or no you don't?
Remember 64-Bit .NET is going to have the same "precision" as 32-bit .NET
for all data types (except IntPtr), what change you will notice is, that
things should be faster and you will have significantly more memory space
(tera bytes instead of giga bytes). I am excluding object reference as a
data type, as Object is the data type, the reference is how you get to
that object, the reference will be larger of course.
Don't worry, I must be missing something along the lines. I wouldn't bother
explaining too much too me, there is allot that I do not know obviously!
LOL, ignore me!
Nick.
--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
"No matter. Whatever the outcome, you are changed."
Fergus - September 5th 2003
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
"Jay B. Harlow [MVP - Outlook]" <Ja********@email.msn.com> wrote in message
news:ej**************@TK2MSFTNGP09.phx.gbl... Nak, An object reference is still an object reference, an Integer is still
a System.Int32, a Double is still a System.Double, a Windows Form is
still a System.Windows.Forms.Form, a DataSet is still a System.Data.DataSet...
LOL, I didn't think this was going to change number bases! More
precision is the result.
Hope this helps
Jay
"Nak" <a@a.com> wrote in message
news:eX**************@tk2msftngp13.phx.gbl... Hi there,
You can purchase Windows Server 2003 64-bit versions, today!
ACK, but that is a server, not meant for home use, as I am developing
for the average user and not businesses. And in my honest opinion, the
majority of users are going to be home users.
Whidbey will have 64-bit support when it ships. Your current apps can
be configured to run under either 64-bit or 32-bit Framework without
recompiling!
Sounds cool
Ah! you're missing the beauty of .NET! ;-)
LOL
An object reference is still an object reference, an Integer is still
a System.Int32, a Double is still a System.Double, a Windows Form is
still a System.Windows.Forms.Form, a DataSet is still a System.Data.DataSet...
LOL, I didn't think this was going to change number bases! More
precision is the result.
The only real change is System.IntPtr & System.UIntPtr, on 32bit .NET
IntPtr is 32 bit, on 64-bit .NET IntPtr is 64-Bit. Obviously there will be
concerns with PInvoke, however if you encapsulated and isolated your Win32
calls to one or two classes (like a good OOP developer should), then that
should be minor also.
ACK, I'm viewing the video too.
"like a good OOP developer should"
Good OOP would have been 1 IDE being updated with service packs and no
having to have 2 Frameworks on a computer.
Nick.
--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ "No matter. Whatever the outcome, you are changed."
Fergus - September 5th 2003
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Chris, & Nick,
Does Sharp Develop or Eclipse have that ability?
If they do, you could consider using Sharp Develop or Eclipse over VS.NET. http://www.icsharpcode.net/OpenSource/SD/ http://www.eclipse.org/
It is a free market you know. (competition?)
There is a C# plug-in for Eclipse, not sure if there is a VB.NET plug-in
available.
Of course you can submit something to MS to request they change the way they
handle it. http://register.microsoft.com/mswish...=EN-US&gssnb=1
Alternatively you could consider purchasing MSDN Universal, then the expense
is not just for a VS.NET upgrade. But rather MSDN itself, which offers so
much more than just VS.NET. http://msdn.microsoft.com/subscriptions/ The only advantage to upgrading VS.Net would be to obtain any
new productivity enhancements that they care to add.
That and the bug fixes are why I upgrade to the next version of VS.NET when
I upgrade to the next version of the Framework.
Just a thought
Jay
"Chris Dunaway" <dunawayc@_lunchmeat_sbcglobal.net> wrote in message
news:1m*****************************@40tude.net... On Thu, 23 Oct 2003 11:53:43 -0500, Jay B. Harlow [MVP - Outlook] wrote:
You program is still compiled with V1.1 compiler & references, however
basically your app.config/web.config is modified to reference the
earlier version of the runtime.
This makes no sense to me. I choose to use a certain framework that's
installed, then the IDE should point to the correct compiler, intellisense
data, etc. Suppose I buy VS.Net 2004 but a little while after that, they
put out framework version 3.0. I should not have to upgrade my VS to use
the new framework. To my mind, VSNet should be a shell around the
framework. The only advantage to upgrading VS.Net would be to obtain any
new productivity enhancements that they care to add. But I should be able
to target any version of the framework.
Just my 2c
--
Chris
To send me an E-mail, remove the underscores and lunchmeat from my E-Mail
address.
Hey! I make pun: It is a free market you know. (competition?)
Its a free market, and the two products I mentioned are free ;-)
Must be late, unfortunately its the middle of the after noon, maybe I just
need a life... ;-)
Jay
"Jay B. Harlow [MVP - Outlook]" <Ja********@email.msn.com> wrote in message
news:OV**************@tk2msftngp13.phx.gbl... Chris, & Nick,
Does Sharp Develop or Eclipse have that ability?
If they do, you could consider using Sharp Develop or Eclipse over VS.NET.
http://www.icsharpcode.net/OpenSource/SD/
http://www.eclipse.org/
It is a free market you know. (competition?)
There is a C# plug-in for Eclipse, not sure if there is a VB.NET plug-in
available.
Of course you can submit something to MS to request they change the way
they handle it.
http://register.microsoft.com/mswish...=EN-US&gssnb=1
Alternatively you could consider purchasing MSDN Universal, then the
expense is not just for a VS.NET upgrade. But rather MSDN itself, which offers so
much more than just VS.NET.
http://msdn.microsoft.com/subscriptions/
The only advantage to upgrading VS.Net would be to obtain any
new productivity enhancements that they care to add. That and the bug fixes are why I upgrade to the next version of VS.NET
when I upgrade to the next version of the Framework.
Just a thought
Jay
"Chris Dunaway" <dunawayc@_lunchmeat_sbcglobal.net> wrote in message
news:1m*****************************@40tude.net... On Thu, 23 Oct 2003 11:53:43 -0500, Jay B. Harlow [MVP - Outlook] wrote:
You program is still compiled with V1.1 compiler & references, however
basically your app.config/web.config is modified to reference the earlier version of the runtime.
This makes no sense to me. I choose to use a certain framework that's
installed, then the IDE should point to the correct compiler,
intellisense data, etc. Suppose I buy VS.Net 2004 but a little while after that,
they put out framework version 3.0. I should not have to upgrade my VS to
use the new framework. To my mind, VSNet should be a shell around the
framework. The only advantage to upgrading VS.Net would be to obtain
any new productivity enhancements that they care to add. But I should be
able to target any version of the framework.
Just my 2c
--
Chris
To send me an E-mail, remove the underscores and lunchmeat from my
E-Mail address.
Hi there, Does Sharp Develop or Eclipse have that ability?
They are Free, and the do not have anywhere near the resources poured into
them to be able to cover all of the aspects. Also Microsoft developed the
..NET Framework so they *should* have more of an understanding about it.
If they do, you could consider using Sharp Develop or Eclipse over VS.NET.
I would *love* to use something else rather that the Microsoft IDE, but they
aren't as good, as simple as that. On the other hand the Free ones aren't
claiming to be something that they are not.
People say hey, $29 upgrade! bargain!, I say yes it may be cheap, but it is
unnecessary due to programming being driven around marketing and at the end
of the day it is still *allot* of money when you are talking about a few
hundred thousand people purchasing it! As well as the upgrade not being
available to *standard* users, because somehow Microsoft have decided that
you cannot develop professionaly with a component of Visual Studio .NET, you
need to whole shebang, which is utter nonsence.
Of course you can submit something to MS to request they change the way
they handle it.
http://register.microsoft.com/mswish...=EN-US&gssnb=1
LOL!!! That would be like replying to senders of SPAM asking them to please
stop!!
Alternatively you could consider purchasing MSDN Universal, then the
expense is not just for a VS.NET upgrade. But rather MSDN itself, which offers so
much more than just VS.NET.
It's too expensive for me, and too expensive for allot of people. If I
could get a subscription I would, but alas I cannot at the moment, maybe a
future investment. But at the end of the day it's just like software
engineers making games for the latest computers, they very rarely consider
the lower spec systems, they are dead set on you having the biggest and the
best and that is that, so people with lower budgest miss out simply down to
poor design! Ill give you an example of excellent programming, Half Life 2
is coming out in December and it is technically going to beat any other game
in existance, and what's the minimal spec? a 700mhz CPU and DirectX 6!! Now
*that* is good.
That and the bug fixes are why I upgrade to the next version of VS.NET
when I upgrade to the next version of the Framework.
What about Visual Studio 6 for chirst sake! That has 5 service packs!!!!
What is the point in releasing a piece of software with an "check for
updates" button that has no intention of ever being implemented. When
Whidbey comes out is it going to display a message box saying, "an update is
available, go purchase it now!".
I think you are missing my point, you can throw money at anything and it
will pretty much fix it, but that is not how everyone wants to work
unfortunately. I do not want to develop on the bleeding edge of technology,
constantly using the latest software that is full of bugs and design flaws,
Id rather use a well refined package that has had all of it's bugs ironed
out over a period of time. Just like software I have released in the past,
I know I am nowhere near the scale of Microsoft, but in essence, software
design is pretty much the same because the second you release that
application, a bug will be found, and would you want to tell your users that
it's tough shit, and that they need to go and buy the new version to fix it?
which will also contain bugs? I don't think so.
Nick.
--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
"No matter. Whatever the outcome, you are changed."
Fergus - September 5th 2003
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
"Jay B. Harlow [MVP - Outlook]" <Ja********@email.msn.com> wrote in message
news:OV**************@tk2msftngp13.phx.gbl... Chris, & Nick,
http://www.icsharpcode.net/OpenSource/SD/
http://www.eclipse.org/
It is a free market you know. (competition?)
There is a C# plug-in for Eclipse, not sure if there is a VB.NET plug-in
available.
http://msdn.microsoft.com/subscriptions/
Just a thought
Jay
"Chris Dunaway" <dunawayc@_lunchmeat_sbcglobal.net> wrote in message
news:1m*****************************@40tude.net... On Thu, 23 Oct 2003 11:53:43 -0500, Jay B. Harlow [MVP - Outlook] wrote:
You program is still compiled with V1.1 compiler & references, however
basically your app.config/web.config is modified to reference the earlier version of the runtime.
This makes no sense to me. I choose to use a certain framework that's
installed, then the IDE should point to the correct compiler,
intellisense data, etc. Suppose I buy VS.Net 2004 but a little while after that,
they put out framework version 3.0. I should not have to upgrade my VS to
use the new framework. To my mind, VSNet should be a shell around the
framework. The only advantage to upgrading VS.Net would be to obtain
any new productivity enhancements that they care to add. But I should be
able to target any version of the framework.
Just my 2c
--
Chris
To send me an E-mail, remove the underscores and lunchmeat from my
E-Mail address.
Hi Jay, Must be late, unfortunately its the middle of the after noon, maybe I just
need a life... ;-)
LOL, If you know where to find one, let me know! ;-)
Nick
--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
"No matter. Whatever the outcome, you are changed."
Fergus - September 5th 2003
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Hi Nick, Has anyone any ideas if the next Framework will be an update to version
1.1 or another completely new install so that people have 3 Frameworks on
Please pay attention to website.
http://msdn.microsoft.com/vstudio/pr...o/default.aspx
their system? And can VS.NET 2003 be set to use any Framework other than
1.1?
Yes.
Applications developed in VS.NET 2003 could be configured to use different
versions of runtime.
SupportedRuntimes Property
http://msdn.microsoft.com/library/de...us/vsintro7/ht
ml/vxgrfSupportedRuntimesProperty.asp
Working with Multiple Versions of the .NET Framework
http://msdn.microsoft.com/library/de...us/vbcon/html/
vbconWorkingWithMultipleVersionsOfNETFramework.asp
Regards,
Peter Huang
Microsoft Online Partner Support
Get Secure! www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
--------------------From: "Nak" <a@a.com>
Subject: Framework v1.2?
Date: Thu, 23 Oct 2003 12:44:31 +0100
Lines: 17
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Message-ID: <eu**************@TK2MSFTNGP11.phx.gbl>
Newsgroups: microsoft.public.dotnet.languages.vb
NNTP-Posting-Host: dsl213-218-227-57.as15444.net 213.218.227.57
Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTN GP11.phx.gbl
Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.languages.vb:149416
X-Tomcat-NG: microsoft.public.dotnet.languages.vb
Hi there,
Has anyone any ideas if the next Framework will be an update to version
1.1 or another completely new install so that people have 3 Frameworks on
their system? And can VS.NET 2003 be set to use any Framework other than
1.1?
Nick.
--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
\"No matter. Whatever the outcome, you are changed."
Fergus - September 5th 2003
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
\
Nak,
I was just reminded that there is a 64-bit version of Windows XP Pro! http://www.microsoft.com/WindowsXP/64bit/default.asp
I already use Windows XP Pro at home, so if I had a 64-bit workstation, I
could run a 64-bit desktop, at home! ;-) http://www.hp.com/workstations/itanium/
Vrmm Vrmm...
:-)
Hope this helps
Jay
"Nak" <a@a.com> wrote in message
news:eX**************@tk2msftngp13.phx.gbl... Hi there,
You can purchase Windows Server 2003 64-bit versions, today!
ACK, but that is a server, not meant for home use, as I am developing for
the average user and not businesses. And in my honest opinion, the
majority of users are going to be home users.
Whidbey will have 64-bit support when it ships. Your current apps can be
configured to run under either 64-bit or 32-bit Framework without
recompiling!
Sounds cool
Ah! you're missing the beauty of .NET! ;-)
LOL
An object reference is still an object reference, an Integer is still a
System.Int32, a Double is still a System.Double, a Windows Form is still
a System.Windows.Forms.Form, a DataSet is still a System.Data.DataSet...
LOL, I didn't think this was going to change number bases! More precision
is the result.
The only real change is System.IntPtr & System.UIntPtr, on 32bit .NET
IntPtr is 32 bit, on 64-bit .NET IntPtr is 64-Bit. Obviously there will be
concerns with PInvoke, however if you encapsulated and isolated your Win32 calls
to one or two classes (like a good OOP developer should), then that should
be minor also.
ACK, I'm viewing the video too.
"like a good OOP developer should"
Good OOP would have been 1 IDE being updated with service packs and no
having to have 2 Frameworks on a computer.
Nick.
--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ "No matter. Whatever the outcome, you are changed."
Fergus - September 5th 2003
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ This discussion thread is closed Replies have been disabled for this discussion. Similar topics
reply
views
Thread by Ravindra |
last post: by
|
3 posts
views
Thread by CMan |
last post: by
|
18 posts
views
Thread by Cameron Laird |
last post: by
|
6 posts
views
Thread by Joseph Geretz |
last post: by
|
9 posts
views
Thread by Tim D |
last post: by
|
1 post
views
Thread by Harry Simpson |
last post: by
|
3 posts
views
Thread by Shadow Lynx |
last post: by
| | |
13 posts
views
Thread by dancer |
last post: by
|
8 posts
views
Thread by Blasting Cap |
last post: by
| | | | | | | | | | | | | | | | | | | |
