AppDomain funktion deprecated - hvordan løses det?

måske bare

AppDomainSetup domain = new AppDomainSetup();
    domain.PrivateBinPath = @"c:\MyAppDir";

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.

kan du benytte denne løsning?
http://www.msnewsgroups.net/group/microsoft.public.dotnet.languages.csharp/topic13593.aspx

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?

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å?

Kommentar: spif2001
26/07-2007 10:40:10

laver ikke nogen exception hos mig

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.

@ 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.

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>

<probing privatePath="c:\MyAppDir"/>

er vel den eneste rettelse

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...

Virkede ikke.

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

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.

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)

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.

vil du lige prøve denne?

<probing privatePath="bin"/>

Virker heller ikke :)

Jeg synes lige du skal kigge på hvordan de gør det her
http://pavanpodila.spaces.live.com/?_c11_BlogPart_FullView=1&_c11_BlogPart_BlogPart=blogview&_c=BlogPart&partqs=amonth%3D11%26ayear%3D2006

det står rimelig godt beskrevet

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...

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.

undeprecate metoden:D den virkede sgu nemmere hehe

MEGET nemmere - hæ

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

Smid et svar.

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();

spif2001 >> Jeg behøver ikke pointene=)

@ 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.

Jeg lukker og sætter min lid til, at MS får lavet noget genialt. ;)