copying folders

  • Thread starter Thread starter Jim Madsen
  • Start date Start date
J

Jim Madsen

How do I copy subfolders from one directory to another. I tried
"moveto", but that only moves the subfolders. I only see "copyto" for
files.

Sorry about the novice question. I have VB dotNet 2003.
 
Note: That feature under My namespace is provided
in .NET 2.0 and above, as you're using .NET 1.1 with
VS 2003, you may need a custom function that does it
using System.IO.
Click to expand...

This is worse than than DLL Hell in the real Visual Basic!
 
Note: That feature under My namespace is provided
in .NET 2.0 and above, as you're using .NET 1.1 with
VS 2003, you may need a custom function that does it
using System.IO.
Click to expand...

This is worse than than DLL Hell in the real Visual Basic!
 
This is worse than than DLL Hell in the real Visual Basic!
Click to expand...

really? how? functionality was added in 2.0 that did not exist in 1.1.
seems reasonable to me - since it doesn't break pre 2.0 code...
 
This is worse than than DLL Hell in the real Visual Basic!
Click to expand...

really? how? functionality was added in 2.0 that did not exist in 1.1.
seems reasonable to me - since it doesn't break pre 2.0 code...
 
really? how? functionality was added in 2.0 that did not
exist in 1.1. seems reasonable to me - since it doesn't
break pre 2.0 code...
Click to expand...

But doesn't it force people who write code using the functionality of 2.0 to
force everyone who uses their application to download the massive 2.0
framework, or to distribute it and install it with their app? How does that
work in .net?
 
really? how? functionality was added in 2.0 that did not
exist in 1.1. seems reasonable to me - since it doesn't
break pre 2.0 code...
Click to expand...

But doesn't it force people who write code using the functionality of 2.0 to
force everyone who uses their application to download the massive 2.0
framework, or to distribute it and install it with their app? How does that
work in .net?
 
But doesn't it force people who write code using the functionality of 2.0 to
force everyone who uses their application to download the massive 2.0
framework, or to distribute it and install it with their app?
Click to expand...

Probably, but it doesn't break existing apps. So, again - I don't see any
simularity at all.
 
But doesn't it force people who write code using the functionality of 2.0 to
force everyone who uses their application to download the massive 2.0
framework, or to distribute it and install it with their app?
Click to expand...

Probably, but it doesn't break existing apps. So, again - I don't see any
simularity at all.
 
Mike --

Mike Williams said:
But doesn't it force people who write code using the functionality of 2.0
to force everyone who uses their application to download the massive 2.0
framework, or to distribute it and install it with their app? How does
that work in .net?
Click to expand...

It's almost² the same situation we experienced with different versions of
Classic VB.

An application which made use of functionality included in the VB5 runtime
didn't run on a system which had only the VB4 runtime installed.

-----

² "almost" because the situation is a bit better with .NET than with Classic
VB: An application compiled against the VBn runtime never worked on a
system which only had the VBm (m <> n) runtime installed.

In .NET, there is even some kind of cross-version compatibility. An
application compiled against .NET Framework n will run on systems which have
..NET Framework m (m >= n) installed, and it may run on systems which only
have .NET Framework o (o < n) installed if only the subset of functionality
provided by the "older" version of the .NET Framework is used by the
application. Nevertheless, there are some exceptions to these rules.
 
Mike --

Mike Williams said:
But doesn't it force people who write code using the functionality of 2.0
to force everyone who uses their application to download the massive 2.0
framework, or to distribute it and install it with their app? How does
that work in .net?
Click to expand...

It's almost² the same situation we experienced with different versions of
Classic VB.

An application which made use of functionality included in the VB5 runtime
didn't run on a system which had only the VB4 runtime installed.

-----

² "almost" because the situation is a bit better with .NET than with Classic
VB: An application compiled against the VBn runtime never worked on a
system which only had the VBm (m <> n) runtime installed.

In .NET, there is even some kind of cross-version compatibility. An
application compiled against .NET Framework n will run on systems which have
..NET Framework m (m >= n) installed, and it may run on systems which only
have .NET Framework o (o < n) installed if only the subset of functionality
provided by the "older" version of the .NET Framework is used by the
application. Nevertheless, there are some exceptions to these rules.
 
An application which made use of functionality included
in the VB5 runtime didn't run on a system which had
only the VB4 runtime installed.
Click to expand...

Yes, but the VB5 runtime (and the VB6 runtime) are both less than 2 MB and
are, as far as I am aware, present by default on all standard installations
of Win XP upwards and are in any case easily redistributable. You certainly
cannot say the same for the various variants of the net framework!
In .NET, there is even some kind of cross-version compatibility.
An application compiled against .NET Framework n will run on
systems which have .NET Framework m (m >= n) installed,
and it may run on systems which only have .NET Framework
o (o < n) installed if only the subset of functionality provided
by the "older" version of the .NET Framework is used by the application.
Nevertheless, there are some exceptions to
these rules.
Click to expand...

What you have just described is a complete mess. I would much sooner be
clear on exactly what is required and have a definite "No" instead of all
this "maybe, possibly, yes but only if . . ." stuff. We were promised that
dotnet would fix all the Classic Visual Basic "DLL Hell" for us, but instead
it has just made matters worse. I was rather hoping for a system such as I
believe Delphi to be (or perhaps to have been before they too moved down the
dotnet road) where in Delphi you could compile an app and the compiled exe
would be completely self contained and would run on whatever machine you
threw it at (at least that's how I understood Delphi to have worked). But
Micro$oft have not done that. They have replaced DLL Hell with an even worse
Hell in which everyone in the world has to rely on a fast broadband
connection to the Micro$oft servers for anything to work at all! I suppose
that is to be expected from a company that is heading full speed down the
road to what they believe is their own rental heaven, but it really is very
disappointing.

Mike
 
An application which made use of functionality included
in the VB5 runtime didn't run on a system which had
only the VB4 runtime installed.
Click to expand...

Yes, but the VB5 runtime (and the VB6 runtime) are both less than 2 MB and
are, as far as I am aware, present by default on all standard installations
of Win XP upwards and are in any case easily redistributable. You certainly
cannot say the same for the various variants of the net framework!
In .NET, there is even some kind of cross-version compatibility.
An application compiled against .NET Framework n will run on
systems which have .NET Framework m (m >= n) installed,
and it may run on systems which only have .NET Framework
o (o < n) installed if only the subset of functionality provided
by the "older" version of the .NET Framework is used by the application.
Nevertheless, there are some exceptions to
these rules.
Click to expand...

What you have just described is a complete mess. I would much sooner be
clear on exactly what is required and have a definite "No" instead of all
this "maybe, possibly, yes but only if . . ." stuff. We were promised that
dotnet would fix all the Classic Visual Basic "DLL Hell" for us, but instead
it has just made matters worse. I was rather hoping for a system such as I
believe Delphi to be (or perhaps to have been before they too moved down the
dotnet road) where in Delphi you could compile an app and the compiled exe
would be completely self contained and would run on whatever machine you
threw it at (at least that's how I understood Delphi to have worked). But
Micro$oft have not done that. They have replaced DLL Hell with an even worse
Hell in which everyone in the world has to rely on a fast broadband
connection to the Micro$oft servers for anything to work at all! I suppose
that is to be expected from a company that is heading full speed down the
road to what they believe is their own rental heaven, but it really is very
disappointing.

Mike
 
One advantage of requiring .Net to be installed as opposed to compiling
everything into an executable is that parts can be left out so each app is
smaller. Sure there's more to download to install your first .Net app but
there's less duplication. You can stick with the older version of .Net if
you want your app to be as backward compatible as possible with older
hardware and/or OSs, but the PC trend is to force everyone to upgrade sooner
or later. The latest .Net does run on Windows XP which most people should
have by now. Many programs (Turbo Tax for one) already require Windows XP.
I don't know what the size is of the latest .Net download but a lot of (if
not most) people already have broadband access, Obama promised to get
broadband access to all Americans, and you can download anything even on
dialup (it'll just take a lot longer). Of course, again, once they get the
..Net framework installed, the apps themselves should be smaller to download.
If you'd rather save a lot of space, make everything backward compatible,
and give yourself more headaches to write the programs, stick with
assembler.
 
One advantage of requiring .Net to be installed as opposed to compiling
everything into an executable is that parts can be left out so each app is
smaller. Sure there's more to download to install your first .Net app but
there's less duplication. You can stick with the older version of .Net if
you want your app to be as backward compatible as possible with older
hardware and/or OSs, but the PC trend is to force everyone to upgrade sooner
or later. The latest .Net does run on Windows XP which most people should
have by now. Many programs (Turbo Tax for one) already require Windows XP.
I don't know what the size is of the latest .Net download but a lot of (if
not most) people already have broadband access, Obama promised to get
broadband access to all Americans, and you can download anything even on
dialup (it'll just take a lot longer). Of course, again, once they get the
..Net framework installed, the apps themselves should be smaller to download.
If you'd rather save a lot of space, make everything backward compatible,
and give yourself more headaches to write the programs, stick with
assembler.
 
Mike Williams said:
Yes, but the VB5 runtime (and the VB6 runtime) are both less than 2 MB and
are, as far as I am aware, present by default on all standard
installations of Win XP upwards and are in any case easily
redistributable. You certainly cannot say the same for the various
variants of the net framework!
Click to expand...

Well, but distribution of the Classic VB runtime was a problem when PCs
didn't have an internet connection and software was distributed primarily on
floppy disks back in the last decade.
What you have just described is a complete mess. I would much sooner be
clear on exactly what is required and have a definite "No" instead of all
this "maybe, possibly, yes but only if . . ." stuff.
Click to expand...

Well, I just didn't want to go into detail. There is definitely no "No"
because the compatiblity I described is defined ("by design") behavior.
We were promised that dotnet would fix all the Classic Visual Basic "DLL
Hell" for us, but instead it has just made matters worse. I was rather
hoping for a system such as I believe Delphi to be (or perhaps to have
been before they too moved down the dotnet road) where in Delphi you could
compile an app and the compiled exe would be completely self contained and
would run on whatever machine you threw it at (at least that's how I
understood Delphi to have worked). But Micro$oft have not done that.
Click to expand...

DLL hell in the days of Classic VB was not a VB-only problem. It has been
caused by the operating system which didn't provide sufficient mechanisms
for DLL versioning and loading. This has changed in the meantime, and
Windows XP and newer versions of Windows allow XCOPY deployment of almost
self-contained packages of files (EXE, DLL, OCX, ...). Windows now contains
even something like an unmanaged GAC (WinSxS). That's all not really
related to Classic VB.
 
Back
Top