[.NET] Remoting - versioning

[whoami]

Ik ben me aan het voorbereiden op het MS examen 070-320 , Xml web services & server components in C#.

Ik heb een aantal testvragen gevonden, en ik kom er bij 1 vraag niet uit. Om meer specifiek te zijn, ik ben niet akkoord met de gegeven correcte oplossing.

De vraag luidt als volgt:

You create version 1.0.0.0 of an assembly named TestKiAssembly. You register the
assembly in the global assembly cache.
TestKiAssembly consists of two .NET Remoting objects named TKRemoteObject1 and
TKRempoteObject2 These objects are configured in the App.config file of
TestKiAssembly as shown in the following code segment:

code:

<system.runtime.remoting>
  <application>
    <service>
      <activated type="TestKiAssembly.TKRemoteObject1,
                      TestKiAssembly, Version=1.0.0.0, Culture=neutral,
                      PublicKeyToken=28dckd83491duj" />
      <wellKnown mode="SingleCall"
                      objectUri="TKRemoteObject2.rem"
                      type="TestKiAssembly.TKRemoteObject2, TestKiAssembly,
                      Version=1.0.0.0, Culture=neutral,
                      PublicKeyToken=28dckd83491duj" />
      <channels>
          <channel ref="http" />
      </channels>
    </service>
  </application>
</system>

You create an application named TKApp that resides on a different computer than
TestKiAssembly. TKApp references version 1.0.0.0 of TestKiAssembly. TKApp contains
code that activates instances of TKRemoteObject1 and TKRemoteObject2 to use their
services.
Due to changes in business needs, you must update TestKiAssembly. You create version
2.0.0.0 of TestKiAssembly, which is backward compatible, but you do not update any
information in the App.config file of TestKiAssembly. You register version 2.0.0.0 of
TestKiAssembly in the global assembly cache. You then rebuild TKApp.
Which version of the remote object will MyApp activate?

A. Version 1.0.0.0 of TKRemoteObject1; version 1.0.0.0 of TKRemoteObject2.
B. Version 1.0.0.0 of TKRemoteObject1; version 2.0.0.0 of TKRemoteObject2.
C. Version 2.0.0.0 of TKRemoteObject1; version 1.0.0.0 of TKRemoteObject2.
D. Version 2.0.0.0 of TKRemoteObject1; version 2.0.0.0 of TKRemoteObject2.

Nu is volgens mij het correcte antwoord C.
Waarom:
In m'n boek, en ook in de MSDN vind ik terug dat, bij server - activated types iedere keer de recentste versie gebruikt wordt als er geen versie-informatie in de config. file gebruikt is. Aangezien er in dit voorbeeld wel een versie-nr wordt meegegeven in de config file, ga ik er dus van uit dat versie 1 van het server - activated object (TKRemoteObj2) gebruikt wordt.
Bij client-activated objects wordt het object gebruikt waartegen gebuild werd. Aangezien in deze nieuwe versie voor versie2 gebuild werd, zou ik zeggen dus dat versie2 van TKRemoteObj1 gebruikt wordt.

Volgens het document waar ik die vraag uit heb, is het correcte antwoord B, net het omgekeerde dus van wat ik dacht.
Dit is trouwens de argumentatie van de auteur van dat document:

Answer: B
Explanation:
Version 1.0.0.0 of MyRemoteObject1 is used since the following client-activated
configuration is used:

code:

<activated type="TestKiAssembly.TKRemoteObject1,
                 Version=1.0.0.0"/>

The element Contains information about server-activated objects the
application exposes to clients. TKRemoteObject2 is therefore server-activated. The server
controls what version is activated when a client connects to a server-activated object.
Therefore Version 2.0.0.0 will be used for TKRemoteObject2.

Wie weet er hier meer vanaf, en kan uitsluitsel geven (onderbouwd ) over welke optie nu correct is?

Dit haal ik trouwens uit de MSDN wb Server Activated objects:[nohtml]

The server controls which version of a type is activated when a client connects to a server-activated (or ) object. If no version information is provided when the service is configured, the most recent version of the assembly is used when the object is activated. For example, if you have two assemblies, MyHello version 1.0.0.0 and MyHello version 2.0.0.0, the well-known object is activated using the version 2 assembly if no version information is provided. It is important to note that this version is used irrespective of the version referenced when the client was built.

En over client-activated objects wordt dit gezegd:

When a client activates a client-activated (that is, an <activated>) object, a network call is immediately sent to the server where the requested object is activated and an object reference to the object is returned to the client. Because it directs the activation of the object, the client also chooses the version of the object to be activated. For example, version 1 of HelloService will be activated on the server if the client was built against version 1 of the object, and version 2 of HelloService will be activated on the server if the client was built against version 2.

