Conversion from 2008->2003?

[Alain Dekker]

Hi,

We're working with a customer of ours who has written a test VB app in VS
2008.NET. We use VS 2003.NET and do not want to install 2008. A couple of
comments and questions:

* How can I convert the 2008 project into 2003?
* If thats not possible, can he convert from 2008 format to 2003 format and
resend?
* If we don't want to move from 2003 (we're happy with it) can we work
together? Should we just let them write the app completely and we just work
with it?
* How do I determine what version of .NET is required? Our target computers
have limited hard disk space and 3.5 is so bloated that we cannot install it
at all. In fact, we will not use .NET higher than 2.0. How to tell what is
required?
* Is it easy enough in 2008 to change the .NET framework required?

Many thanks,
Alain

 

[Scott M.]

Hi,

We're working with a customer of ours who has written a test VB app in VS
2008.NET. We use VS 2003.NET and do not want to install 2008. A couple of
comments and questions:

* How can I convert the 2008 project into 2003?

There is no automatic way to do it. You'd have to get rid of the solution
and project files (as they no longer conform to the 2003 configuration) and
manually modify the source code files to be compatible with 2003 code.
Also, if the 2008 project relies on any 2.0 or higher assemblies, then you
cannot go back to 2003.

Assuming absolutely nothing from the 2.0 and up Frameworks, you should
create an empty solution in 2003 and import just the source code files,
remake any necessary references (only references to .NET 1.x assemblies) and
then go through and fix each compile error you encounter.

* If thats not possible, can he convert from 2008 format to 2003 format
and
resend?

He'd have the same problems as you would.

* If we don't want to move from 2003 (we're happy with it) can we work
together?

No. If some of the code is being compiled against the 3.5 Framework,
everyone on the team must have 3.5.

Should we just let them write the app completely and we just work
with it?

If you mean should you just upgrade to 3.5 so that you can work with what
they are sending you, then probably, yes because you cannot work with the
2008 stuff they are sending you unless you have 2008.

* How do I determine what version of .NET is required?

You can look at the project file(s) and see what versions of the .NET
Framework assemblies are being referenced. If you see anything that is
version 3.5, you need the 3.5 Framework.

Our target computers have limited hard disk space and 3.5 is so bloated
that we cannot install it
at all.

If that's the case, then you have other problems. Since the 3.5 Framework
requires about 300MB and you are saying you can't install something of that
size, you development hardware is very much out of date. 300MB is nothing
in today's world.

In fact, we will not use .NET higher than 2.0.

Do you realize that the 3.0 and 3.5 Frameworks are really just additions to
the 2.0 Framework? 3.x just runs "on top" of 2.0. It is the 2.0 Framework
that is about 215MB on disk. 3.0 is about 33MB and 3.5 is about 30MB.

If you are going to install the 2.0 Framework, then you have already taken
the "plunge", now it's only about 60MB that is required to go to 3.5.

How to tell what is required?

Same answer as before.

* Is it easy enough in 2008 to change the .NET framework required?

The New Project Dialog box in VS 2008 allows you to pick which version of
the Framework you want to "target" with your new project. It allows you to
choose from 2.0, 3.0, and 3.5. Depending on the one you choose, you will
only be allowed to pick a project template that is compatible with that
Framework version and you will only get references to assemblies that are
compatible with that version.

I can understand if you've got some technical/architectural reason not to go
to 3.5 and VS 2008, but if your only reason is you don't want to install the
Framework, I think you either are misinformed about the size/requirements of
3.5 or need to upgrade your development hardware.

The fact is that if you stay on 1.1, you won't get to use any of the
following:

Windows Communication Foundation
Windows Workflow
Windows Presentation Foundation
Generics
LINQ
ASP .NET AJAX
Extension Methods
Lamda Expressions
Anonymous Functions
ASP .NET Membership & Roles

Not to mention the hundreds of new and improved classes that make
development easier, secure, and robust.

By the way .NET 4.0 and VS 2010 is in beta 2 right now and will be coming
out on 3/22/10.

-Scott

 

[Family Tree Mike]

Hi,

