Sur un TS en W2003, nous rencontrons des probl=E8mes avec des exe C#
.NET qui accepte de se lancer sous un compte administrateur mais qui
refuse de s'ex=E9cuter sous un compte plus limit=E9 (de niveau de droits
utilisateur).
En recherchant d'un peu plus pr=E8s, l'erreur vient de la m=E9thode
process.getprocessbyname qui sort en erreur.
Une recherche sur MSDN nous apprend qu'il faut le niveau FullTrust pour
pouvoir ex=E9cuter cette m=E9thode. Donc on positionne les niveaux
FullTrust au lieu de Nothing dans la configuration de .NET FrameWork
1=2E1 (dans les 3 strag=E9gies de s=E9curit=E9 du runtime : Entreprise,
Ordinateur et utilisateur) et ceci dans le groupe de codde All_Code
mais sans succ=E8s.
1/ Que nous manque-t-il pour pouvoir ex=E9cuter cette m=E9thode dans un
compte utilisateur limit=E9 (qui n'est pas administrateur) ?
2=E8me probl=E8me :
En voulant revenir en arri=E8re sur la modification de la configuration
de .NET Framework 1.1, (remettre les niveaux Nothing =E0 la place de
FullTrust) je n'arrive plus =E0 lancer aucun exe .net sur le poste.
Erreur signal=E9e lors du lancement d'un exe : "L'application a
g=E9n=E9r=E9 une exception non g=E9r=E9e."
Erreur signal=E9e au lancement de cet outil de configuration :
"Echec de l'initialisation du composant de logiciel enfichable
Nom: .Net Framework 1.1 Configuration
CLSID:{1270E004-F895-42BE-8070-DF90D60CBB75}"
2/ Comment puis-je me sortir de cette impossibilit=E9 d'executer des exe
.NET=20
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Steph
et oui... vous mettez en evidence un des gros inconvenient d'utiliser un langage proprietaire... vous n'avez la main sur rien et vous devez attendre que microsoft deigne sortir un patch ou fournir une explication claire et explicite... en gros vous vous retrouvez avec aucun interlocuteur, et le jour ou ils decideront que votre langage de programmation ne les interresses plus, vous vous retrouverez avec un framework plus compatible, une programation a refaire... ah c'est deja le cas... zut... :)
non sans rire, je suis desole de ne pas pouvoir vous aider... et en C++ ? vous n'auriez pas eu (surement) de probleme ! pourquoi c# .... sorry...
a écrit dans le message de news:
Sur un TS en W2003, nous rencontrons des problèmes avec des exe C# .NET qui accepte de se lancer sous un compte administrateur mais qui refuse de s'exécuter sous un compte plus limité (de niveau de droits utilisateur).
En recherchant d'un peu plus près, l'erreur vient de la méthode process.getprocessbyname qui sort en erreur.
Une recherche sur MSDN nous apprend qu'il faut le niveau FullTrust pour pouvoir exécuter cette méthode. Donc on positionne les niveaux FullTrust au lieu de Nothing dans la configuration de .NET FrameWork 1.1 (dans les 3 stragégies de sécurité du runtime : Entreprise, Ordinateur et utilisateur) et ceci dans le groupe de codde All_Code mais sans succès.
1/ Que nous manque-t-il pour pouvoir exécuter cette méthode dans un compte utilisateur limité (qui n'est pas administrateur) ?
2ème problème :
En voulant revenir en arrière sur la modification de la configuration de .NET Framework 1.1, (remettre les niveaux Nothing à la place de FullTrust) je n'arrive plus à lancer aucun exe .net sur le poste.
Erreur signalée lors du lancement d'un exe : "L'application a généré une exception non gérée."
Erreur signalée au lancement de cet outil de configuration : "Echec de l'initialisation du composant de logiciel enfichable Nom: .Net Framework 1.1 Configuration CLSID:{1270E004-F895-42BE-8070-DF90D60CBB75}"
2/ Comment puis-je me sortir de cette impossibilité d'executer des exe .NET
Merci de votre aide, c'est très urgent...
et oui... vous mettez en evidence un des gros inconvenient d'utiliser un
langage proprietaire... vous n'avez la main sur rien et vous devez attendre
que microsoft deigne sortir un patch ou fournir une explication claire et
explicite... en gros vous vous retrouvez avec aucun interlocuteur, et le
jour ou ils decideront que votre langage de programmation ne les interresses
plus, vous vous retrouverez avec un framework plus compatible, une
programation a refaire...
ah c'est deja le cas... zut... :)
non sans rire, je suis desole de ne pas pouvoir vous aider... et en C++ ?
vous n'auriez pas eu (surement) de probleme ! pourquoi c# .... sorry...
<qualitychecker@free.fr> a écrit dans le message de news:
1142433446.037157.102890@e56g2000cwe.googlegroups.com...
Sur un TS en W2003, nous rencontrons des problèmes avec des exe C#
.NET qui accepte de se lancer sous un compte administrateur mais qui
refuse de s'exécuter sous un compte plus limité (de niveau de droits
utilisateur).
En recherchant d'un peu plus près, l'erreur vient de la méthode
process.getprocessbyname qui sort en erreur.
Une recherche sur MSDN nous apprend qu'il faut le niveau FullTrust pour
pouvoir exécuter cette méthode. Donc on positionne les niveaux
FullTrust au lieu de Nothing dans la configuration de .NET FrameWork
1.1 (dans les 3 stragégies de sécurité du runtime : Entreprise,
Ordinateur et utilisateur) et ceci dans le groupe de codde All_Code
mais sans succès.
1/ Que nous manque-t-il pour pouvoir exécuter cette méthode dans un
compte utilisateur limité (qui n'est pas administrateur) ?
2ème problème :
En voulant revenir en arrière sur la modification de la configuration
de .NET Framework 1.1, (remettre les niveaux Nothing à la place de
FullTrust) je n'arrive plus à lancer aucun exe .net sur le poste.
Erreur signalée lors du lancement d'un exe : "L'application a
généré une exception non gérée."
Erreur signalée au lancement de cet outil de configuration :
"Echec de l'initialisation du composant de logiciel enfichable
Nom: .Net Framework 1.1 Configuration
CLSID:{1270E004-F895-42BE-8070-DF90D60CBB75}"
2/ Comment puis-je me sortir de cette impossibilité d'executer des exe
.NET
et oui... vous mettez en evidence un des gros inconvenient d'utiliser un langage proprietaire... vous n'avez la main sur rien et vous devez attendre que microsoft deigne sortir un patch ou fournir une explication claire et explicite... en gros vous vous retrouvez avec aucun interlocuteur, et le jour ou ils decideront que votre langage de programmation ne les interresses plus, vous vous retrouverez avec un framework plus compatible, une programation a refaire... ah c'est deja le cas... zut... :)
non sans rire, je suis desole de ne pas pouvoir vous aider... et en C++ ? vous n'auriez pas eu (surement) de probleme ! pourquoi c# .... sorry...
a écrit dans le message de news:
Sur un TS en W2003, nous rencontrons des problèmes avec des exe C# .NET qui accepte de se lancer sous un compte administrateur mais qui refuse de s'exécuter sous un compte plus limité (de niveau de droits utilisateur).
En recherchant d'un peu plus près, l'erreur vient de la méthode process.getprocessbyname qui sort en erreur.
Une recherche sur MSDN nous apprend qu'il faut le niveau FullTrust pour pouvoir exécuter cette méthode. Donc on positionne les niveaux FullTrust au lieu de Nothing dans la configuration de .NET FrameWork 1.1 (dans les 3 stragégies de sécurité du runtime : Entreprise, Ordinateur et utilisateur) et ceci dans le groupe de codde All_Code mais sans succès.
1/ Que nous manque-t-il pour pouvoir exécuter cette méthode dans un compte utilisateur limité (qui n'est pas administrateur) ?
2ème problème :
En voulant revenir en arrière sur la modification de la configuration de .NET Framework 1.1, (remettre les niveaux Nothing à la place de FullTrust) je n'arrive plus à lancer aucun exe .net sur le poste.
Erreur signalée lors du lancement d'un exe : "L'application a généré une exception non gérée."
Erreur signalée au lancement de cet outil de configuration : "Echec de l'initialisation du composant de logiciel enfichable Nom: .Net Framework 1.1 Configuration CLSID:{1270E004-F895-42BE-8070-DF90D60CBB75}"
2/ Comment puis-je me sortir de cette impossibilité d'executer des exe .NET
Merci de votre aide, c'est très urgent...
Paul Bacelar
Un troll, COOL! COME IN FIGHT!!!
Le problème n'a rien à voir avec le langage d'implémentation.
Ca marche avec compte Admin mais pas utilisateur: Réponse de "Steph" : C'est la faute du langage: A croire que "Steph" pense qu'il y a des langages pour les maîtres du monde comme lui, qui permettent de produire des soft utilisable par les communs des mortels, et des langages de nains de jardins qui ne produisent des soft utilisable que par des administrateurs (comme "Steph"" puisqu'il est maître du monde).
C#:"langage propriétaire", pas mal pour un langage standardisé par ECMA contrairement à Java où SUN interdit toutes évolutions contraire à ses intérêts business.
"" n'aura pas à attendre un patch ou des explications claires et explicites de M$ car la communauté des utilisateurs des produits M$ (qui, je l'espère, n'utilise pas que des produits M$ ;-) ) est pleine de ressource et de bonnes volontés.
Mes explications ( pas M$ :-) ), explicites je l'espère, sont les suivantes:
Dans Doc MSDN : http://msdn2.microsoft.com/en-US/library/system.diagnostics.process(VS.80).aspx , il est question, dans les "Notes," que la classe dérivée ou le code appelant ait les permissions "Full-Trust". C'est le mécanisme de sécurité du FrameWork .NET qui a été configuré de manière trop restrictif pour vos applications ou composants. La méthode la plus simple est de demander à vos administrateurs de configurer les contextes de sécurité du FrameWork .NET de sorte que vos composants software aient les droits "Full-Trust".
Ce n'est pas un problème de langage mais de configuration de sécurité.
Pour "Steph", si tu veux une explication à l'utilisation de C#, c'est peut-être pour ne pas supporter les conneries de soi-disant cadors de la programmation Objet qui n'ont jamais vu de SandBox de sécurité à la JBoss ou TomCat et qui n'ont jamais connus d'évolutions majeures dans LE langage qu'ils utilisent comme l'abandon d'AWT, l'obsolescence ultra rapide des différentes versions de la glibc etc... Sans rire, et c'est pas une formule, il n'y a pas une proposition grammaticale dans votre précèdent post qui ne sous pas une ânerie.
PS: Si il veut aider, le "Steph", j'ai des personnes utilisant le C++ qui t'attendent des réponses sur les NG "microsoft.public.fr.vc" et "microsoft.public.fr.dotnet.vc" . -- Paul Bacelar MVP VC++
"Steph" wrote in message news:441fccc0$0$18328$
et oui... vous mettez en evidence un des gros inconvenient d'utiliser un langage proprietaire... vous n'avez la main sur rien et vous devez attendre que microsoft deigne sortir un patch ou fournir une explication claire et explicite... en gros vous vous retrouvez avec aucun interlocuteur, et le jour ou ils decideront que votre langage de programmation ne les interresses plus, vous vous retrouverez avec un framework plus compatible, une programation a refaire... ah c'est deja le cas... zut... :)
non sans rire, je suis desole de ne pas pouvoir vous aider... et en C++ ? vous n'auriez pas eu (surement) de probleme ! pourquoi c# .... sorry...
a écrit dans le message de news:
Sur un TS en W2003, nous rencontrons des problèmes avec des exe C# .NET qui accepte de se lancer sous un compte administrateur mais qui refuse de s'exécuter sous un compte plus limité (de niveau de droits utilisateur).
En recherchant d'un peu plus près, l'erreur vient de la méthode process.getprocessbyname qui sort en erreur.
Une recherche sur MSDN nous apprend qu'il faut le niveau FullTrust pour pouvoir exécuter cette méthode. Donc on positionne les niveaux FullTrust au lieu de Nothing dans la configuration de .NET FrameWork 1.1 (dans les 3 stragégies de sécurité du runtime : Entreprise, Ordinateur et utilisateur) et ceci dans le groupe de codde All_Code mais sans succès.
1/ Que nous manque-t-il pour pouvoir exécuter cette méthode dans un compte utilisateur limité (qui n'est pas administrateur) ?
2ème problème :
En voulant revenir en arrière sur la modification de la configuration de .NET Framework 1.1, (remettre les niveaux Nothing à la place de FullTrust) je n'arrive plus à lancer aucun exe .net sur le poste.
Erreur signalée lors du lancement d'un exe : "L'application a généré une exception non gérée."
Erreur signalée au lancement de cet outil de configuration : "Echec de l'initialisation du composant de logiciel enfichable Nom: .Net Framework 1.1 Configuration CLSID:{1270E004-F895-42BE-8070-DF90D60CBB75}"
2/ Comment puis-je me sortir de cette impossibilité d'executer des exe .NET
Merci de votre aide, c'est très urgent...
Un troll, COOL!
COME IN FIGHT!!!
Le problème n'a rien à voir avec le langage d'implémentation.
Ca marche avec compte Admin mais pas utilisateur:
Réponse de "Steph" : C'est la faute du langage:
A croire que "Steph" pense qu'il y a des langages pour les maîtres du monde
comme lui, qui permettent de produire des soft utilisable par les communs
des mortels, et des langages de nains de jardins qui ne produisent des soft
utilisable que par des administrateurs (comme "Steph"" puisqu'il est maître
du monde).
C#:"langage propriétaire", pas mal pour un langage standardisé par ECMA
contrairement à Java où SUN interdit toutes évolutions contraire à ses
intérêts business.
"qualitychecker@free.fr" n'aura pas à attendre un patch ou des explications
claires et explicites de M$ car la communauté des utilisateurs des produits
M$ (qui, je l'espère, n'utilise pas que des produits M$ ;-) ) est pleine de
ressource et de bonnes volontés.
Mes explications ( pas M$ :-) ), explicites je l'espère, sont les suivantes:
Dans Doc MSDN :
http://msdn2.microsoft.com/en-US/library/system.diagnostics.process(VS.80).aspx ,
il est question, dans les "Notes," que la classe dérivée ou le code appelant
ait les permissions "Full-Trust".
C'est le mécanisme de sécurité du FrameWork .NET qui a été configuré de
manière trop restrictif pour vos applications ou composants.
La méthode la plus simple est de demander à vos administrateurs de
configurer les contextes de sécurité du FrameWork .NET de sorte que vos
composants software aient les droits "Full-Trust".
Ce n'est pas un problème de langage mais de configuration de sécurité.
Pour "Steph", si tu veux une explication à l'utilisation de C#, c'est
peut-être pour ne pas supporter les conneries de soi-disant cadors de la
programmation Objet qui n'ont jamais vu de SandBox de sécurité à la JBoss ou
TomCat et qui n'ont jamais connus d'évolutions majeures dans LE langage
qu'ils utilisent comme l'abandon d'AWT, l'obsolescence ultra rapide des
différentes versions de la glibc etc...
Sans rire, et c'est pas une formule, il n'y a pas une proposition
grammaticale dans votre précèdent post qui ne sous pas une ânerie.
PS: Si il veut aider, le "Steph", j'ai des personnes utilisant le C++ qui
t'attendent des réponses sur les NG "microsoft.public.fr.vc" et
"microsoft.public.fr.dotnet.vc" .
--
Paul Bacelar
MVP VC++
"Steph" <pipo@pipo.com> wrote in message
news:441fccc0$0$18328$8fcfb975@news.wanadoo.fr...
et oui... vous mettez en evidence un des gros inconvenient d'utiliser un
langage proprietaire... vous n'avez la main sur rien et vous devez
attendre que microsoft deigne sortir un patch ou fournir une explication
claire et explicite... en gros vous vous retrouvez avec aucun
interlocuteur, et le jour ou ils decideront que votre langage de
programmation ne les interresses plus, vous vous retrouverez avec un
framework plus compatible, une programation a refaire...
ah c'est deja le cas... zut... :)
non sans rire, je suis desole de ne pas pouvoir vous aider... et en C++ ?
vous n'auriez pas eu (surement) de probleme ! pourquoi c# .... sorry...
<qualitychecker@free.fr> a écrit dans le message de news:
1142433446.037157.102890@e56g2000cwe.googlegroups.com...
Sur un TS en W2003, nous rencontrons des problèmes avec des exe C#
.NET qui accepte de se lancer sous un compte administrateur mais qui
refuse de s'exécuter sous un compte plus limité (de niveau de droits
utilisateur).
En recherchant d'un peu plus près, l'erreur vient de la méthode
process.getprocessbyname qui sort en erreur.
Une recherche sur MSDN nous apprend qu'il faut le niveau FullTrust pour
pouvoir exécuter cette méthode. Donc on positionne les niveaux
FullTrust au lieu de Nothing dans la configuration de .NET FrameWork
1.1 (dans les 3 stragégies de sécurité du runtime : Entreprise,
Ordinateur et utilisateur) et ceci dans le groupe de codde All_Code
mais sans succès.
1/ Que nous manque-t-il pour pouvoir exécuter cette méthode dans un
compte utilisateur limité (qui n'est pas administrateur) ?
2ème problème :
En voulant revenir en arrière sur la modification de la configuration
de .NET Framework 1.1, (remettre les niveaux Nothing à la place de
FullTrust) je n'arrive plus à lancer aucun exe .net sur le poste.
Erreur signalée lors du lancement d'un exe : "L'application a
généré une exception non gérée."
Erreur signalée au lancement de cet outil de configuration :
"Echec de l'initialisation du composant de logiciel enfichable
Nom: .Net Framework 1.1 Configuration
CLSID:{1270E004-F895-42BE-8070-DF90D60CBB75}"
2/ Comment puis-je me sortir de cette impossibilité d'executer des exe
.NET
Le problème n'a rien à voir avec le langage d'implémentation.
Ca marche avec compte Admin mais pas utilisateur: Réponse de "Steph" : C'est la faute du langage: A croire que "Steph" pense qu'il y a des langages pour les maîtres du monde comme lui, qui permettent de produire des soft utilisable par les communs des mortels, et des langages de nains de jardins qui ne produisent des soft utilisable que par des administrateurs (comme "Steph"" puisqu'il est maître du monde).
C#:"langage propriétaire", pas mal pour un langage standardisé par ECMA contrairement à Java où SUN interdit toutes évolutions contraire à ses intérêts business.
"" n'aura pas à attendre un patch ou des explications claires et explicites de M$ car la communauté des utilisateurs des produits M$ (qui, je l'espère, n'utilise pas que des produits M$ ;-) ) est pleine de ressource et de bonnes volontés.
Mes explications ( pas M$ :-) ), explicites je l'espère, sont les suivantes:
Dans Doc MSDN : http://msdn2.microsoft.com/en-US/library/system.diagnostics.process(VS.80).aspx , il est question, dans les "Notes," que la classe dérivée ou le code appelant ait les permissions "Full-Trust". C'est le mécanisme de sécurité du FrameWork .NET qui a été configuré de manière trop restrictif pour vos applications ou composants. La méthode la plus simple est de demander à vos administrateurs de configurer les contextes de sécurité du FrameWork .NET de sorte que vos composants software aient les droits "Full-Trust".
Ce n'est pas un problème de langage mais de configuration de sécurité.
Pour "Steph", si tu veux une explication à l'utilisation de C#, c'est peut-être pour ne pas supporter les conneries de soi-disant cadors de la programmation Objet qui n'ont jamais vu de SandBox de sécurité à la JBoss ou TomCat et qui n'ont jamais connus d'évolutions majeures dans LE langage qu'ils utilisent comme l'abandon d'AWT, l'obsolescence ultra rapide des différentes versions de la glibc etc... Sans rire, et c'est pas une formule, il n'y a pas une proposition grammaticale dans votre précèdent post qui ne sous pas une ânerie.
PS: Si il veut aider, le "Steph", j'ai des personnes utilisant le C++ qui t'attendent des réponses sur les NG "microsoft.public.fr.vc" et "microsoft.public.fr.dotnet.vc" . -- Paul Bacelar MVP VC++
"Steph" wrote in message news:441fccc0$0$18328$
et oui... vous mettez en evidence un des gros inconvenient d'utiliser un langage proprietaire... vous n'avez la main sur rien et vous devez attendre que microsoft deigne sortir un patch ou fournir une explication claire et explicite... en gros vous vous retrouvez avec aucun interlocuteur, et le jour ou ils decideront que votre langage de programmation ne les interresses plus, vous vous retrouverez avec un framework plus compatible, une programation a refaire... ah c'est deja le cas... zut... :)
non sans rire, je suis desole de ne pas pouvoir vous aider... et en C++ ? vous n'auriez pas eu (surement) de probleme ! pourquoi c# .... sorry...
a écrit dans le message de news:
Sur un TS en W2003, nous rencontrons des problèmes avec des exe C# .NET qui accepte de se lancer sous un compte administrateur mais qui refuse de s'exécuter sous un compte plus limité (de niveau de droits utilisateur).
En recherchant d'un peu plus près, l'erreur vient de la méthode process.getprocessbyname qui sort en erreur.
Une recherche sur MSDN nous apprend qu'il faut le niveau FullTrust pour pouvoir exécuter cette méthode. Donc on positionne les niveaux FullTrust au lieu de Nothing dans la configuration de .NET FrameWork 1.1 (dans les 3 stragégies de sécurité du runtime : Entreprise, Ordinateur et utilisateur) et ceci dans le groupe de codde All_Code mais sans succès.
1/ Que nous manque-t-il pour pouvoir exécuter cette méthode dans un compte utilisateur limité (qui n'est pas administrateur) ?
2ème problème :
En voulant revenir en arrière sur la modification de la configuration de .NET Framework 1.1, (remettre les niveaux Nothing à la place de FullTrust) je n'arrive plus à lancer aucun exe .net sur le poste.
Erreur signalée lors du lancement d'un exe : "L'application a généré une exception non gérée."
Erreur signalée au lancement de cet outil de configuration : "Echec de l'initialisation du composant de logiciel enfichable Nom: .Net Framework 1.1 Configuration CLSID:{1270E004-F895-42BE-8070-DF90D60CBB75}"
2/ Comment puis-je me sortir de cette impossibilité d'executer des exe .NET