It is important to note that you cannot specify the version number for client-activated types when configuring the service. Also, any versioning information provided for server-activated types has no effect on client-activated objects, even if both types are in the same assembly.

For example, suppose you have a client-activated type and a server-activated type in the same assembly, and you build client1 against version 1 and client2 against version 2. If no version information is specified for the server-activated object, client1 will receive version 2 of the server-activated object and version 1 of the client activated object. Client2 will receive version 2 objects for both well-known and activated types.

If you configure the service to use version 1 of the assembly for the well-known object, both clients will receive version 1 of the well-known object while client 1 receives version 1 of the activated type and client 2 receives version 2 of the activated type.

The version activated for a client cannot be configured; the version the client was built against is always used.

[ Voor 4% gewijzigd door whoami op 22-10-2003 15:09 ]

[whoami]

Ik snap er niks meer van.

Ik heb even de proef op de som genomen, en een testprojectje aangemaakt.

Ik heb dus een server-applicatie die volgende configuratie-file inlaadt:

code:

<configuration>
<system.runtime.remoting>
  <application>
    <service>
      <wellknown type="serveract, remobj, 
                       Version=1.0.1388.15713 ,Culture=neutral, PublicKeyToken=8a091fc57408d07a"
                 objectUri="serveract.rem"
                 mode="Singleton" 
       />      
      <activated type="clientact, remobj"/>
    </service>
  </application>
</system.runtime.remoting>
</configuration>

Zoals je kunt zien, registreert de server een Server Activated () object met
versie informatie. Het wellknown object is ook 'shared', en dus in de GAC opgenomen.

Ik heb 2 versies van m'n remote object die in de GAC geinstalleerd staan, nl :
versie 1.0.1388.15713 en versie 2.0.0.0.
Die remote objects hebben elk een method die een string returnen met hun versie-info.

Aangezien ik dus in m'n config-file van m'n server applicatie een versie specifieer die moet
gebruikt worden, verwacht ik dus ook dat die versie uitgevoerd wordt door m'n client applicatie.

De client-applicatie laadt onderstaande config-file in:

code:

<configuration>
  <system.runtime.remoting>
   <application>
    <client url="http://127.0.0.1:8080">
      
       <wellknown 
         type="serveract, remobj"
         url="http://127.0.0.1:8080/serveract.rem"
       />       
    </client>
   <channels>
     <channel 
        ref="http" 
        port="0"/>
     </channels>
  </application>
</system.runtime.remoting>
</configuration>

Als ik nu echter m'n client-app uitvoer, en ik voer de method uit die de versie-info returned, krijg ik te zien dat versie 2 gebruikt wordt, alhoewel ik de andere versie specifieer in m'n config file
op de server
Als ik de versie informatie uit de config file weglaat, dan wordt versie 2 ook geactiveerd.

Lees ik nu iets verkeerd in de MSDN?

[EfBe]

Als je het allemaal leest, zou antwoord D de juiste moeten zijn.

[whoami]

EfBe schreef op 20 October 2003 @ 12:11:
Als je het allemaal leest, zou antwoord D de juiste moeten zijn.

Waarom?
Voor het client activated object zou versie 2 idd moeten geactiveerd worden, omdat de applicatie gebuild is voor versie 2.
Echter, in de config. file staat voor het server-activated object een versie-nr gespecifieerd nl. versie 1, dus zou het toch versie 1 van het server activated object moeten zijn dat uitgevoerd wordt?

[ Voor 36% gewijzigd door whoami op 20-10-2003 12:39 ]

[EfBe]

whoami schreef op 20 October 2003 @ 12:31:
Echter, in de config. file staat voor het server-activated object een versie-nr gespecifieerd nl. versie 1, dus zou het toch versie 1 van het server activated object moeten zijn dat uitgevoerd wordt?

B is sowieso fout. Let wel, dit zijn braindumps met het juiste antwoord van de braindumper erbij. Veel van die MS vragen zijn simpele instinkers en daar kan de braindumper ook gewoon ingestonken zijn.

Ik zou me echter geen reden voor kunnen stellen, waarom een build tegen een nieuwere versie niet die nieuwere versie zou gebruiken? Je definieert immers geen policy file. Dit wordt ook bevestigd door je test.

[alienfruit]

Cool. Nu weet ik waarom me programma over de zeik gaat, bedankt

[whoami]

Op de een of andere manier moet je toch kunnen teruggrijpen naar een oudere versie.
Misschien heb ik wel in m'n test iets verkeerds gedaan, 'k was nogal gehaast.
Vanavond test ik wel nog eens eea uit, en lees ik nog eens iets over Publisher policies.

