coapp-developers team mailing list archive

[Garrett Serack <garretts@xxxxxxxxxxxxx>]

Notes on Creating Test Packages:
---------------------------------------------

Below are some notes I’ve been making regarding creating test EXE & DLL files for test packages.
I’ve started writing out some combinations.  I know there are more that I haven’t done yet…

Versions are specified as MM.NN.RR.BB
    MM - Major
    NN - Minor
    RR - Revision
    BB - Build
Each element is an unsigned integer 0..65535.

For purposes of testing, versions are considered to always be
binary compatible if the MM & NN numbers are identical between the
libraries.
    ie: for a given library, version 1.1.0.0 should always have
        binary compatibility with any version of the library
        that starts with 1.1  (1.1.0.0 to 1.1.65535.65535)

Publishers of libraries MAY declare later Major/Minor versions support
ABI compatible interfaces for earlier libraries. However this requires
additional policy files to be created.
   ie: for a given library it is possible that version 1.1.0.0
        supports binary compatibility for 1.0.0.0.

        or, for 2.0.0.0, the publisher can claim that this is
        supports binary compatibility for applications binding to
        versions 1.*.*.*.

The compatibility information a publisher issues for a library is
called the BINDING POLICY. The Binding Policy is stored in a file
called a PUBLISHER CONFIGURATION FILE which is an XML file stored
in the %systemDrive%\windows\winsxs\policies\... folder.

The file name of a publisher configuration file has the form
"POLICY.MM.NN.[ASSEMBLYNAME]" where MM and NN refer to the major and
minor parts of the assembly version that is being affected. The
[ASSEMBLYNAME] refers to the name of the assembly.

On disk, the name likely changes to something like:

x86_policy.[MM].[NN].[ASSEMBLYNAME]_[PKT]_[LANG-ID]_[hashvalue].manifest

Generally speaking, applications should bind to the lowest possible
version that compatibility is guaranteed with.

Applications
-------------
AppOne          ->  LibA[1.0.0.0]

AppTwo          ->  LibB[1.0.0.0]
                ->  LibC[1.0.0.0]

AppThree        ->  LibA[1.0.50.0]
                ->  LibC[2.0.0.0]

AppFour         ->  LibD[2.0.0.0]
                ->  LibC[2.0.0.0]

Libraries
----------

Library Name        Version         Binding Policy              Depends on
---------------     ----------      ------------------          ------------
LibA                1.0.0.0         (none)                      (none)
                    1.0.0.1         1.0.0.0-1.0.0.0             (none)
                    2.0.0.0         1.0.0.0-1.65535.65535.65535 LibB-1.0.0.0


LibB                1.0.0.0         (none)                      LibC-1.0.0.0
                    1.0.0.1         1.0.0.0-1.0.0.0             LibC-1.0.0.0
                    2.0.0.0         (none)                      LibC-1.0.0.0
                    2.0.0.1         2.0.0.0-1.0.0.0             LibC-2.0.0.0

LibC                1.0.0.0         (none)                      LibD-1.0.0.0
                    2.0.0.1         1.0.0.0-2.0.0.0             LibD-1.0.0.0

LibD                1.0.0.0         (none)                      (none)
                    2.0.0.0         (none)                      (none)

which can be expressed in an INI file to drive the test generator:

-------------[test.ini]--------------------------------------------------
[exe]
AppOne=LibA(1.0.0.0)
AppTwo=LibB(1.0.0.0),LibC(1.0.0.0)
AppThree=LibA(1.0.50.0),LibC(2.0.0.0)
AppFour=LibD(2.0.0.0),LibC(2.0.0.0)

[dll]
LibA(1.0.0.0)
LibA(1.0.0.1)=1.0.0.0-1.0.0.0
LibA(2.0.0.0)=1.0.0.0-1.65535.65535.65535:LibB(1.0.0.0)

LibB(1.0.0.0)=:LibC(1.0.0.0)
LibB(1.0.0.1)=1.0.0.0-1.0.0.0:LibC(1.0.0.0)
LibB(2.0.0.0)=:LibC-1.0.0.0
LibB(2.0.0.1)=2.0.0.0-1.0.0.0:LibC(2.0.0.0)

LibC(1.0.0.0)=:LibD-1.0.0.0
LibC(2.0.0.1)=1.0.0.0-2.0.0.0:LibD(1.0.0.0)

LibD(1.0.0.0)=:
LibD(2.0.0.0)=:


________________________________
From: coapp-developers-bounces+garretts=microsoft.com@xxxxxxxxxxxxxxxxxxx [coapp-developers-bounces+garretts=microsoft.com@xxxxxxxxxxxxxxxxxxx] on behalf of Rivera, Rafael [rafael@xxxxxxxxxxxxxxxxx]
Sent: Thursday, September 02, 2010 8:37 PM
To: coapp-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Coapp-developers] Test Package (EXE & DLL) Creator

So here's a dump of what I had in mind.

Executable
- 0..n Private DLLs
- 0..n Public DLLs
  ...
  + @name unique restriction
  + @versionRequested may match @versionGiven
  + @versionGiven

Private DLLs
- 0..n Private DLLs
- 0..n Public DLLs
  ...
  + @name unique restriction
  + @versionRequested may match @versionGiven
  + @versionGiven

Public DLLs
- 0..n Private DLLs
- 0..n Public DLLs
  ...
  + @name unique restriction
  + @versionRequested may match @versionGiven
  + @versionGiven

And represented graphically...

[cid:part1.05050304.00000904@withinwindows.com]

Kinda what you were looking for?


/rafael


On 9/2/2010 7:01 PM, Garrett Serack wrote:
How do I drive my funky creator to generate all the package combinations that we want to test?

I want to generate EXEs and DLLs that depend on different versions of DLLs, some should be binary-compitable, some not (so we'd see two different versions of the same library loaded by the same EXE at some point).

I've got the code ready to generate, compile, sign EXEs and DLLs, so they can be turned into WinSXS assemblies, I just need a formula.

Any ideas?

G