Re: VS 2005 questions

> A developer should have at least one machine that has at least 30 or 40 GB
of hard drive space on it. I have 3. A good developer likes to collect
tools, not throw them away. And a developer who works with "legacy" software
should have the tools to work with that software.

yes, I have an 80 gig hard drive on my laptop and recently filled it. After
a year or so I ended up cluttering my hard drive from day to day use, which
sometimes includes installing apps that I only need for a month. So I moved
all of my files over to my fileserver and did a fresh reinstall. Now I am
only using a third of my hard drive after putting only essential software and
files on my laptop. Some of the essential development apps I've installed
include Macromedia Studio and Eclipse. I applaud Microsoft for the level of
backward compatibility they have achieved with VS 2005, but I still find it a
legitimate complaint that it is incomplete. Microsoft is not the only one
guilty of forcing developers to install legacy versions of their software.

For example, when Macromedia introduced actionscript 2.0 in Flash MX 2004,
they went from object based to object oriented code. I won't go back. If I am
handed Actionscript 1.0 code, I will convince the client that the code needs
to be upgraded and develop it in the latest version of the Flash IDE or hand
the job off to a contractor. I do this for three reasons (in order of
importance):
1) AS 1.0 code is a kludge to work with compared to 2.0
2) MM will soon deprecate AS 1.0 code
3) I don't want the overhead of a legacy app on my laptop hard drive

Likewise, if a client wants me to develop VB6 code, I won't do it on my
laptop, I will install VS 6.0 on an expendable hard drive on one of my
desktop machines to compile and won't do any real version 6 development
myself. It would be a disservice to my clients to do this since MS will
deprecate support for 6.0 within a year. In the case of .net 1.x versus 2.0,
it's simply too early to take such and attitude and the difference in code
development is not so radically different. So there is only one reason to be
disappointed with VS 2005: the hard drive overhead of having VS 2003
installed (I realize this is relatively minor and love everything else about
it). Simply put, the more space used on the hard drive, the slower the
computer works. So since my laptop is my development box and not my
fileserver, anything even slightly extraneous on the hard drive constitutes
'clutter' in my mind.

Hopefully by the time the next Visual Studio comes out, I will only have to
install one IDE for Microsoft development. I'm glad to know that I'm not the
only one looking forward to being able to install only one Managed code IDE
and that Microsoft finds this a high priority.

Mikhail, thank your for your thorough explanation. I can appreciate what a
tall order this is much better now.




"Mikhail Arkhipov (Microsoft)" wrote:

