Avatar billede spif2001 Nybegynder
26. juli 2007 - 10:03 Der er 26 kommentarer og
1 løsning

AppDomain funktion deprecated - hvordan løses det?

Hej

Sidder og roder med et tredjeparts API, som p.g.a. noget IIOP og COM+ interaktion forlanger at jeg bruger følgende kald, for at undgå en IIOP exception:

AppDomain.CurrentDomain.AppendPrivatePath("c:\MyAppDir");

Problemet er bare, at AppDomain.CurrentDomain.AppendPrivatePath() er deprecated og det kan jeg ikke leve med. Beskeden i min Warning er så følgende:

Please investigate the use of AppDomainSetup.PrivateBinPath instead. http://go.microsoft.com/fwlink/?linkid=14202'

Det har jeg så kigget lidt på, men jeg aner ikke hvordan jeg skal få det til at virke. Er der nogen der har styr på AppDomain, så de kan sige hvad jeg skal gøre for at få samme effekt som med AppDomain.CurrentDomain.AppendPrivatePath()?
Avatar billede kalp Novice
26. juli 2007 - 10:19 #1
måske bare

AppDomainSetup domain = new AppDomainSetup();
    domain.PrivateBinPath = @"c:\MyAppDir";
Avatar billede spif2001 Nybegynder
26. juli 2007 - 10:33 #2
Mja - det ændrer jo ikke noget. Så har man bare et object.

Har forsøgt mig med:

AppDomainSetup setupInfo = AppDomain.CurrentDomain.SetupInformation;
setupInfo.ApplicationBase = @"C:\MyAppDir";
setupInfo.ApplicationName = "MyApp";
AppDomain newDomain = AppDomain.CreateDomain("MyApp Domain", null, setupInfo);

...men det giver stadig den IIOP exception.
Avatar billede kalp Novice
26. juli 2007 - 10:38 #3
Avatar billede spif2001 Nybegynder
26. juli 2007 - 10:40 #4
Har lige nu denne løsningsmodel (virker ikke):

foreach (Assembly assembly in AppDomain.CurrentDomain.GetAssemblies())
{
    if (assembly.FullName.Substring(0, assembly.FullName.IndexOf(',')) == "MyApp")
    {
        string location = assembly.Location.Substring(0, assembly.Location.LastIndexOf('\\'));
        //AppDomain.CurrentDomain.AppendPrivatePath(location);

        AppDomainSetup setupInfo = AppDomain.CurrentDomain.SetupInformation;
        setupInfo.ApplicationBase = location;
        setupInfo.ApplicationName = "MyApp";
        setupInfo.PrivateBinPath = location;
        AppDomain newDomain = AppDomain.CreateDomain("NedapCommunicator Domain", null, setupInfo);
        break;
    }


Kan man gøre et eller andet der gør, at mit newDomain "overskriver" det eksisterende, eller burde AppDomain.CreateDomain gøre det?
Avatar billede kalp Novice
26. juli 2007 - 10:42 #5
hmm ser ud til man gør sådan her

AppDomainSetup domaininfo = new AppDomainSetup();
domaininfo.ApplicationBase = @"C:\MyAppDir";
AppDomain domain = AppDomain.CreateDomain("MyDomain", null, domaininfo);
AppDomain.Unload(domain);

hvis det er det du prøver at opnå?
Avatar billede kalp Novice
26. juli 2007 - 10:49 #6
Kommentar: spif2001
26/07-2007 10:40:10

laver ikke nogen exception hos mig
Avatar billede spif2001 Nybegynder
26. juli 2007 - 10:52 #7
Jeg skal ikke unloade mit assembly.

Situationen er, at det jeg laver, er middle tier imellem et tredjeparts IIOP .NET API og et gammelt 16 bits legacy system.

Legacy systemet kontakter min app som er en COM+ service. Herved bliver min process / domæne / hvaddetnuhedder startet op i C:\Windows\System32 mappen af en exe fil derinde. MEN det er skidt, fordi det tredjeparts API jeg kalder, har en masse DLL'er liggende i det bibliotek hvor jeg installerer min app og de refererede tredje parts DLL'er. Et eller andet sted inde i de DLL'er, som jeg ikke har styr over, tror DLL'erne at de bare kan kigge der hvor de selv er, for at finde sig selv (går ud fra der er noget runtime assembly loading i de DLL'er).

Derfor skal jeg have sagt til mit domæne, at den ikke skal kigge i C:\Windows\System32, men i stedet kigge i den mappe hvor jeg er installeret. Det sørgelige er jo så at AppDomain.CurrentDomain.AppendPrivatePath() virker, men at den er deprecated.
Avatar billede spif2001 Nybegynder
26. juli 2007 - 10:54 #8
@ kalp
26/07-2007 10:49:55

Den gør den heller ikke her, så længe jeg starter den via noget Test GUI eller lignende. Hvis jeg registrerer den som COM+ service går det galt inde i de tredjeparts DLL'er, som beskrevet ovenover.
Avatar billede kalp Novice
26. juli 2007 - 10:56 #9
Der står at dette fra 1.1
AppDomain.CurrentDomain.AppendPrivatePath("c:\MyAppDir");

laves sådan i 2.0

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="Plugins"/>
    </assemblyBinding>
  </runtime>
</configuration>
Avatar billede kalp Novice
26. juli 2007 - 10:57 #10
<probing privatePath="c:\MyAppDir"/>

er vel den eneste rettelse
Avatar billede spif2001 Nybegynder
26. juli 2007 - 11:03 #11
Prøver lige.

Problemet med den sti er bare, at den er relativ i forhold til start processen - i mit tilfælde System32 mappen. Om den kan finde ud af absolutte stier må komme an på en prøve :)

2 minutter...
Avatar billede spif2001 Nybegynder
26. juli 2007 - 11:06 #12
Virkede ikke.
Avatar billede kalp Novice
26. juli 2007 - 11:16 #13
okay jeg tror vi er derhen af i hvertfald for det lader til, at det skal skrives mere dynamisk.

du udlæser stien i din app ?

du kan prøve noget alá

<probing privatePath="MyAppDir"/>
muligvis
<probing privatePath="/MyAppDir"/>

og

AppDomainSetup domain = new AppDomainSetup();
      string path = System.IO.Path.GetDirectoryName(
      System.Reflection.Assembly.GetExecutingAssembly().GetName().CodeBase) +  domain.PrivateBinPath;
 
så burde du have stien i path
Avatar billede spif2001 Nybegynder
26. juli 2007 - 11:36 #14
Samme exception.

Skrev path ud i en logfil:

file:\C:\Programmer\MyApp

Så stien er for så vidt ok, men det for jo ikke domænet til at bruge den.
Avatar billede kalp Novice
26. juli 2007 - 11:43 #15
jeg kan læse flere steder, at dette bør være nok

<probing privatePath="myPath"/>

måske skal man angive det uden drev bogstav.

en detalje er dog, at den nye metode er blevet rapporteret, som havende en fejl! og kunne ikke finde nogle steder, at denne fejl skulle være fikset endnu.

så vil mene du skal fokusere udelukkende på den linje i config filen og hvis det ikke virker kunne det jo se ud til det ikke er fikset (evt. sørg for du har service pack installeret til visual studio - mener at have installeret sådan en selv)
Avatar billede spif2001 Nybegynder
26. juli 2007 - 11:55 #16
Nitten - kan ikke få det til at virke og jeg skulle være opdateret.

Kan så være jeg ryger ind i den fejl du snakker om.

Må leve med den deprecatede indtil videre så - øv...

Smid et svar, så du kan få dine velfortjente point.
Avatar billede kalp Novice
26. juli 2007 - 12:06 #17
vil du lige prøve denne?

<probing privatePath="bin"/>
Avatar billede spif2001 Nybegynder
26. juli 2007 - 12:12 #18
Virker heller ikke :)
Avatar billede kalp Novice
26. juli 2007 - 12:16 #19
Avatar billede spif2001 Nybegynder
26. juli 2007 - 12:27 #20
Ok - det bliver lige lidt senere, da jeg er ved at gå fuldstændig sukkerkold. Har ikke fået frokost og skal ud og hente den i byen. Vender tilbage senere...
Avatar billede spif2001 Nybegynder
26. juli 2007 - 13:12 #21
Jeg tror ikke artiklen helt afspejler min situation. Hvis det skulle være 1 af de 3 muligheder beskrevet, må det være den første, da de DLL'er der bøvler ligger samme sted som min app.

