Re: VS 2005 questions

It's good to know that you're working on that feature, Mikhail. You guys
definitely aim to please!

Meanwhile I have no complaints. I have been nothing but dumbfounded by the
Visual Studio.Net software, particularly the latest version. You guys
deserve a huge pat on the back (and a raise!).

--
Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

"Mikhail Arkhipov (Microsoft)" <mikhaila@xxxxxxxxxxxxxxxxxxxx> wrote in
message news:BF8A4D3C.1785C%mikhaila@xxxxxxxxxxxxxxxxxxxxxxx
> 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: The curse of constant fields
    ... production branch, EAR construction etc) for a reasonably important J2EE app I am pretty fanatic about sanitizing everything prior to an official build. ... our environment it would be unrealistic. ... Because a lot of time can be wasted if a tester reports that an error is still there, and then it's a question of is the error still there because the build is flawed, or because the developer who "fixed" it only fixed it for a different use case or in his own development environment. ...
    (comp.lang.java.programmer)
  • Re: Are ASP.NET user interfaces essentially dead now?
    ... How does "clickonce" solve the problem up version updates? ... takes longer to develop ASP.NET interface than a windowsform app ... > developer can choose how they want to communicate -- direct to SQL ... using winforms requires that the client has the .NET framework ...
    (microsoft.public.dotnet.framework.aspnet)
  • Apples FCC Response Infuriates Google Voice App Developer
    ... Apple's FCC Response Infuriates Google Voice App Developer ... He also suspects Apple is being more ...
    (comp.sys.mac.advocacy)
  • Re: Are ASP.NET user interfaces essentially dead now?
    ... proper care and then there is jumping thru hoops, you want to avoid the hoop ... takes longer to develop ASP.NET interface than a windowsform app ... developer can choose how they want to communicate -- direct to SQL servers, ... I see Winforms doing the major amount of interface work and leaving the web ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Versions of .net + visual studio
    ... you do not spend a penny to develop .NET app: ... If you are dedicated/professional .NET developer, ... installtion/coexistence comes in. ... Installing later version of .ENT Framework does not ...
    (microsoft.public.dotnet.framework)
Quantcast