> On 10/30/05 8:09, in article O39UsPW3FHA.3000@xxxxxxxxxxxxxxxxxxxx, "Kevin
> Spencer" <kevin@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> > I suppose I can see your point, and even understand your annoyance. However,
> > I disagree with the "clutter" idea. I am just trying to derive Microsoft's
> > logic here, but let me see if I can explain this correctly.
> >
> > If you built a .Net Framework 1.1 app for a client, you used Visual
> > Studio.Net 2003 to do it. If you want to develop a .Net Framework 2.0 app,
> > you will need Visual Studio.Net 2005 to do it. So far, nothing is different
> > from the "traditional" model of development. Development software cannot be
> > "forwards-compatible."
> >
> > So, at least at one point, you had the earlier development software
> > installed on your system. Now, you say that a developer might uninstall
> > Visual Studio.Net 2003 to avoid "clutter" on their system. This argument,
> > while intriguing on the face of it, doesn't really hold water. We're not
> > alking about an AOL user. We're talking about a developer.
> >
> > A developer should have at least one machine that has at least 30 or 40 GB
> > of hard drive space on it. I have 3. A good developer likes to collect
> > tools, not throw them away. And a developer who works with "legacy" software
> > should have the tools to work with that software. I have Visual Studio 6 on
> > my development machine at work, for just that purpose. I also have dozens of
> > other Microsoft development tools and third-party development tools
> > installed on my dev machines. You might say that my dev machines are
> > "cluttered" with development software. You might even call me a "collector"
> > of tools. But again, I see that as a good practice.
> >
> > Now, while a developer who has *not* built a .Net Framework 1.1 application
> > would not necessarily have or need Visual Studio.Net 2003 on their machine,
> > neither would they need it, unless they took on a job working on one
> > developed by someone else, prior to them. On the other hand, if a developer
> > *has* built a .Net Framework 1.1 app, he/she would have, or have had, a copy
> > of Visual Studio.Net 2003 on their dev box. So, assuming that there is no
> > hard drive space issue (which there should not be), and assuming that
> > "clutter" is a subjective quantitative evalutation (which it is), I can only
> > think of one scenario which would cause an issue here, and that is the
> > scenario of a developer who takes on new work with an existing app that the
> > developer did not write.
> >
> > Now, as to that scenario: If that legacy app was written with VB6, the
> > developer would have to buy Visual Studio 6 to work on it. So, what's the
> > difference between having to buy Visual Studio 6 to work on a Visual Studio
> > 6 app that one did not create in the first place, and having to buy Visual
> > Studio.Net 2003 to work on a Visual Studio.Net 2003 app that one did not
> > create in the first place?
> >
> > Again, I agree that it would be *convenient* for Visual Studio.Net 2005 to
> > be able to work on legacy apps built with Microsoft programming
> > technologies, all the way back to BASIC, perhaps, why not? But necessary?
> > No. Therefore, it is not "wrong" that it does not.
> >
> > If you find it annoying, well, I can't find fault with that. One is annoyed
> > by whatever one is annoyed by. I am annoyed by lots of things, many of which
> > are simply annoying to me, whether or not they are legitimate. And your
> > annoyance is certainly legitimate as a feeling. In any case, your annoyance
> > is not annoying to me. ;-)
>
> As a matter of fact, using newer versions of VS to work on older versions of
> ..NET is a very popular request and we, in fact, are taking the feedback very
> seriously. Unfortunately, there are hard architectural problems that must be
> to be solved in order to make this happen. Here is a brief outline.
>
> In order to be able to debug managed code and instantiate managed controls
> (which is needed in Windows Form designer, Web Form designer, Class
> designer, XML Data/Schema designer, etc), VS itself is partially written in
> the managed code. We also know that in many cases managed code development
> is more efficient than C++ development so some teams use managed code quite
> extensively, especially when developing new components. Therefore when VS
> 2005 is running, .NET 2.0 CLR and 2.0 Framework is loaded into the VS
> process space and into the main VS app domain. All designers are running in
> the same main VS app domain. Property grid is talking to managed control
> instances so it must be in the same app domain.
>
> The issue here is that CLR is able to load only one framework into the same
> app domain. You do can use 1.1 assemblies and custom controls, but, for
> instance, System.Web.dll from 1.1 cannot be loaded into VS 2005 since
> System.Web.dll from .NET 2.0 is already loaded into the VS app domain.
>
> In order to make VS 2005 to support 1.1 development either all managed code
> in VS had be limited to 1.1 features (which would seriously limit VS
> functionality and would make development of the VS itself must less
> efficient) or designers had to be running in separate app domains (which
> would make managed/native interop more difficult and much less efficient),
> or CLR must allow loading of multiple frameworks into the same app domain.
> The latter is probably the best solution, but requires significant
> architectural work in the CLR.
>
> Jason Zander ( http://blogs.msdn.com/jasonz ) is CLR unit manager, he is the
> best person to talk to if you want more information.
>
> Again, we know about your feedback and supporting multiple versions of .NET
> is definitely high in our list of things to do. However, I obviously can't
> promise when exactly it will happen.
>
> Thanks
> Mikhail Arkhipov (Microsoft)
> -- This post is provided 'AS IS' with no warranties and confers no rights
>
>
.

Relevant Pages

  • Re: Cannot find sqlce.wce4.arm.cab
    ... I am loading from visual studio and get the ... and then get a deployment error message in visual ... > my app and I get this message"...how are you trying to install the app? ...
    (microsoft.public.sqlserver.ce)
  • mobile 5 developer error
    ... I have installed the mobile SDK to visual studio 2005 std. ... If I create a simple app it will not install to the PC2005 device or the ...
    (microsoft.public.pocketpc.developer)
  • Re: VB 6, Visual Studio .NET etc?
    ... > A PC would need the .NET software on it to be able to install an app ... Studio.Net and doesn't exist in Visual Studio 6.0. ...
    (microsoft.public.vb.general.discussion)
  • Re: eVC++4.0 and target SDK
    ... I suspect that the SDK that you installed only supports Managed Code ... I just started to create an app for a Windows CE5.0 system with AMD CPU. ... when I tried to install the target SDK, ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: Error while installing Micro Focus Net Express
    ... If you don't need Visual Studio integration or the ability to create managed code, then during the Net Express installation, when you get to the page of the installation wizard for selecting components to install, deselect "Net Express support for .NET" (the first component). ...
    (comp.lang.cobol)
Loading