Conversion from 2008->2003?

[Family Tree Mike]

Thanks. I did look further but just didn't report it. Looking more closely,
though, there is this line:

<Reference Include="System.Xml.Linq">
<RequiredTargetFramework>3.5</RequiredTargetFramework>

which is one of the things you mentioned requires 3.5 (as opposed to 2.0).

Will have to find out whether thats actually required or whether it just got
included by accident or "copy and paste" from another project.

Thanks,
Alain





.

I'm pretty sure that line will tell you that the code was built to 3.5. It
may be quite simple to recreate the app as a 2.0 app. It depends on how much
"LINQ"ing they did, for example.

Mike

 

[Scott M.]

Thanks. I did look further but just didn't report it. Looking more
closely, though, there is this line:

<Reference Include="System.Xml.Linq">
<RequiredTargetFramework>3.5</RequiredTargetFramework>

which is one of the things you mentioned requires 3.5 (as opposed to 2.0).

Will have to find out whether thats actually required or whether it just
got included by accident or "copy and paste" from another project.

Thanks,
Alain

Yes. When you create a new project in VS 2008, it assumes (by default) that
you want to use the 3.5 Framework and, as a result, it creates certain basic
assembly refererences for you (System.Xml.Linq being one of them). It's
entirely possible that during the development of the application, Linq never
gets used though.

One very nice feature of VS 2008, when working with VB projects, is that you
can go to the references dialog and click the "Unused References" button,
which will report back to you on assemblies that are referenced, but not
actually used by your code. This makes it very easy to remove what you're
not using. The result being that even though you might have started out
targetting the 3.5 Framework, you might not be actually using any assemblies
defined in 3.5.

That's why I say that you can't just look at the RequiredTargetFramework tag
in the .vbproj file. It may say 3.5, but you may not actually be using or
even have any 3.5 assembly references.

-Scott

 

[Scott M.]

BTW, an "evangelist" is not meant perjoratively. I'm a MS and a native C++
envangelist, for example. Its just someone who, if you like, defends a
viewpoint. The more usual term is "apologist".

An "evangelist" is someone who *promotes* something, not necessarially one
who defends something. I can defend a criminal in court, but that doesn't
mean I promote the criminal's behavior.

I'm not sure the 200MB / 60MB limits you mention are correct.

I may be off by a few 10's of megabytes (because the actual size will depend
on your system configuraiton), but I'm quite sure that the installation does
not exceed 400MB (I actually have never seen even this size -- It's almost
always right about 300MB).