[EfBe]

whoami schreef op 20 October 2003 @ 14:02:
Op de een of andere manier moet je toch kunnen teruggrijpen naar een oudere versie.

Daar heb je die policy files voor Ik zou het een enorme design blunder vinden als je versions ineens ook via service config files zou kunnen gaan aangeven, want de policy files zijn daar juist voor bedoeld, zodat de administrator op 1 manier die zaken kan beheren.
[/quote]

[whoami]

EfBe schreef op 20 October 2003 @ 15:04:
[...]

Daar heb je die policy files voor Ik zou het een enorme design blunder vinden als je versions ineens ook via service config files zou kunnen gaan aangeven, want de policy files zijn daar juist voor bedoeld, zodat de administrator op 1 manier die zaken kan beheren.

Volgens dit stukje moet het toch kunnen:

For example, suppose you have a client-activated type and a server-activated type in the same assembly, and you build client1 against version 1 and client2 against version 2. If no version information is specified for the server-activated object, client1 will receive version 2 of the server-activated object and version 1 of the client activated object. Client2 will receive version 2 objects for both well-known and activated types.

If you configure the service to use version 1 of the assembly for the well-known object, both clients will receive version 1 of the well-known object while client 1 receives version 1 of the activated type and client 2 receives version 2 of the activated type.

Enfin, vanavond klooi ik wel wat verder.

[whoami]

Je kan dus wel degelijk specifieren welke versie er moet gebruikt worden van het Server activated object in de config. file waarin je de objecten registreert op de serverapp.

Ik heb net ff een server applicatie gemaakt waarvan dit de relevante code is:

ServerApp

code:

RemotingConfiguration.Configure("..\\..\\serverconfig.xml");

Dit is de serverconfig.xml config. file die door de server wordt ingeladen

code:

<configuration>
  <system.runtime.remoting>
    <application>
       <service>
        <wellknown type="FGRemObj.FGServer, FGRemObj, 
                Version=2.0.0.0, Culture=neutral, 
                                PublicKeyToken=e07d62b837be633c"
             objectUri="FGRemObj.serverfg"
             mode="Singleton"
        />
       </service>
      <channels>
        <channel ref="http" port="8765"/>
         </channels>
       </application>
  </system>
</configuration>

Ik heb dus 2 versies van FGRemObj.FGServer nl. versie 1.0.0.0 en versie 2.0.0.0.
Die bevinden zich beide in de GAC.
FGServer heeft een method GetVersion die een string returned waarin de versie-informatie in getoond wordt.

M'n client applicatie heeft deze relevante code:

code:

ChannelServices.RegisterChannel(new HttpChannel(0));
            
s = (FGRemObj.FGServer)Activator.GetObject(typeof(FGRemObj.FGServer), 
                                           "http://127.0.0.1:8765/FGRemObj.serverfg");

en:

code:

private void button1_Click(object sender, System.EventArgs e)
{
    MessageBox.Show(s.GetVersion());
}

Als ik dus in m'n server config. file versie 1.0.0.0 specifieer dan krijg ik:

server activated version 1

te zien, en als ik v2.0.0.0 specifieer, dan krijg ik:

server activated version 2

te zien.

Je kan dus wel degelijk de te gebruiken versie in je config. file op de server gaan specifieren.

Als ik echter de versie-informatie uit m'n config file weglaat, dan krijg ik een exceptie, dat de gevraagde service niet kan gevonden worden.
Blijkt dat dat is omdat m'n objecten in de GAC staan, en je dan alle versie-info moet opgeven.

* whoami gaat nog eens stoeien met server activated objects die niet in de GAC staan.

[ Voor 4% gewijzigd door whoami op 22-10-2003 15:11 ]

[whoami]

OMG, bij bovenstaand voorbeeld werkt het boeltje niet als je server config file er zo uit ziet:

code:

<wellknown type="FGRemObj.FGServer, FGRemObj, 
                Version=2.0.0.0, Culture=neutral, 
                PublicKeyToken=e07d62b837be633c"
     objectUri="FGRemObj.serverfg"
         mode="Singleton"
                />

Er wordt een exceptie gegooid dat ie het object niet kan vinden.

Als je dat echter op 1 lijn werkt, dan werkt het wel.

[ Voor 6% gewijzigd door whoami op 22-10-2003 15:11 ]

[whoami]

Hmmm.....
Blijkbaar is het niet mogelijk om op Windows2000 private assemblies side by side te gaan deployen.
Dit zou enkel beschikbaar zijn vanaf Windows XP.