Re: Goodbye and Best Wishes

From: Craig Stuntz [TeamB] (cstuntz_at_nospam.please)
Date: 02/17/04 

Date: 17 Feb 2004 06:14:20 -0800

Eric Grange wrote:

> > This is *not true.* If I create an assembly using, say, the 2.0
> > framework, I can, if I'm careful, make the assembly also work with
> > the 1.1 framework.
>
> uh? Look up text around those excerpts in the article:

        It is also necessary to consider what they *mean,* especially as
regards what you wrote. You wrote:

"That's where you're going wrong: if your assembly is N+1, it won't run
*at all* on a N install, after all, it's just object code, and without
an N+1 capable framework, you can't even display a nice dialog box to
explain the issue to the user."

        ...and that's what I replied to. You have since modified your
position to include use of features not in the N+1 framework and
dynamic selection of CLR versions, which are separate questions. What
you wrote is simply wrong, and changing the subject doesn't make it
right.
 
> "When you choose to take advantage of features available in a newer
> .NET version but not in older ones, your components will no longer
> be compatible with older versions" [...]

        What part of this suggests to you that you can't even display a
dialog, as you wrote? It is not necessary to take advantage of
features available in a newer version in order to display a dialog box.
Or are you once again revising your position and saying, "if you use
features which exist in the N+1 only?" (You said nothing of the sort
in the message I first replied to.)

        As I showed in my last message, the code to do so doesn't even have to
go in the same assembly if you find that easier; you can manifest the
app so that the "correct" assembly is loaded for whichever version of
the framework is present.

        Nor is this restriction in any way unique to .NET. If I am careful, I
can write an application which works with multiple versions of
comctl32.dll. But if I use features only available in version n+1 or
comctl32.dll, that part of the code isn't going to work with version n.
.NET provides some ways to work with this situation, but it won't make
features which don't appear in one version magically appear.

> "Next, you need to understand CLR version unification." [...]
> "when you get a particular version of the CLR, that also dictates
> which version of the .NET application frameworks is used" [...]
> "the CLR and the .NET application frameworks aren't designed for
> mix and match, with some assemblies coming from version n and some
> from version n+1." [...]

        You do understand that this is referring to *the framework itself*
rather than assemblies you write, correct? It *is* correct that you
can't use, say, System.Drawing.dll 1.1.4322 with System.dll 1.0.3705.
But that has no bearing at all on your incorrect statement that you
can't display a dialog or that your assembly won't run at all on an N
framework if you compile with an N+1 compiler -- as both the article
and the framework documentation link I gave explicitly demonstrate,
this is wrong.

> "It's up to the EXE to select the CLR and application framework
> version to use. The class libraries have no say in the matter" [...]
> "If the EXE assembly selects version 1.0.3300.0, then all the class
> libraries it loads will use version 1.0.3300.0, even if they require
> the newer features of 1.1.5000.0" [...]
>
> Doesn't leave much rooms for dynamic selection does it?

        You're changing the subject -- again! We were discussing the ability
of an assembly compiled with an N+1 compiler to use an N framework, not
the ability to dynamically load different versions of the framework,
which I agree is not possible.

> > This is a change? When has Microsoft ever made such a guarantee?
>
> Win32 or Win64 API.

        Are you saying you consider the comctl32 library to be guaranteed
backwards compatible? Or that you don't consider it to be a part of
the API? If the answer to either of these is yes then this has gone so
far into fictional territory that I won't waste any further time on the
thread.

        -Craig 

-- 
Craig Stuntz [TeamB] . Vertex Systems Corp. . Columbus, OH
  Delphi/InterBase Weblog : http://delphi.weblogs.com
InterBase Performance Monitor -- Analyze and control your IB7 
  server: http://delphi.weblogs.com/IBPerformanceMonitor

Relevant Pages

  • Re: IE Hosts Windows Control
    ... statement in the "What's new in the .NET Framework 1.1" ... Internet-based Web page or Windows Forms assemblies ... could get my control to execute on a framework v1 sp1 ... >> assemblyName, String ...
    (microsoft.public.dotnet.security)
  • Re: God I Love Delphi7
    ... Windows Forms are extremely easy to use. ... Where do you put those assemblies on ... application config files shoule be placed in your app directory. ... know what version of an assembly to use and what framework it needs. ...
    (borland.public.delphi.non-technical)
  • Re: Oddity with protected internal and derivation
    ... Well that's what the compiler is doing, the question is why it is doing it. ... If the framework allowed for the override to be also 'protected internal' ... Which would mean a circular reference of assemblies. ... classes derived from this base class as a result of moving the base class ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Cant use VS2005 assembly on VS2003 project
    ... > 2) If .NET runtime can only load one version of the framework, ... >> You can't use VS 2005 assemblies in earlier versions. ... CLR cannot load 2.0 assembly even if CLR itself is 2.0. ... >> Mikhail Arkhipov ...
    (microsoft.public.vsnet.general)
  • Re: Retargetable=Yes
    ... AccessDriver version - AccessDriverCF and another AccessDriverFull. ... > comapct framework, but keeping the same contract, ... > CF assemblies bind to the full framework assemblies when run on desktop). ...
    (microsoft.public.dotnet.framework.compactframework)
Loading