We're working with a customer of ours who has written a test VB app in VS
2008.NET. We use VS 2003.NET and do not want to install 2008. A couple of
comments and questions:

* How can I convert the 2008 project into 2003?
* If thats not possible, can he convert from 2008 format to 2003 format and
resend?
* If we don't want to move from 2003 (we're happy with it) can we work
together? Should we just let them write the app completely and we just work
with it?
* How do I determine what version of .NET is required? Our target computers
have limited hard disk space and 3.5 is so bloated that we cannot install it
at all. In fact, we will not use .NET higher than 2.0. How to tell what is
required?
* Is it easy enough in 2008 to change the .NET framework required?

Many thanks,
Alain


.

First, Scott's comments reply is right on.

I have to ask though, whether the customer has noted problems with your code
running under .net 3.5. If you are just assuming a problem, that may not
necessarily be so.

I want to throw out another possibility for your customer and you. Is it
possible for you and the customer to meet in the middle at .net 2.0? It may
be a smoother transition for you, and they may not be using features of 3.5.

Your scenario sounds a little strange to me though, but maybe I live in a
strange world. Your "customer" is testing with a completely different
framework than you? Who (your company or the customer) is providing the
specifications?

Mike

 

[Alain Dekker]

Thanks Scott.

I looked in the AssemblyInfo.vb file he sent as part of the 2008 project:

Assembly: AssemblyVersion("1.0.*") // taken from AssemblyInfo.vb

Does that mean only 1.1 is required? What exactly does it mean that 2008
only supports 2.0 or higher? Does it mean that even the simplest app will
*always* require .NET 2.0 or higher installed?

The last time I looked at Micrsoft .NET 3.5 on the Microsoft Update website,
it was 3.5GB, not 30MB. We need to clone the entire OS onto a flash card
that is 4.0GB, preferably under 2.0GB because of the way we reclone systems.
I accidentally installed .NET 3.5 when making the latest clone and when we
ghosted it into a drive image, it exceeded what we could put on the flash
card.

I redid the entire clone (a half days work so was not happy) and this time
did not install .NET 3.5 and it easily fitted onto the flash disk (less than
half the size if I remember correctly).

One problem with the hordes of .NET evangelists is that they happily tell
you every new piece of functionality in .NET is making things "more robust",
"more secure", "moving with the times". Probably true some of the time but
also disingenous. More complexity means higher maintenance and development
costs, leaving aside the issue of bugs in the actual functionality. Even if
3.0 and 3.5 require "only" 60MB if installed optimally, it does mean that
calling one thing that requires 3.5 means an extra 60MB of data.

And sure, its easy to say its "nothing in the modern world" but thats also
disingenuous. Firstly, some people have legitimate reasons for keeping
binaries as small and as fast as possible. High speed imaging applications
for one. Many people have perfectly legitimate reasons for not wanting to
buy a whole new computer which ran XP SP2 fine until SP3 came along. A
perfectly legitimate reason for keeping binary sizes down is that you might
use a Windows 98 tool (we do for recloning from ghost images) that has an
upper limit of binary sizes. Another legitimate reason is that you might
have an installed base of hundreds or thousands or even millions of
computers that need updating. They are fast, powerful computers...but every
time .NET "moves on" it shifts the goalposts. Surely an intelligent .NET
evangelist can at least understand the point. Secondly, its not nothing. It
all adds up.

I think bottom line is .NET and its increasingly bloated frameworks is a bad
move for the computing industry and when the dust has settled a few years
from now, I think you'll find a lot of developers will have stuck with fast,
proven native programming or even ditched MS altogether. I am one developer,
a keen Windows developer with over 10 years experience, who has been more
than a little sickened and disheartened with the way .NET has swamped the
landscape. I'm not looking to ditch MS or Windows but I'd like a little more
consideration from them for the loyalty and evangelism (and cash I've handed
over!) I've given them over the years. And there are increasing numbers who
feel just like I do.

Thanks for the answers to the other questions. I'll be asking the customer
what features are required and to check whether 3.0 or 3.5 is actually
required. As its a fairly simple proxy app (to communicate between my app
and a low-level PLC in their system) I hope not.

Many thanks,
Alain

 

[Simon Whale]

have a look at this they discuss the framework sizes for application
deployment

http://stackoverflow.com/questions/6440/net-3-5-redistributable-200-mb-other-options

Simon

 

[Alain Dekker]

Hi Mike,

I think we might be able to meet in the middle at .NET 2.0, though its
unclear to me whether VS 2003.NET will support 2.0. I'll find that out
separately.

Our machine is standalone, in a food production line. It needs to get
information from their ModBUS PLC via an ethernet link, but their PLC has
problems communicating over standard TCP/IP (WinSock) and we have trouble
understanding ModBUS (never used it before, and of the hundreds of
installations this is the first using ModBUS).

We're thinking the best approach is to have something "in the middle", a
kind of proxy, that will communicate with the ModBUS PLC on one side and
with the production machine on standard TCP on the other. This the test
application that arrived today written in VS 2008.NET (a VB app) which I
cannot open.

On my development machine, I can have whatever I want including .NET 3.0 and
3.5, but for reasons explained elsewhere, would prefer not to install the
latest version of .NET on the target system. In fact, its unclear to me why
we have to use .NET at all. As I'm not a fan of .NET that is my preferred
approach, but I'm prepared to meet part-way. The basic specification is the
exchange of long strings of simple alphanumeric codes specifying the product
about to be inspected, the result of that inspection, and so forth, but what
is changing from the customer's side is how those strings will be
communicated back and forth from our machine. Even the formatting is not cut
and dried yet.

It might end up that this proxy app sits on a separate computer altogether
on their network (not on our machine) in which case in can use .NET 3.5
without any issue.

The whole situation is being complicated by the 12 hour time difference as
well, but thats another issue!

Thanks and regards,
Alain

 

[Scott M.]

Thanks Scott.

I looked in the AssemblyInfo.vb file he sent as part of the 2008 project:

Assembly: AssemblyVersion("1.0.*") // taken from AssemblyInfo.vb
Does that mean only 1.1 is required?

Your should not be looking at the AssemblyInfo.vb file for the assemblies
that are required by the project. This file gives you information about
YOUR project. When it says 1.0.*, it's talking about what version number
YOUR finished product will have.

