[c#]programma start niet van netwerklocatie

[Magic]

Ik heb zojuist een programmatje geschreven dat vanaf elke locatie perfect werkt, tenzij ik hem van een netwerklocatie start. Deze foutmelding is dan het gevolg:

De toepassing heeft een fout gegenereerd die niet kan worden verwerkt.

Proces-id=0xc24 (3108), thread-id=0xe54 (3668).

nu ben ik door middel van een beetje backtracen er achter gekomen dat de fout zich voordoet zodra ik een ADO-component toevoeg aan het programma.

Als IDE gebruik ik SharpDevelop die nog lichtjes bèta is, helaas heb ik niet de mogelijkheid om het te proberen in een andere IDE, ik weet dus niet of het een bug is (de bugtracker van SD meld er niks over), of dat de fout ergens anders te zoeken is.

is er iemand die mij hier iets meer over kan vertellen?

[Twilight Burn]

Als je een C# of een andere .Net applicatie vanaf een netwerklocatie opstart heb je minder rechten dan als je hem lokaal draait. Ik denk dat daar de fout in zit, en je dus geen ADO component toe mag voegen als je hem vanaf het netwerk opstart.

[Infinitive]

Er is een oplossing: je moet de assembly vertrouwen. Doe dit onder windows xp als volgt:
configuratie scherm -> systeem beheer -> wizards microsoft .net framework -> een assembly vertrouwen.

Komt dat echt door het ADO component trouwens? Want ik heb dit probleem bij elke .net applicatie die vanaf een netwerkshare wordt uitgevoerd. Dus zelfs bij een "hello world".

[ Voor 34% gewijzigd door Infinitive op 12-06-2004 21:27 ]

[Magic]

Infinitive schreef op 12 juni 2004 @ 21:26:
Er is een oplossing: je moet de assembly vertrouwen. Doe dit onder windows xp als volgt:
configuratie scherm -> systeem beheer -> wizards microsoft .net framework -> een assembly vertrouwen.

thanks, dat loste het probleem op wel stom trouwens dat er geen vriendelijke melding komt in de trend van "dit programma is een mogelijk beveiligingsprobleem en kan daarom niet worden gestart"

Komt dat echt door het ADO component trouwens? Want ik heb dit probleem bij elke .net applicatie die vanaf een netwerkshare wordt uitgevoerd. Dus zelfs bij een "hello world".

ik heb enkele programma's zonder ADO-componenten die het gewoon goed doen. en ook "Hello World" heb ik net even getest en doet het perfect. zodra ik echter aan het "hello world" een ADO-component toevoeg weigert hij dienst te doen.

Maar het probleem is in ieder geval opgelost, bedankt voor de snelle reactie

[ Voor 9% gewijzigd door Magic op 12-06-2004 21:51 ]

[whoami]

Magic schreef op 12 juni 2004 @ 21:50:
[...]

thanks, dat loste het probleem op wel stom trouwens dat er geen vriendelijke melding komt in de trend van "dit programma is een mogelijk beveiligingsprobleem en kan daarom niet worden gestart"

Er wordt gewoon een exceptie gegooid, die kan je opvangen en zelf voor de 'vriendelijke' boodschap zorgen.

[Infinitive]

Er wordt gewoon een exceptie gegooid, die kan je opvangen en zelf voor de 'vriendelijke' boodschap zorgen.

Deze excepties worden gegooid op het moment dat je assembly door de VM ingeladen wordt. Je kan catchen wat je wilt, maar dat gaat niet lukken

[whoami]

Infinitive schreef op 13 juni 2004 @ 13:20:
[...]

Deze excepties worden gegooid op het moment dat je assembly door de VM ingeladen wordt. Je kan catchen wat je wilt, maar dat gaat niet lukken

Ben je daar heel zeker van? Volgens mij wordt die exceptie maar gegooid vanaf dat er een operatie uitgevoerd wordt die niet toegestaan is.

Ik heb net even volgend testje gedaan: Ik heb een progje geschreven dat gewoon iets wegschrijft naar een file op local disk:

code:

private void btnDiskAccess_Click(object sender, System.EventArgs e)
{
    FileStream fs = new FileStream (@"c:\blaat.txt", FileMode.Create, FileAccess.Write, FileShare.Read);
    StreamWriter ws = new StreamWriter (fs);
    ws.WriteLine("blaat");
    ws.Close();
    fs.Close();
}

Dit werkt perfect als ik het programma uitvoer vanaf de lokale schijf.
Ik kan dit programma echter ook laden vanaf een network-share; echter, vanzodra ik op die knop klik, krijg ik een securityexception.

(Trouwens, je kan er ook voor zorgen dat -als je een bepaald recht niet hebt- helemaal niet op die knop kunt klikken):

code:

try
{
    FileIOPermission fp = new FileIOPermission (FileIOPermissionAccess.AllAccess, @"c:\");
    fp.Demand();
}
catch
{
    btnDiskAccess.Enabled = false;
}

[Infinitive]

Ik heb blijkbaar ergens in m'n .net configuratie ingesteld staan dat geen enkele assembly vanaf een netwerkshare geladen mag worden, tenzij ik hem expliciet trust. Dit is ook zichtbaar wanneer ik naar de exception trace kijk. Blijkbaar is dat bij jouw en de TS anders, en dan kan je idd de exception opvangen.

Bij de TS is het denk ik zo dat hij de exception krijgt zodra de ADO bibiotheek wordt ingeladen. Dat zal komen door een reference zijn die aan z'n assembly vast zit. Ik verwacht dat dit dus ook gedaan wordt voordat de code van de assembly zelf wordt uitgevoerd en deze exception dus ook niet gecatched kan worden. Tenzij je een tweede assembly maakt en realtime de echte inlaad.

[ Voor 44% gewijzigd door Infinitive op 13-06-2004 13:59 ]

[whoami]

Ik heb net ff een en ander getest.
Ik kan er voor zorgen dat m'n applicatie ook een exceptie gooit als ik 'm vanaf een netwerk-share uitvoer, en ik geen FileAccess Permissie heb.
In m'n assembly info zet ik dan dit:

code:

[assembly: FileIOPermission(SecurityAction.RequestMinimum, Write="c:\\")]

Bij het laden ziet de CLR dat ik die permissie niet heb als ik vanaf een netwerk-share m'n code uitvoer en wordt er een exceptie gegooid.
Zo'n check zal misschien idd ingebouwd zijn in ADO.NET

[Infinitive]

Met de ODBC bibliotheken heb ik dat ook een keer gehad. Hij gaf op een win2k machine aan dat minstens MDAC 6.2 nodig moest zijn en er stond nog een oudere versie op. In de stacktrace kon je toen zien dat hij bezig was met het inladen van de ODBC assembly en dat hij nog niet toe was aan het uitvoeren van code van de applicatie zelf. Dat zijn ook weer fouten die je niet vanuit de code kan opvangen, en dat is wel jammer want die foutmeldingen zien er voor de gebruiker nogal eng uit.

Aan de andere kant was ik zelf dan wel weer blij dat hij iig vertelde wat het probleem was, want als 'ie bij wijze van spreken alleen gezegt zou hebben "odbc library kan niet geladen worden " dan had ik dat probleem nooit kunnen achterhalen. Dus de inhoud van die "preload" foutmeldingen zijn op zich niet slecht, maar voor de normale gebruiker toe zouden die er toch ietsjes aardiger uit moeten zien (naar mijn mening).

[ Voor 36% gewijzigd door Infinitive op 13-06-2004 14:21 ]

[whoami]

Infinitive schreef op 13 juni 2004 @ 14:18:
Met de ODBC bibliotheken heb ik dat ook een keer gehad. Hij gaf op een win2k machine aan dat minstens MDAC 6.2 nodig moest zijn en er stond nog een oudere versie op. In de stacktrace kon je toen zien dat hij bezig was met het inladen van de ODBC assembly en dat hij nog niet toe was aan het uitvoeren van code van de applicatie zelf. Dat zijn ook weer fouten die je niet vanuit de code kan opvangen, en dat is wel jammer want die foutmeldingen zien er voor de gebruiker nogal eng uit.

Dat kan je toch wel oplossen denk ik door in je setup ervoor te zorgen dat die MDAC versie mee geinstalleerd wordt als die er nog niet is ofzo.

[Infinitive]

Dat kan je toch wel oplossen denk ik door in je setup ervoor te zorgen dat die MDAC versie mee geinstalleerd wordt als die er nog niet is ofzo.

Daar heb je helemaal gelijk in. Behalve dat ik zelf niet wist welke bibliotheken dat ding allemaal nodig heeft
Dat ging toen om een klein handig tooltje dat ik voor iemand gemaakt had, dat in principe direct draaide op een win xp + .net framework 1.1 computer. Ik had niet de moeite genomen om er een setup voor te maken.

[ Voor 29% gewijzigd door Infinitive op 13-06-2004 14:24 ]