I have the full versions of each of the Frameworks (and all available
Framework SP's) on my XP Pro SP 3 system and can tell you definitively that
the installation sizes of approximately:

200MB for 2.0
33 MB for 3.0
30 MB for 3.5

is right in line with, not only what MS documentation says it should be, but
also what others report as well.

I definitely saw something on the MS Update website that was absolutely
massive and it was something to do with .NET 3.5. As I've already
installed it here on my dev machine, I can't see it anymore. I'll check
online on the deployment machine tomorrow and report back.

I'm quite sure that if you are getting an installation size of anything over
500MB, then you are installing something in addition to the full 3.5
Framework (BTW the term "full 3.5 Framework" generally means the 2.0, 3.0,
and 3.5 Frameworks).

Again, please refer to the following MS link for the details of the 3.5
Framework installation:

http://www.microsoft.com/downloads/...FD-AE52-4E35-B531-508D977D32A6&displaylang=en

I'm perfectly happy to admit it if I'm wrong, but I am absolutely sure
that whatever it was that I installed was very large and meant the clone
size went slightly over 4.0GB when without it the clone was under 3.0GB.
It might have been XP SP3 (which includes .NET 3.0, 3.5, SPs and so on).

As far as I understand it, each version of .NET gets its own set of
folders buried somewhere in the
%windir% folder. This means, unless I'm mistaken, that .NET 3.5 and its SP
will exist in separate folders. Correct me if I'm wrong, please. This
implies more than just 60MB.

You are correct that each Framework will install to its own folder, but SP's
will install into the main Framework folder for any given version. So, when
I report that 3.5 takes 29MB that actually includes 3.5 SP1. You'll see
below that my 60MB number is correct for the 3.0 and 3.5 upgrade from 2.0.

You can locate any and all Framework versions you have here:

C:\WINDOWS\Microsoft.NET\Framework

On my system (and every other I've ever seen, which is quite a few) the
Framework sizes are:

1.1 - 54MB
2.0 (the root of the 3.0 and 3.5 Frameworks) - 219 MB
3.0 (an add on to 2.0) - 33MB
3.5 (an add on to 2.0 and 3.0) - 29MB

So, as I say, the 2.0 Framework is where you'll take the biggest size hit.
After that, it's only an additional 62MB to add 3.0 and 3.5 on top of those.

-Scott

 

[Scott M.]

Oh, dear. Actually Rory above gave the opposite answer, but yours is
consistent with everything else I've been reading about on the net today.

Pity this. MS have usually been very good with providing backward
compatibility, but I think the pace of technological change is very, very
rapid these days and backward compatibility is a costly exercise for
manufacturers. MS have been dropping the ball, admittedly hot and
complicated, in my opinion.

Personally, I don't understand why the XML definition of the project can't
be fully backward compatibile, like a set of inherited class:

<BaseSettings>
<?Common to all variants of VS.NET>
<...>
</BaseSettings>
<VS2003::BaseSettings>
<...>
</VS2003::BaseSettings>
<VS2005::VS2003>
<?this will be ignored by 2003>
<...>
</VS2005::VS2003>
<etc...>

Can't they do this? I know this is simplistic and doesn't deal with actual
coding issues not supported by 2003, but its a start, surely. Maybe MS
could provide a tool that added into 2003 and highlighted code not
compatible with 2003 or the 1.x framework.

Even without the tool, with the XML project definition done along the
lines shown above, at least you could load a 2008 project in 2003, though
of course you might not be able to compile it.

Just a thought...

Regards,
Alain

One thing to keep in mind when discussing backwards compatibility and Visual
Studio's lack thereof, is that each version of the .NET Framework is meant
to be able to be run side-by-side with any other version.

For example, you absolutely need a new version of Excel to be backwards
compatible with previous versions (to a point anyway) because you can't have
multiple versions of Excel installed side-by-side.

MS believes that it will be necessary for systems to need to be able to
handle applications that run on various versions of the Framework, so they
design the Frameworks to exist and execute side-by-side, which eliminates
the need for any one Framework version to have to be backward compatible
with others.

Of course, the downside to this approach is exactly what you are
experiencing, which is that for each new version of the Framework, you'll
need a new version of Visual Studio to work with.

This is why you can't work with 2.0+ in VS 2003.

-Scott

 

[Scott M.]

Hello Alain,

Versions of Studio since 2003 have supported 2.0 onwards.
VS2010 will support .Net 2.0 , 3.0, 3.5 and 4.0

Yes, but of course this means that you must have all of these Frameworks
installed in order to utilize them. So, if someone has a problem with the
approximately 300MB needed for the 2.0, 3.0, and 3.5 Frameworks, then they'd
really have a problem with the additional 393MB for the 4.0 Framework.

A full installation of VS 2010 will install all of these for a total of
800MB needed.

-Scott

 

[Scott M.]

An "evangelist" is someone who *promotes* something, not necessarially one
who defends something. I can defend a criminal in court, but that doesn't
mean I promote the criminal's behavior.
-Scott

Also, I haven't actually even been defending MS or their approach, I've just
been answering your questions.

Sorry! Couldn't resist throwing that in there!!

-Scott

 

[Tom Shelton]

An "evangelist" is someone who *promotes* something, not necessarially one
who defends something. I can defend a criminal in court, but that doesn't
mean I promote the criminal's behavior.


I may be off by a few 10's of megabytes (because the actual size will depend
on your system configuraiton), but I'm quite sure that the installation does
not exceed 400MB (I actually have never seen even this size -- It's almost
always right about 300MB).

I have the full versions of each of the Frameworks (and all available
Framework SP's) on my XP Pro SP 3 system and can tell you definitively that
the installation sizes of approximately:

200MB for 2.0
33 MB for 3.0
30 MB for 3.5

is right in line with, not only what MS documentation says it should be, but
also what others report as well.

Well... It is bigger on a 64-bit OS because it installs both a 32-bit and
64-bit version of the runtime. In fact, the overall install size doubles - my
framework and framework64 runtime directories on windows 7 64-bit are ~240MB
each.

 

[Scott M.]

Well... It is bigger on a 64-bit OS because it installs both a 32-bit and
64-bit version of the runtime. In fact, the overall install size
doubles - my
framework and framework64 runtime directories on windows 7 64-bit are
~240MB
each.

Sure, that makes sense. But, you're still not anywhere near 3.5 GB. You're
probably at about 650-ish MB.

-Scott

 

[Alain Dekker]

Understood. Thanks for that additional insight. I think the idea of removing
unused references is something that VB has been quite good at for a few
versions.

Regards,
Alain

 

[Alain Dekker]

Checking my .NET frameworks on my dev machine, I can report that:
3.0 = 33.2MB
3.5 = 28.0MB

Dammit, I will find out where I got this "3.5GB" number from! Whatever it
was the MS Update website gave me to install definitely took the clone size
over 4.0GB. I hope to report back sometime tomorrow.

Regards,
Alain

 

[Alain Dekker]

Something I don't quite understand here. What exactly does "the framework's
are meant to work side-by-side" mean? If 3.5 is "built on" 3.0 why is it
smaller? Do programs make use of 3.5 as well as 3.0 and 2.0, or just one?

Lets say you had a .NET app that only referenced 3.5. Could you,
hypothetically, delete the v1.8, v2.* and v3.0 folders and the app would run
fine?

I'm showing my ignorance of .NEt here, I'm sure. Its prossibly an ignorance
shared by many a novice .NET programmer.

Thanks,
Alain

 

[Family Tree Mike]

Something I don't quite understand here. What exactly does "the framework's
are meant to work side-by-side" mean? If 3.5 is "built on" 3.0 why is it
smaller? Do programs make use of 3.5 as well as 3.0 and 2.0, or just one?

Lets say you had a .NET app that only referenced 3.5. Could you,
hypothetically, delete the v1.8, v2.* and v3.0 folders and the app would run
fine?

I'm showing my ignorance of .NEt here, I'm sure. Its prossibly an ignorance
shared by many a novice .NET programmer.

Thanks,
Alain

No, 3.0 and 3.5 add things to the base 2.0. You could not delete 2.0's
folder if you only used things in 3.5. As an example, the following code
would write "Green is: Green" when run under 3.5. This is because 3.5
adds System.Linq to do queries, specifically the .Where() method on
Lists. With VS 2008, building this for 2.0, you get an error on this
line, as Linq is not available.

static void Main(string[] args)
{
List<string> colors = new List<string>();
colors.Add("Red");
colors.Add("Green");
colors.Add("Blue");

Console.WriteLine("Green is: " +
colors.Where(c => c == "Green").First().ToString());
Console.ReadLine();
}

 

[Scott M.]

Something I don't quite understand here. What exactly does "the
framework's are meant to work side-by-side" mean?

Well, understanding that 3.0 and 3.5 aren't "stand-alone" Frameworks and
therefore are "special", it means that you can have the 1.0, 1.1, and 2.0
(by itselft), 3.0 (which includes 2.0), and 3.5 (which includes 2.0),
running side-by-side.

It's best to think of all these Framework versions in terms of a version of
the CLR (Common Language Runtime - this is the core engine that processes
your .NET code). There isn't a 3.0 or 3.5 CLR. Both of those Frameworks
use the 2.0 CLR.

So, in terms of unique CLR's there is 1.0, 1.1, and 2.0 and each of these
Frameworks exists independent of each other on your machine. You can run
one .NET application in the 1.0 CLR and another in the 2.0 CLR. You don't
have to worry about the 2.0 CLR being backwards compatible with the 1.x
CLR's because you can just install them in addition to the 2.0 CLR.

If 3.5 is "built on" 3.0 why is it smaller? Do programs make use of 3.5 as
well as 3.0 and 2.0, or just one?

3.5 isn't built on 3.0, it's built on 2.0 and so is 3.0.

2.0 is the key as this is the Framework that has everything it needs to
stand on its own.
3.0 simply adds 3 libraries (WCF, WF, WPF) that run on the 2.0 Framework.
3.5 simply adds 2 major libraries (AJAX & LINQ) along with a few other
enhancements that run on the 2.0 Framework.

Lets say you had a .NET app that only referenced 3.5. Could you,
hypothetically, delete the v1.8, v2.* and v3.0 folders and the app would
run fine?

No. 3.5 and 3.0 are extensions of 2.0. When you install the 3.0 Framework,
it installs 2.0 and when you install the 3.5 Framework, it installs 3.0 and
2.0.

I'm showing my ignorance of .NEt here, I'm sure. Its prossibly an
ignorance shared by many a novice .NET programmer.

This particular topic can take a little while to get straight as most people
I've run into feel that 3.0 (which is just an extension of 2.0) should have
been numbered something more trivial, such as 2.1 and 3.5 (which is yet
another extension of 2.0 and 3.0) should have been numbered something like
2.5. This would have made the whole verioning issue much easier to
understand. But again, if you think in terms of CLR's and know that 3.0 and
3.5 don't include new CLR's, then you get that both of those versions still
need 2.0, which has the CLR for them to run against.

 

[Tom Shelton]

Well, understanding that 3.0 and 3.5 aren't "stand-alone" Frameworks and
therefore are "special", it means that you can have the 1.0, 1.1, and 2.0
(by itselft), 3.0 (which includes 2.0), and 3.5 (which includes 2.0),
running side-by-side.

It's best to think of all these Framework versions in terms of a version of
the CLR (Common Language Runtime - this is the core engine that processes
your .NET code). There isn't a 3.0 or 3.5 CLR. Both of those Frameworks
use the 2.0 CLR.

So, in terms of unique CLR's there is 1.0, 1.1, and 2.0 and each of these
Frameworks exists independent of each other on your machine. You can run
one .NET application in the 1.0 CLR and another in the 2.0 CLR. You don't
have to worry about the 2.0 CLR being backwards compatible with the 1.x
CLR's because you can just install them in addition to the 2.0 CLR.


3.5 isn't built on 3.0, it's built on 2.0 and so is 3.0.

2.0 is the key as this is the Framework that has everything it needs to
stand on its own.
3.0 simply adds 3 libraries (WCF, WF, WPF) that run on the 2.0 Framework.
3.5 simply adds 2 major libraries (AJAX & LINQ) along with a few other
enhancements that run on the 2.0 Framework.


No. 3.5 and 3.0 are extensions of 2.0. When you install the 3.0 Framework,
it installs 2.0 and when you install the 3.5 Framework, it installs 3.0 and
2.0.


This particular topic can take a little while to get straight as most people
I've run into feel that 3.0 (which is just an extension of 2.0) should have
been numbered something more trivial, such as 2.1 and 3.5 (which is yet
another extension of 2.0 and 3.0) should have been numbered something like
2.5. This would have made the whole verioning issue much easier to
understand. But again, if you think in terms of CLR's and know that 3.0 and
3.5 don't include new CLR's, then you get that both of those versions still
need 2.0, which has the CLR for them to run against.

I'm in that camp. They should never have jumped to the 3.0/3.5 version
numbers. 4.0 is going to have a new CLR, but it really should be 3.0 in my
book...

Oh, well, what's done is done.

 

[Rory Becker]

Hello Alain,

Oh, dear. Actually Rory above gave the opposite answer, but yours is
consistent with everything else I've been reading about on the net
today.

Sorry Alan

I realise now my answer was a bit ambiguous.

I meant that the IDEs that have come out since ( ie after) VS2003 are backward
compatible to v2.0

Which is to say that 2005, 2008 and soon 2010 are capable of handling their
respective frameworks and also those preceding frameworks going back to v2.0.

As many have indicated, VS2003 only works with v1.1 of the framework.

Sorry for any confusion.

 

[Rory Becker]

Hello Scott M.,

Yes, but of course this means that you must have all of these
Frameworks installed in order to utilize them. So, if someone has a
problem with the approximately 300MB needed for the 2.0, 3.0, and 3.5
Frameworks, then they'd really have a problem with the additional
393MB for the 4.0 Framework.

A full installation of VS 2010 will install all of these for a total
of 800MB needed.

AFAIK .Net 4.0 provides a new CLR and therefore starts a new dependancy tree.

Which is to say .Net 4.0 does not require 2.0 or 3.0 or 3.5

 

[Rory Becker]

Hello Alain,

Checking my .NET frameworks on my dev machine, I can report that:
3.0 = 33.2MB
3.5 = 28.0MB
Dammit, I will find out where I got this "3.5GB" number from! Whatever
it was the MS Update website gave me to install definitely took the
clone size over 4.0GB. I hope to report back sometime tomorrow.

Regards,
Alain

Could it be that you downloaded an SDK?


This one lists a maximum size of 4GB ... http://www.microsoft.com/downloads/...69-9671-4330-a63e-1fd44e0e2505&displaylang=en

 

[Alain Dekker]

No problem, confusion was cleared up quickly. Had a thought in the shower
this morning, is there an option to write a VS2003.NET (.NET 1.1) app in VS
2008? You can save older Word formats in MS Word, for example. I'm guessing
not (MS want developers to buy new IDEs every couple of years) but thought
I'd ask the question. It would good if you could...

One thing that bugs with with all this "moving with the times" is that
things definitely do NOT monotonically improve with time! Going back in
versions of the IDE, VS6 was an absolute classic, brilliant and deserved its
dominant status. VS2003.NET is very good, I recommend it. VS2005.NET is
poor, and I've heard from several colleagues that while 2008 is better than
2005, it isn't as good as 2003.

Wouldn't it be better to just pay a smaller upfront cost and then a nominal
yearly license fee (for professionals) to MS for bug fixes and new features
(like multi-processor support). This would all be patched into one version
of the IDE (lets say 2003.NET for arguments sake) and then *only* move the
IDE when absolutely neccesary. As a rule, I think new IDEs should only be
released every 5-6 years and stable, good OSes like XP shouldn't move for
double that time, but I'll probably cause some VP at MS a heart attack if he
reads this...

One advantage of keeping the "rug beneath our feet" more stable would be
that we'd actually get to feel the benefits of faster processors.

I use VS2003.NET and don't, unless testing something, actually write managed
..NET code. I just write standard native C++ apps. C++ rocks.

Thanks,
Alain

 

[Alain Dekker]

Thanks for those explanations, Scott. Confusion is clearing rapidly.

Agree with Tom that the versioning of 3.0 and 3.5 has been done incorrectly.

Regards,
Alain

 

[Rory Becker]

Hello Alain,

is there an option to write a VS2003.NET (.NET
1.1) app in VS 2008?

No. Sorry .Net 2.0 is the new line in the sand. Or at least it was 4 years
ago.

VS2005.NET is poor, and I've heard from several colleagues that while
2008 is better than 2005, it isn't as good as 2003.

I also thought VS2005 was poor (stability wise) compared with VS2003.

However I would say that VS2008 (for my purposes at least) is better than
either in almost every way.