You need to look at the project file for the project in question. A project
file is a file that ends with .vbproj (VB) or .csproj (C#). This file will
list several assembly names along with with version numbers for those
assemblies.

What exactly does it mean that 2008 only supports 2.0 or higher? Does it
mean that even the simplest app will *always* require .NET 2.0 or higher
installed?

Yes. Any applications and libraries you create using Visual Studio 2008
will require, at a bare minimum, the 2.0 Framework.

The last time I looked at Micrsoft .NET 3.5 on the Microsoft Update
website, it was 3.5GB, not 30MB.

No, that's incorrect. First, you've got to understand that when people say
the 3.0 or 3.5 Framework, it is understood that they are talking about the
2.0 Framework with 3.0 or 3.5 added on top of it. The 2.0 Framework has the
meat and potatoes that is necessary for basic functionality of any .NET
assembly, but 3.0 adds libraries for Windows Communication Foundation,
Windows Presentation Foundation, and Windows Workflow. That's it for 3.0.
So, in the strictest sense, the 3.0 Framework only adds about 33MB to the
required 2.0 Framework. The 3.5 Framework adds support for ASP .NET AJAX
and LINQ which again sits on top of the 2.0 Framework.

To install the entire 3.5 Framework (2.0, 3.0, and 3.5) you need about 300MB
of disk space (although, the following link says you need 500MB). You can
download it via:

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

We need to clone the entire OS onto a flash card that is 4.0GB, preferably
under 2.0GB because of the way we reclone systems. I accidentally
installed .NET 3.5 when making the latest clone and when we ghosted it
into a drive image, it exceeded what we could put on the flash card.

Ok, I understand that, but I think your going to find that limiting yourself
to 4.0 GB is going to put you into a corner that is hard to get out of.
Nonetheless, the 3.5 Framework is not in the GB's, it's in the MB's.

I redid the entire clone (a half days work so was not happy) and this time
did not install .NET 3.5 and it easily fitted onto the flash disk (less
than half the size if I remember correctly).

If you are saying that what you installed was nearly 2.0 GB in size, then
you are installing something other than the .NET Framework.

One problem with the hordes of .NET evangelists is that they happily tell
you every new piece of functionality in .NET is making things "more
robust", "more secure", "moving with the times". Probably true some of the
time but also disingenous. More complexity means higher maintenance and
development costs, leaving aside the issue of bugs in the actual
functionality. Even if 3.0 and 3.5 require "only" 60MB if installed
optimally, it does mean that calling one thing that requires 3.5 means an
extra 60MB of data.

True, but it can also be said that if you continue to stay with some older
Framework, that you now don't get the opportunites to utilize advances in
technology. The simplest example I can think of is with multi-core
machines. .NET 1.x has nothing in it to take advantage of these processors,
which means that if you build a 1.x application and run it on a multi-core
machine, your particluar application won't run any more efficiently than
with a single core processor.

So, in the end, you've got to decide if you want to stay stagnant or take
advantage of new ideas and technologies as they come around. This doesn't
mean you have to be on the bleeding edge of technology though.

And sure, its easy to say its "nothing in the modern world" but thats also
disingenuous. Firstly, some people have legitimate reasons for keeping
binaries as small and as fast as possible.

There is no reason that a .NET 3.5 assembly can't be small and fast. In
fact, that is the whole point of expanding and improving the Framework. In
the old days, we used to have to bloat up our applications with utilitarian
code that didn't really have anything to do with the business reason we were
creating the application in the first place. Now, much of that utilitarian
code is in the Framework and doesn't have to be repeated over and over again
in each application you write.

High speed imaging applications for one. Many people have perfectly
legitimate reasons for not wanting to buy a whole new computer which ran
XP SP2 fine until SP3 came along.

I'm not aware of any hardware requirements that XP SP 2 or 3 has that would
not be compatible with a machine that is currently running XP.

A perfectly legitimate reason for keeping binary sizes down is that you
might use a Windows 98 tool (we do for recloning from ghost images) that
has an upper limit of binary sizes. Another legitimate reason is that you
might have an installed base of hundreds or thousands or even millions of
computers that need updating. They are fast, powerful computers...but
every time .NET "moves on" it shifts the goalposts. Surely an intelligent
.NET evangelist can at least understand the point. Secondly, its not
nothing. It all adds up.

I'm not sure how to respond there. First, I don't think I'm evangelizing
anything here, I'm just answering your questions. The only *opinion* I've
offered is that if you can't afford to add 300MB to your .NET development
platform, then that platform isn't sufficient for .NET development.

If you have a need or desire to be backwards compatible with Windows 98 (or
DOS for that matter) that's your buisiness, but your post is clear evidence
that you are now paying the price for the need to stay with these older
hardware and software requirments.

I think bottom line is .NET and its increasingly bloated frameworks is a
bad move for the computing industry and when the dust has settled a few
years from now, I think you'll find a lot of developers will have stuck
with fast, proven native programming or even ditched MS altogether. I am
one developer, a keen Windows developer with over 10 years experience, who
has been more than a little sickened and disheartened with the way .NET
has swamped the landscape. I'm not looking to ditch MS or Windows but I'd
like a little more consideration from them for the loyalty and evangelism
(and cash I've handed over!) I've given them over the years. And there are
increasing numbers who feel just like I do.

Ok, that's your personal perception and you are entitled to it.
Unfortunately, it doesn't change the way .NET is set up or the requirements
for its use. I'm simply telling you how it works, I'm not advocating
anything.

Thanks for the answers to the other questions. I'll be asking the customer
what features are required and to check whether 3.0 or 3.5 is actually
required. As its a fairly simple proxy app (to communicate between my app
and a low-level PLC in their system) I hope not.

Many thanks,
Alain

Sure. Good luck Alain!

 

[Scott M.]

Hi Mike,

I think we might be able to meet in the middle at .NET 2.0, though its
unclear to me whether VS 2003.NET will support 2.0. I'll find that out
separately.

VS 2003 does not support the 2.0 Framework. You'll need VS 2005 or 2008 for
that.

-Scott

 

[Alain Dekker]

Thanks. Interesting to know about. VS 2010.NET will possibly have a minimum
..NET version of 4.0 or something like that so sticking to targetting 2.0 is
only a temporary solution.

It is good to know that there are some tools to help keep the bloat down,
but it seems to me that its not a permanent solution. For example, if you
determine a subset of namespaces and classes from the full .NET 3.5 is
required and install only those, you've not solved the problem of a new .NET
app that uses a namespace or class you didn't know about when you did the
bootstrapping. A lot of people will not want to risk that problem and will
just install the full 3.5 framework, in other words masses of bloat and
waste.

As Jeremy Privett points out in that article on stackoverflow.com, .NET 3.5
has meant downloading (and supporting) a simple app is no longer quick and
painless.

Some .NET evangelist will probably point out that once you've got the 3.5
binaries installed and compiled on the target computer it'll all be
fine...but you'll then have at least 30MB+ of new binaries on the target
computer and you're not future-proofed against the next installment of .NET.
Once 4.0 comes out or 3.5 SP2 you'll have the same problems all over again.

For myself, I like .NET less the more I learn about it. I say we should dump
..NET and stick with native programming, yes Win32 or Win64 native
programming. Heresy I know, but as you can see I haven't been struck by a
bolt of lightning.

Thanks,
Alain

 

[Rory Becker]

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

 

[Alain Dekker]

Thanks!

 

[Alain Dekker]

Hi Scott,

Thanks, found the vbproj file for the target application and you're right,
it says in good 'ol plain ASCII text:

<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>

so I guess that answers my question. Next question is whether we can move
back to more standard 2.0 or I'll have to move to 2008 or we'll go another
route, like maybe putting the app on a separate computer.

I take your point about .NET 2.0 v 1.x and multi-core processors. Good
point. You can of course work with multi-core libraries in native
programming and the MS C++ libraries, of course.

Thanks again for your answers,
Alain

 

[Scott M.]

have a look at this they discuss the framework sizes for application
deployment

http://stackoverflow.com/questions/6440/net-3-5-redistributable-200-mb-other-options

Simon

Just keep in mind that that thread discusses the "deployment" size to the
client. For development, you'd still need the full Framework.

-Scott

 

[Alain Dekker]

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

 

[Scott M.]

Hi Scott,

Thanks, found the vbproj file for the target application and you're right,
it says in good 'ol plain ASCII text:

<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>

so I guess that answers my question. Next question is whether we can move
back to more standard 2.0 or I'll have to move to 2008 or we'll go another
route, like maybe putting the app on a separate computer.

Keep looking at that .vbproj file for the list of individual assemblies and
their versions. It may be that even though the TargetFramework attribute
says 3.5, that in reality, none of the 3.5 assemblies are used, only 2.0
assemblies. That will tell you if you can go with just 2.0.

But remember, going to 2.0 is where you'll take most of the hard disk hit
(about 200MB), so if you're into 2.0 for a penny, you might as well be into
3.5 for a pound (well, 60MB more anyway). Then you're covered for whatever
your client throws at you.

If you want to work with 2.0, then you'll have to move to, at least VS 2005,
so you might as well go to 2008 where you can use 2.0, 3.0, or 3.5.

-Scott

 

[Alain Dekker]

OK, thanks. I understand. Actually I'm perfectly content to install the
latest .NET and SPs for development (though almost 100% of my code is
actually native, written in standard C++/Delphi/VB). I'll even upgrade the
hardware/memory if required as time goes by. Its the deloyment side of
things that concerns me here.

 

[Alain Dekker]

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

 

[Alain Dekker]

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".

I'm not sure the 200MB / 60MB limits you mention are correct. 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 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.

Regards,
Alain

 

[Family Tree Mike]

Thanks!




.

I believe that Rory uses the word "since" to mean "after". VS 2003 will not
support .net 2.0.

Mike

 

[Alain Dekker]

Yes, I see my mistake now. Confirm that I understand that VS 2003.NET won't
work with .NET 2.0 and the changes made in WinForms and other .NET classes.

Thanks Mike.
Alain