Forskellene er bare, at min service for det første ikke er en EXE, men bare en DLL der bliver aktiveret af hvem der nu end måtte kalde den, og for det andet ligger mine DLL'er (både min app og tredje parts DLL'erne) ikke samme sted som hvor min process bliver startet. Da alt det her sti halløjsa ser ud til at arbejde på relative stier, fra hvor processen / domænet opstår, kan jeg ikke "navigere" hen til hvor mine DLL'er ligger rent fysisk.
Avatar billede kalp Novice
26. juli 2007 - 13:14 #22
undeprecate metoden:D den virkede sgu nemmere hehe
Avatar billede spif2001 Nybegynder
26. juli 2007 - 13:17 #23
MEGET nemmere - hæ

Jeg beholder den og så må jeg lave en alternativ løsning når den metode engang forsvinder.

Smid et svar.
Avatar billede akempff Nybegynder
26. juli 2007 - 14:37 #24
Måske du kan bruge:
System.IO.Directory.SetCurrentDirectory(SomePath);


Det har jeg brugt et par gange for at styre hvor nogle dynamisk loadet assemblies hentede deres appconfig fra.

Du kan hente den ved System.IO.Directory.GetCurrentDirectory();
Avatar billede kalp Novice
26. juli 2007 - 14:43 #25
spif2001 >> Jeg behøver ikke pointene=)
Avatar billede spif2001 Nybegynder
26. juli 2007 - 15:44 #26
@ akempff  -  desværre virker det heller ikke.

@ kalp - du har da ellers ikke så mange tilbage, men ok.

Jeg lader spørgsmålet stå åbent henover weekenden. Kunne jo være der var én der kunne et trick a la akempff's, der lige kunne snyde min kære service.
Avatar billede spif2001 Nybegynder
30. juli 2007 - 11:35 #27
Jeg lukker og sætter min lid til, at MS får lavet noget genialt. ;)
Avatar billede Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.

Loading billede Opret Preview
Kategori
IT-kurser om Microsoft 365, sikkerhed, personlig vækst, udvikling, digital markedsføring, grafisk design, SAP og forretningsanalyse.

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester