"Richard Grimes [MVP]" <read my sig> wrote in message
This is the so-called 'XCOPY deployment'. It works in some cases, but there
are far too many cases when it does not apply, so I regard 'XCOPY
deployment' as Microsoft hype.
I'd have to disagree with the disagreement. True, there are cases where
you'd have to register your .Net dlls with the GAC, and true - when doing
interop with ActiveX the registration becomes even more of a pain than it
used to be. However, when doing pure .Net, the xcopy deployment, for me,
turned out to be most convenient and working suprisingly flawlessly. If you
take for example Desktop applications, Console applications and even ASP.Net
applications, the xcopy thing is just plain WORKING. The first time I took
all of my files in an ASP.Net application and just dumped them over the old
ones, only to watch everything working flawlessly afterwards, it felt like I
just got the bar;bar;bar on the slot machine!
This is true of C# too. The OP does not mention the .NET language that will
be used.
...and neither did I...
- increased security, your code is tamperproof, it won't run code that has
not been specified as trusted by your machine's addministrator. 'Trusted' is
fine grain, so there are levels of trust. Code access security checks the
execution stack, so if your code is trusted but is called by untrusted code
the privileged action will be prevented, if your trusted code calls
untrusted code, their privileged actions will be prevented.
Thanks for the addition, although I found that in many cases these new
features serve as a burdon on the new .Net programmer, rather than an
advantage. (and then you hear the smart puppy go "I just went into the
wizard and gave all the assemblies in the world full trust", which kind of
defeats the purpose in my mind).
But please be aware that VB.NET is not VB. You cannot compile VB classic
code under the VB.NET compiler and there are so many other differences that
is is not fair to say that moving from VB classic to VB.NET is simple. It is
not, and you'll find that moving to C# is no more effort. I write in C#,
VB.NET and managed C++, learning .NET was the most important bit, the actual
dialect of the language wasn't too hard (although I admit for most managed
C++ will be a bit harder to learn than the other .NET languages).
I have found that MS agrees with your approach, but they only reached to
this enlightment much later in the process of developing .Net. I have
therefore found that the best articles for people who want to know "what's
new" in .Net are those Dr. GUI type articles that were written when VB.Net
was still known as "the next version of VB" or VB7. In those articles they
just bring out plain differences between VB6 and VB.Net, without going
through what I personally consider as a lot of buzz-words describing why
VB.Net is NOT the next version of VB6, but rather a new language. Let's be
honest - if you're a VB6 programmer (who doesn't regularly write in C, C++,
Java, etc.), you simply don't want to hear this "new language" talk while
you're trying to gain some progress in your carreer and move on into the
future.
--itai