Framework v1.2?

  • Thread starter Thread starter Nak
  • Start date Start date
N

Nak

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
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
 
.. . .
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
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
 
Hi there,

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.
 
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/default.asp?url=/library/en-us/dnnetdep/html/sidexsidenet.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
 
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
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
 
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
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
 
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 said:
Hi Jay,


Where is this option? Is it in 2002?
<<snip>>
 
Nak,
You can purchase Windows Server 2003 64-bit versions, today!

http://www.microsoft.com/windowsserver2003/64bit/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/episode.aspx?xml=episodes/en/20030731CLRCB/manifest.xml

Hope this helps
Jay

Nak said:
Hi Jay,


I have no idea, your guess is better than mine :-)


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,
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
 
* "Jay B. Harlow said:
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.
 
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
 
Herfried,
That makes sense.

Makes talking about it interesting, but it makes sense to number them that
way.

Thanks
Jay
 
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 said:
Nak, still
a

LOL, I didn't think this was going to change number bases! More precision
is the result.

Hope this helps
Jay

Nak said:
Hi there,


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.


Sounds cool
still
a

LOL, I didn't think this was going to change number bases! More precision
is the result.
calls
should
be

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/suggestion.asp?&SD=GN&LN=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
 
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
 
Back
Top