[VB2005] Rare foutmelding gebuilde applicatie.

[Luppie]

Ik heb op een Windows Server 2003 Visual Studio geïnstalleerd en heb een simpele windows form applicatie gemaakt. Er zijn geen references aan het project toegevoegd.

Nu heb ik de applicatie gebuild en de executable gekopieerd naar een andere Windows Server 2003 server waarop Framework 2 isgeïnstalleerd. Als ik de applicatie start dan krijg ik de volgende melding:



Wat heb ik zelf geprobeerd :
* Publishen van de applicatie
* Builden van een "Hello World" app en krijg hier ook de melding.
* Getest op meerdere servers.

Heeft iemand dit al eerder gehad en/of weet iemand hoe dit op te lossen is ?

[ Voor 4% gewijzigd door Luppie op 24-11-2005 15:48 ]

[Luppie]

iemand ??

[Luppie]

Nog maar een schopje.

Misschien doe ik zelf wel iets fout met het builden van de applicatie. Kan iemand mij uitleggen hoe ik kan zien of het framework wel goed op de target machine staat en/of ik deze foutmelding kan verhelpen/voorkomen.

[RobIII]

Om heel eerlijk te zijn: Lijkt me een *kuch* niet-zo-legale-versie^TM *kuch* van VS, niet?

Edit: damned, da's vandaag al de tweede post die ik niet goed lees. Sorry daarvoor. Heeft geen zak te maken met wat ik hierboven schreef, want dan zou het niet op de ene pc wél en op de andere pc niet werken.

Probeer dan eens een re-install van het .Net framework of anders desnoods compleet VS opnieuw.

[ Voor 84% gewijzigd door RobIII op 29-11-2005 11:42 ]

[Luppie]

Ik heb een legale versie van VS (Van MS gekregen tijdens de launch)
Het rare is dat een applicatie die ik build wel werkt op de machine waarop ik hem geschreven heb en dat als ik de gebuilde applicatie (de exe) kopieer naar een andere machine die met hetzelfde OS Image is geïnstalleerd (echter zonder VS maar met .NET Framework 2.0) niet werkt.

Ik heb een repair van .NET Framework uitgeprobeerd maar dat hielp helaas niet. (zelfs op een andere server krijg ik exact dezelfde melding)

[pjvandesande]

Dit heeft volgens mij gewoon met security te maken, probeer hem is full-trusted te draaien.

In .NET 1.1 was hier ook al zo'n wazige melding, alleen in een ander jasje.

Als je het Application.ThreadException even wired, word deze dan wel getriggerd of komt hij zelfs daar nog niet eens?

[Verwijderd]

Volgens mij is het inderdaad security-gerelateerd (OLEAUT -> Object Linking and Embedding Authorisation ofzo). Check anders even of die hele registry key wel bestaat; misschien is de installatie corrupt geraakt.

[Luppie]

Ok, ik ben jullie nu al helemaal kwijt dit is mijn eerste overstap van VB6 naar VS2005.
Ik zal ook nog wel gaan zoeken naar OLEAUT en security.

[Gerco]

Start je de app vanaf een netwerkdrive? Zo ja, sla hem dan eens lokaal op en probeer het nog eens. .NET kent default minder rechten toe aan apps die niet van een lokale schijf komen en dat wil weleens tot wazige errors leiden.

[Luppie]

Nope, heb hem netjes gekopieerd naar 2 verschillende machines en lokaal gedraaid. Het is mij inderdaad opgevallen dat als ik de applicatie draai via een UNC path dat ie met een security melding komt.

Misschien kan ik mijn vraag ook anders formuleren, "Hoe kan ik een zelf geschreven applicatie distribueren naar een simpele gebruiker/machine die buiten mijn ontwikkel netwerk valt"

[ Voor 32% gewijzigd door Luppie op 29-11-2005 13:47 ]

[pjvandesande]

Cobra_Lup schreef op dinsdag 29 november 2005 @ 13:45:
Nope, heb hem netjes gekopieerd naar 2 verschillende machines en lokaal gedraaid. Het is mij inderdaad opgevallen dat als ik de applicatie draai via een UNC path dat ie met een security melding komt.

Misschien kan ik mijn vraag ook anders formuleren, "Hoe kan ik een zelf geschreven applicatie distribueren naar een simpele gebruiker/machine die buiten mijn ontwikkel netwerk valt"

Je kunt je app toch gewoon trusted maken? Werkt het dan wel?

[Luppie]

Dat is het probleem. In de .NET FW2 zit de FrameWork Configuration snap-in (mscorcfg.msc) niet meer. Maar ik weet dus niet hoe ik een app. zo kan maken dat ie op iedere willekeurige PC met alleen het FW er op kan draaien.

The basic answer here is that, yes, it has been removed from the .NET Framework and it is still available for developers in the SDK.

The CLR team did a lot of work to determine how end users would use the tool and decided to move out of the .NET Framework.

If there are specific things you are trying to do that you can't do programatically or with caspol.exe, please do post those questions. It is always good to get information directly from customers about what they are trying to accomplish.

Bret Grinslade
VS/.NET Framework Setup Team