Bonjour
J'ai un problème de sécurité avec .NET 2 et le remoting.
Lorsque j'essaye d'envoyer un objet du client vers le serveur cela lance
une exception lié à la sécurité.
J'essaye donc depuis de donner les privilèges complets à mon application
cliente mais sans résultat.
Voici ce que j'ai fais :
-création d'un nom fort et ajout de la directive [assembly:
AssemblyKeyFile("protec.snk")] avec l'adresse de ma clef que j'ai généré
avec sn -k protec.snk au client et au serveur .NET REMOTING ainsi qu'au
fichier .dll métier.
Après cela je suis allé dans Outils d'administration->Configuration
Microsoft .NET Framework 2.0 afin d'allouer à mon application .NET 2
d'avantages de droits.
Ensuite je clic sur "Stratégie de sécurité du runtime" puis "Augmenter le
niveau de confiance d'un assembly".
Ensuite je choisis l'adresse du .exe du client .NET REMOTING et choisit de
"faire confiance à toute les assemblys avec la même clef publique
d'assembly". A partir de là, je suppose que le fichier .dll métier, le
serveur et le client .NET REMOTING.
Ensuite je choisis de faire une confiance totale à cette assembly.
Là je m'attend à ceux que le serveur, le client et le fichier .dll qui
partage la même clef bénéficieront des droits complets sur ma machine mais
... ce n'est pas le cas ... j'obtiens toujours la même exception malgré
d'autres tests du même type dans le logiciel de configuration du .NET 2.
Ci-dessous l'exception complète qui est lancée par le client .NET REMOTING
lorsque j'essaye d'envoyer au serveur .NET REMOTING un objet métier
définit dans le fichier .dll que le serveur et le client référence :
Exception non gérée : System.Runtime.Serialization.SerializationException:
En raison de re
strictions de sécurité, le type System.Runtime.Remoting.ObjRef est
inaccessible. ---> Syst
em.Security.SecurityException: Échec de la demande.
à
System.Runtime.Serialization.FormatterServices.nativeGetSafeUninitializedObject(Runti
meType type)
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
L'action qui a échoué était :
Demand
Le type de la première autorisation qui a échoué était :
System.Security.Permissions.SecurityPermission
La première autorisation qui a échoué était :
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
La demande était pour :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
</PermissionSet>
Les seules autorisations permises étaient :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="SerializationFormatter"/>
</PermissionSet>
La méthode qui a causé l'échec était :
System.Runtime.Remoting.Channels.ServerProcessing
ProcessMessage(System.Runtime.Remoting.C
hannels.IServerChannelSinkStack,
System.Runtime.Remoting.Messaging.IMessage, System.Runtim
e.Remoting.Channels.ITransportHeaders, System.IO.Stream,
System.Runtime.Remoting.Messaging
.IMessage ByRef, System.Runtime.Remoting.Channels.ITransportHeaders ByRef,
System.IO.Strea
m ByRef)
--- Fin de la trace de la pile d'exception interne ---
Server stack trace:
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.ParseObject(ParseRecord
p
r)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Parse(ParseRecord
pr)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryObjectWithMapTyped record)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryHeaderEnum binaryHeaderEnum)
à System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler
handler, __BinaryParser serParser, Boolean fCheck, Boolean
isCrossAppDomain, IMethodCallM
essage methodCallMessage)
à
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream
ser
ializationStream, HeaderHandler handler, Boolean fCheck, Boolean
isCrossAppDomain, IMethod
CallMessage methodCallMessage)
à
System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessage(String
o
bjectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel
securityLevel)
à
System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChan
nelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders
requestHeaders, Stream requ
estStream, IMessage& responseMsg, ITransportHeaders& responseHeaders,
Stream& responseStre
am)
Exception rethrown at [0]:
à System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
reqMsg, IMessa
ge retMsg)
à System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
msgData, Int32 t
ype)
à ng.mapping.IDBManager.saveOrUpdateBusinessObject(Object o)
à remoting_client.Program.Main(String[] args) dans C:Documents and
Settingsa.UNI
-24064DMes documentsVisual Studio
2005Projectsmappingremoting_clientProgram.cs:ligne
28
Quelqu'un a une idée d'un truc que j'aurai mal fait ?
Merci d'avance
Bonjour
J'ai un problème de sécurité avec .NET 2 et le remoting.
Lorsque j'essaye d'envoyer un objet du client vers le serveur cela lance
une exception lié à la sécurité.
J'essaye donc depuis de donner les privilèges complets à mon application
cliente mais sans résultat.
Voici ce que j'ai fais :
-création d'un nom fort et ajout de la directive [assembly:
AssemblyKeyFile("protec.snk")] avec l'adresse de ma clef que j'ai généré
avec sn -k protec.snk au client et au serveur .NET REMOTING ainsi qu'au
fichier .dll métier.
Après cela je suis allé dans Outils d'administration->Configuration
Microsoft .NET Framework 2.0 afin d'allouer à mon application .NET 2
d'avantages de droits.
Ensuite je clic sur "Stratégie de sécurité du runtime" puis "Augmenter le
niveau de confiance d'un assembly".
Ensuite je choisis l'adresse du .exe du client .NET REMOTING et choisit de
"faire confiance à toute les assemblys avec la même clef publique
d'assembly". A partir de là, je suppose que le fichier .dll métier, le
serveur et le client .NET REMOTING.
Ensuite je choisis de faire une confiance totale à cette assembly.
Là je m'attend à ceux que le serveur, le client et le fichier .dll qui
partage la même clef bénéficieront des droits complets sur ma machine mais
... ce n'est pas le cas ... j'obtiens toujours la même exception malgré
d'autres tests du même type dans le logiciel de configuration du .NET 2.
Ci-dessous l'exception complète qui est lancée par le client .NET REMOTING
lorsque j'essaye d'envoyer au serveur .NET REMOTING un objet métier
définit dans le fichier .dll que le serveur et le client référence :
Exception non gérée : System.Runtime.Serialization.SerializationException:
En raison de re
strictions de sécurité, le type System.Runtime.Remoting.ObjRef est
inaccessible. ---> Syst
em.Security.SecurityException: Échec de la demande.
à
System.Runtime.Serialization.FormatterServices.nativeGetSafeUninitializedObject(Runti
meType type)
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
L'action qui a échoué était :
Demand
Le type de la première autorisation qui a échoué était :
System.Security.Permissions.SecurityPermission
La première autorisation qui a échoué était :
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
La demande était pour :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
</PermissionSet>
Les seules autorisations permises étaient :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="SerializationFormatter"/>
</PermissionSet>
La méthode qui a causé l'échec était :
System.Runtime.Remoting.Channels.ServerProcessing
ProcessMessage(System.Runtime.Remoting.C
hannels.IServerChannelSinkStack,
System.Runtime.Remoting.Messaging.IMessage, System.Runtim
e.Remoting.Channels.ITransportHeaders, System.IO.Stream,
System.Runtime.Remoting.Messaging
.IMessage ByRef, System.Runtime.Remoting.Channels.ITransportHeaders ByRef,
System.IO.Strea
m ByRef)
--- Fin de la trace de la pile d'exception interne ---
Server stack trace:
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.ParseObject(ParseRecord
p
r)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Parse(ParseRecord
pr)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryObjectWithMapTyped record)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryHeaderEnum binaryHeaderEnum)
à System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler
handler, __BinaryParser serParser, Boolean fCheck, Boolean
isCrossAppDomain, IMethodCallM
essage methodCallMessage)
à
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream
ser
ializationStream, HeaderHandler handler, Boolean fCheck, Boolean
isCrossAppDomain, IMethod
CallMessage methodCallMessage)
à
System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessage(String
o
bjectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel
securityLevel)
à
System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChan
nelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders
requestHeaders, Stream requ
estStream, IMessage& responseMsg, ITransportHeaders& responseHeaders,
Stream& responseStre
am)
Exception rethrown at [0]:
à System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
reqMsg, IMessa
ge retMsg)
à System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
msgData, Int32 t
ype)
à ng.mapping.IDBManager.saveOrUpdateBusinessObject(Object o)
à remoting_client.Program.Main(String[] args) dans C:Documents and
Settingsa.UNI
-24064DMes documentsVisual Studio
2005Projectsmappingremoting_clientProgram.cs:ligne
28
Quelqu'un a une idée d'un truc que j'aurai mal fait ?
Merci d'avance
Bonjour
J'ai un problème de sécurité avec .NET 2 et le remoting.
Lorsque j'essaye d'envoyer un objet du client vers le serveur cela lance
une exception lié à la sécurité.
J'essaye donc depuis de donner les privilèges complets à mon application
cliente mais sans résultat.
Voici ce que j'ai fais :
-création d'un nom fort et ajout de la directive [assembly:
AssemblyKeyFile("protec.snk")] avec l'adresse de ma clef que j'ai généré
avec sn -k protec.snk au client et au serveur .NET REMOTING ainsi qu'au
fichier .dll métier.
Après cela je suis allé dans Outils d'administration->Configuration
Microsoft .NET Framework 2.0 afin d'allouer à mon application .NET 2
d'avantages de droits.
Ensuite je clic sur "Stratégie de sécurité du runtime" puis "Augmenter le
niveau de confiance d'un assembly".
Ensuite je choisis l'adresse du .exe du client .NET REMOTING et choisit de
"faire confiance à toute les assemblys avec la même clef publique
d'assembly". A partir de là, je suppose que le fichier .dll métier, le
serveur et le client .NET REMOTING.
Ensuite je choisis de faire une confiance totale à cette assembly.
Là je m'attend à ceux que le serveur, le client et le fichier .dll qui
partage la même clef bénéficieront des droits complets sur ma machine mais
... ce n'est pas le cas ... j'obtiens toujours la même exception malgré
d'autres tests du même type dans le logiciel de configuration du .NET 2.
Ci-dessous l'exception complète qui est lancée par le client .NET REMOTING
lorsque j'essaye d'envoyer au serveur .NET REMOTING un objet métier
définit dans le fichier .dll que le serveur et le client référence :
Exception non gérée : System.Runtime.Serialization.SerializationException:
En raison de re
strictions de sécurité, le type System.Runtime.Remoting.ObjRef est
inaccessible. ---> Syst
em.Security.SecurityException: Échec de la demande.
à
System.Runtime.Serialization.FormatterServices.nativeGetSafeUninitializedObject(Runti
meType type)
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
L'action qui a échoué était :
Demand
Le type de la première autorisation qui a échoué était :
System.Security.Permissions.SecurityPermission
La première autorisation qui a échoué était :
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
La demande était pour :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
</PermissionSet>
Les seules autorisations permises étaient :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="SerializationFormatter"/>
</PermissionSet>
La méthode qui a causé l'échec était :
System.Runtime.Remoting.Channels.ServerProcessing
ProcessMessage(System.Runtime.Remoting.C
hannels.IServerChannelSinkStack,
System.Runtime.Remoting.Messaging.IMessage, System.Runtim
e.Remoting.Channels.ITransportHeaders, System.IO.Stream,
System.Runtime.Remoting.Messaging
.IMessage ByRef, System.Runtime.Remoting.Channels.ITransportHeaders ByRef,
System.IO.Strea
m ByRef)
--- Fin de la trace de la pile d'exception interne ---
Server stack trace:
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.ParseObject(ParseRecord
p
r)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Parse(ParseRecord
pr)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryObjectWithMapTyped record)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryHeaderEnum binaryHeaderEnum)
à System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler
handler, __BinaryParser serParser, Boolean fCheck, Boolean
isCrossAppDomain, IMethodCallM
essage methodCallMessage)
à
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream
ser
ializationStream, HeaderHandler handler, Boolean fCheck, Boolean
isCrossAppDomain, IMethod
CallMessage methodCallMessage)
à
System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessage(String
o
bjectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel
securityLevel)
à
System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChan
nelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders
requestHeaders, Stream requ
estStream, IMessage& responseMsg, ITransportHeaders& responseHeaders,
Stream& responseStre
am)
Exception rethrown at [0]:
à System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
reqMsg, IMessa
ge retMsg)
à System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
msgData, Int32 t
ype)
à ng.mapping.IDBManager.saveOrUpdateBusinessObject(Object o)
à remoting_client.Program.Main(String[] args) dans C:Documents and
Settingsa.UNI
-24064DMes documentsVisual Studio
2005Projectsmappingremoting_clientProgram.cs:ligne
28
Quelqu'un a une idée d'un truc que j'aurai mal fait ?
Merci d'avance
Il y a aussi les droits de l'utilisateur ayant lancé l'application à
prendre en compte.
--
Paul Bacelar
MVP VC++
"Nico" wrote in message
news:Bonjour
J'ai un problème de sécurité avec .NET 2 et le remoting.
Lorsque j'essaye d'envoyer un objet du client vers le serveur cela lance
une exception lié à la sécurité.
J'essaye donc depuis de donner les privilèges complets à mon application
cliente mais sans résultat.
Voici ce que j'ai fais :
-création d'un nom fort et ajout de la directive [assembly:
AssemblyKeyFile("protec.snk")] avec l'adresse de ma clef que j'ai généré
avec sn -k protec.snk au client et au serveur .NET REMOTING ainsi qu'au
fichier .dll métier.
Après cela je suis allé dans Outils d'administration->Configuration
Microsoft .NET Framework 2.0 afin d'allouer à mon application .NET 2
d'avantages de droits.
Ensuite je clic sur "Stratégie de sécurité du runtime" puis "Augmenter le
niveau de confiance d'un assembly".
Ensuite je choisis l'adresse du .exe du client .NET REMOTING et choisit
de "faire confiance à toute les assemblys avec la même clef publique
d'assembly". A partir de là, je suppose que le fichier .dll métier, le
serveur et le client .NET REMOTING.
Ensuite je choisis de faire une confiance totale à cette assembly.
Là je m'attend à ceux que le serveur, le client et le fichier .dll qui
partage la même clef bénéficieront des droits complets sur ma machine
mais ... ce n'est pas le cas ... j'obtiens toujours la même exception
malgré d'autres tests du même type dans le logiciel de configuration du
.NET 2.
Ci-dessous l'exception complète qui est lancée par le client .NET
REMOTING lorsque j'essaye d'envoyer au serveur .NET REMOTING un objet
métier définit dans le fichier .dll que le serveur et le client référence
:
Exception non gérée :
System.Runtime.Serialization.SerializationException: En raison de re
strictions de sécurité, le type System.Runtime.Remoting.ObjRef est
inaccessible. ---> Syst
em.Security.SecurityException: Échec de la demande.
à
System.Runtime.Serialization.FormatterServices.nativeGetSafeUninitializedObject(Runti
meType type)
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
L'action qui a échoué était :
Demand
Le type de la première autorisation qui a échoué était :
System.Security.Permissions.SecurityPermission
La première autorisation qui a échoué était :
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
La demande était pour :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
</PermissionSet>
Les seules autorisations permises étaient :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="SerializationFormatter"/>
</PermissionSet>
La méthode qui a causé l'échec était :
System.Runtime.Remoting.Channels.ServerProcessing
ProcessMessage(System.Runtime.Remoting.C
hannels.IServerChannelSinkStack,
System.Runtime.Remoting.Messaging.IMessage, System.Runtim
e.Remoting.Channels.ITransportHeaders, System.IO.Stream,
System.Runtime.Remoting.Messaging
.IMessage ByRef, System.Runtime.Remoting.Channels.ITransportHeaders
ByRef, System.IO.Strea
m ByRef)
--- Fin de la trace de la pile d'exception interne ---
Server stack trace:
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.ParseObject(ParseRecord
p
r)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Parse(ParseRecord
pr)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryObjectWithMapTyped record)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryHeaderEnum binaryHeaderEnum)
à System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler
handler, __BinaryParser serParser, Boolean fCheck, Boolean
isCrossAppDomain, IMethodCallM
essage methodCallMessage)
à
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream
ser
ializationStream, HeaderHandler handler, Boolean fCheck, Boolean
isCrossAppDomain, IMethod
CallMessage methodCallMessage)
à
System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessage(String
o
bjectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel
securityLevel)
à
System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChan
nelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders
requestHeaders, Stream requ
estStream, IMessage& responseMsg, ITransportHeaders& responseHeaders,
Stream& responseStre
am)
Exception rethrown at [0]:
à
System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
reqMsg, IMessa
ge retMsg)
à System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
msgData, Int32 t
ype)
à ng.mapping.IDBManager.saveOrUpdateBusinessObject(Object o)
à remoting_client.Program.Main(String[] args) dans C:Documents and
Settingsa.UNI
-24064DMes documentsVisual Studio
2005Projectsmappingremoting_clientProgram.cs:ligne
28
Quelqu'un a une idée d'un truc que j'aurai mal fait ?
Merci d'avance
Il y a aussi les droits de l'utilisateur ayant lancé l'application à
prendre en compte.
--
Paul Bacelar
MVP VC++
"Nico" <nico@AAA.fr> wrote in message
news:egqwNnOeGHA.3948@TK2MSFTNGP03.phx.gbl...
Bonjour
J'ai un problème de sécurité avec .NET 2 et le remoting.
Lorsque j'essaye d'envoyer un objet du client vers le serveur cela lance
une exception lié à la sécurité.
J'essaye donc depuis de donner les privilèges complets à mon application
cliente mais sans résultat.
Voici ce que j'ai fais :
-création d'un nom fort et ajout de la directive [assembly:
AssemblyKeyFile("protec.snk")] avec l'adresse de ma clef que j'ai généré
avec sn -k protec.snk au client et au serveur .NET REMOTING ainsi qu'au
fichier .dll métier.
Après cela je suis allé dans Outils d'administration->Configuration
Microsoft .NET Framework 2.0 afin d'allouer à mon application .NET 2
d'avantages de droits.
Ensuite je clic sur "Stratégie de sécurité du runtime" puis "Augmenter le
niveau de confiance d'un assembly".
Ensuite je choisis l'adresse du .exe du client .NET REMOTING et choisit
de "faire confiance à toute les assemblys avec la même clef publique
d'assembly". A partir de là, je suppose que le fichier .dll métier, le
serveur et le client .NET REMOTING.
Ensuite je choisis de faire une confiance totale à cette assembly.
Là je m'attend à ceux que le serveur, le client et le fichier .dll qui
partage la même clef bénéficieront des droits complets sur ma machine
mais ... ce n'est pas le cas ... j'obtiens toujours la même exception
malgré d'autres tests du même type dans le logiciel de configuration du
.NET 2.
Ci-dessous l'exception complète qui est lancée par le client .NET
REMOTING lorsque j'essaye d'envoyer au serveur .NET REMOTING un objet
métier définit dans le fichier .dll que le serveur et le client référence
:
Exception non gérée :
System.Runtime.Serialization.SerializationException: En raison de re
strictions de sécurité, le type System.Runtime.Remoting.ObjRef est
inaccessible. ---> Syst
em.Security.SecurityException: Échec de la demande.
à
System.Runtime.Serialization.FormatterServices.nativeGetSafeUninitializedObject(Runti
meType type)
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
L'action qui a échoué était :
Demand
Le type de la première autorisation qui a échoué était :
System.Security.Permissions.SecurityPermission
La première autorisation qui a échoué était :
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
La demande était pour :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
</PermissionSet>
Les seules autorisations permises étaient :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="SerializationFormatter"/>
</PermissionSet>
La méthode qui a causé l'échec était :
System.Runtime.Remoting.Channels.ServerProcessing
ProcessMessage(System.Runtime.Remoting.C
hannels.IServerChannelSinkStack,
System.Runtime.Remoting.Messaging.IMessage, System.Runtim
e.Remoting.Channels.ITransportHeaders, System.IO.Stream,
System.Runtime.Remoting.Messaging
.IMessage ByRef, System.Runtime.Remoting.Channels.ITransportHeaders
ByRef, System.IO.Strea
m ByRef)
--- Fin de la trace de la pile d'exception interne ---
Server stack trace:
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.ParseObject(ParseRecord
p
r)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Parse(ParseRecord
pr)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryObjectWithMapTyped record)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryHeaderEnum binaryHeaderEnum)
à System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler
handler, __BinaryParser serParser, Boolean fCheck, Boolean
isCrossAppDomain, IMethodCallM
essage methodCallMessage)
à
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream
ser
ializationStream, HeaderHandler handler, Boolean fCheck, Boolean
isCrossAppDomain, IMethod
CallMessage methodCallMessage)
à
System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessage(String
o
bjectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel
securityLevel)
à
System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChan
nelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders
requestHeaders, Stream requ
estStream, IMessage& responseMsg, ITransportHeaders& responseHeaders,
Stream& responseStre
am)
Exception rethrown at [0]:
à
System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
reqMsg, IMessa
ge retMsg)
à System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
msgData, Int32 t
ype)
à ng.mapping.IDBManager.saveOrUpdateBusinessObject(Object o)
à remoting_client.Program.Main(String[] args) dans C:Documents and
Settingsa.UNI
-24064DMes documentsVisual Studio
2005Projectsmappingremoting_clientProgram.cs:ligne
28
Quelqu'un a une idée d'un truc que j'aurai mal fait ?
Merci d'avance
Il y a aussi les droits de l'utilisateur ayant lancé l'application à
prendre en compte.
--
Paul Bacelar
MVP VC++
"Nico" wrote in message
news:Bonjour
J'ai un problème de sécurité avec .NET 2 et le remoting.
Lorsque j'essaye d'envoyer un objet du client vers le serveur cela lance
une exception lié à la sécurité.
J'essaye donc depuis de donner les privilèges complets à mon application
cliente mais sans résultat.
Voici ce que j'ai fais :
-création d'un nom fort et ajout de la directive [assembly:
AssemblyKeyFile("protec.snk")] avec l'adresse de ma clef que j'ai généré
avec sn -k protec.snk au client et au serveur .NET REMOTING ainsi qu'au
fichier .dll métier.
Après cela je suis allé dans Outils d'administration->Configuration
Microsoft .NET Framework 2.0 afin d'allouer à mon application .NET 2
d'avantages de droits.
Ensuite je clic sur "Stratégie de sécurité du runtime" puis "Augmenter le
niveau de confiance d'un assembly".
Ensuite je choisis l'adresse du .exe du client .NET REMOTING et choisit
de "faire confiance à toute les assemblys avec la même clef publique
d'assembly". A partir de là, je suppose que le fichier .dll métier, le
serveur et le client .NET REMOTING.
Ensuite je choisis de faire une confiance totale à cette assembly.
Là je m'attend à ceux que le serveur, le client et le fichier .dll qui
partage la même clef bénéficieront des droits complets sur ma machine
mais ... ce n'est pas le cas ... j'obtiens toujours la même exception
malgré d'autres tests du même type dans le logiciel de configuration du
.NET 2.
Ci-dessous l'exception complète qui est lancée par le client .NET
REMOTING lorsque j'essaye d'envoyer au serveur .NET REMOTING un objet
métier définit dans le fichier .dll que le serveur et le client référence
:
Exception non gérée :
System.Runtime.Serialization.SerializationException: En raison de re
strictions de sécurité, le type System.Runtime.Remoting.ObjRef est
inaccessible. ---> Syst
em.Security.SecurityException: Échec de la demande.
à
System.Runtime.Serialization.FormatterServices.nativeGetSafeUninitializedObject(Runti
meType type)
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
L'action qui a échoué était :
Demand
Le type de la première autorisation qui a échoué était :
System.Security.Permissions.SecurityPermission
La première autorisation qui a échoué était :
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
La demande était pour :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
</PermissionSet>
Les seules autorisations permises étaient :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="SerializationFormatter"/>
</PermissionSet>
La méthode qui a causé l'échec était :
System.Runtime.Remoting.Channels.ServerProcessing
ProcessMessage(System.Runtime.Remoting.C
hannels.IServerChannelSinkStack,
System.Runtime.Remoting.Messaging.IMessage, System.Runtim
e.Remoting.Channels.ITransportHeaders, System.IO.Stream,
System.Runtime.Remoting.Messaging
.IMessage ByRef, System.Runtime.Remoting.Channels.ITransportHeaders
ByRef, System.IO.Strea
m ByRef)
--- Fin de la trace de la pile d'exception interne ---
Server stack trace:
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.ParseObject(ParseRecord
p
r)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Parse(ParseRecord
pr)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryObjectWithMapTyped record)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryHeaderEnum binaryHeaderEnum)
à System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler
handler, __BinaryParser serParser, Boolean fCheck, Boolean
isCrossAppDomain, IMethodCallM
essage methodCallMessage)
à
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream
ser
ializationStream, HeaderHandler handler, Boolean fCheck, Boolean
isCrossAppDomain, IMethod
CallMessage methodCallMessage)
à
System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessage(String
o
bjectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel
securityLevel)
à
System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChan
nelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders
requestHeaders, Stream requ
estStream, IMessage& responseMsg, ITransportHeaders& responseHeaders,
Stream& responseStre
am)
Exception rethrown at [0]:
à
System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
reqMsg, IMessa
ge retMsg)
à System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
msgData, Int32 t
ype)
à ng.mapping.IDBManager.saveOrUpdateBusinessObject(Object o)
à remoting_client.Program.Main(String[] args) dans C:Documents and
Settingsa.UNI
-24064DMes documentsVisual Studio
2005Projectsmappingremoting_clientProgram.cs:ligne
28
Quelqu'un a une idée d'un truc que j'aurai mal fait ?
Merci d'avance
Bonjour
J'ai un problème de sécurité avec .NET 2 et le remoting.
Lorsque j'essaye d'envoyer un objet du client vers le serveur cela lance
une exception lié à la sécurité.
J'essaye donc depuis de donner les privilèges complets à mon application
cliente mais sans résultat.
Voici ce que j'ai fais :
-création d'un nom fort et ajout de la directive [assembly:
AssemblyKeyFile("protec.snk")] avec l'adresse de ma clef que j'ai généré
avec sn -k protec.snk au client et au serveur .NET REMOTING ainsi qu'au
fichier .dll métier.
Après cela je suis allé dans Outils d'administration->Configuration
Microsoft .NET Framework 2.0 afin d'allouer à mon application .NET 2
d'avantages de droits.
Ensuite je clic sur "Stratégie de sécurité du runtime" puis "Augmenter le
niveau de confiance d'un assembly".
Ensuite je choisis l'adresse du .exe du client .NET REMOTING et choisit de
"faire confiance à toute les assemblys avec la même clef publique
d'assembly". A partir de là, je suppose que le fichier .dll métier, le
serveur et le client .NET REMOTING.
Ensuite je choisis de faire une confiance totale à cette assembly.
Là je m'attend à ceux que le serveur, le client et le fichier .dll qui
partage la même clef bénéficieront des droits complets sur ma machine mais
... ce n'est pas le cas ... j'obtiens toujours la même exception malgré
d'autres tests du même type dans le logiciel de configuration du .NET 2.
Ci-dessous l'exception complète qui est lancée par le client .NET REMOTING
lorsque j'essaye d'envoyer au serveur .NET REMOTING un objet métier
définit dans le fichier .dll que le serveur et le client référence :
Exception non gérée : System.Runtime.Serialization.SerializationException:
En raison de re
strictions de sécurité, le type System.Runtime.Remoting.ObjRef est
inaccessible. ---> Syst
em.Security.SecurityException: Échec de la demande.
à
System.Runtime.Serialization.FormatterServices.nativeGetSafeUninitializedObject(Runti
meType type)
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
L'action qui a échoué était :
Demand
Le type de la première autorisation qui a échoué était :
System.Security.Permissions.SecurityPermission
La première autorisation qui a échoué était :
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
La demande était pour :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
</PermissionSet>
Les seules autorisations permises étaient :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="SerializationFormatter"/>
</PermissionSet>
La méthode qui a causé l'échec était :
System.Runtime.Remoting.Channels.ServerProcessing
ProcessMessage(System.Runtime.Remoting.C
hannels.IServerChannelSinkStack,
System.Runtime.Remoting.Messaging.IMessage, System.Runtim
e.Remoting.Channels.ITransportHeaders, System.IO.Stream,
System.Runtime.Remoting.Messaging
.IMessage ByRef, System.Runtime.Remoting.Channels.ITransportHeaders ByRef,
System.IO.Strea
m ByRef)
--- Fin de la trace de la pile d'exception interne ---
Server stack trace:
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.ParseObject(ParseRecord
p
r)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Parse(ParseRecord
pr)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryObjectWithMapTyped record)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryHeaderEnum binaryHeaderEnum)
à System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler
handler, __BinaryParser serParser, Boolean fCheck, Boolean
isCrossAppDomain, IMethodCallM
essage methodCallMessage)
à
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream
ser
ializationStream, HeaderHandler handler, Boolean fCheck, Boolean
isCrossAppDomain, IMethod
CallMessage methodCallMessage)
à
System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessage(String
o
bjectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel
securityLevel)
à
System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChan
nelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders
requestHeaders, Stream requ
estStream, IMessage& responseMsg, ITransportHeaders& responseHeaders,
Stream& responseStre
am)
Exception rethrown at [0]:
à System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
reqMsg, IMessa
ge retMsg)
à System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
msgData, Int32 t
ype)
à ng.mapping.IDBManager.saveOrUpdateBusinessObject(Object o)
à remoting_client.Program.Main(String[] args) dans C:Documents and
Settingsa.UNI
-24064DMes documentsVisual Studio
2005Projectsmappingremoting_clientProgram.cs:ligne
28
Quelqu'un a une idée d'un truc que j'aurai mal fait ?
Merci d'avance
Bonjour
J'ai un problème de sécurité avec .NET 2 et le remoting.
Lorsque j'essaye d'envoyer un objet du client vers le serveur cela lance
une exception lié à la sécurité.
J'essaye donc depuis de donner les privilèges complets à mon application
cliente mais sans résultat.
Voici ce que j'ai fais :
-création d'un nom fort et ajout de la directive [assembly:
AssemblyKeyFile("protec.snk")] avec l'adresse de ma clef que j'ai généré
avec sn -k protec.snk au client et au serveur .NET REMOTING ainsi qu'au
fichier .dll métier.
Après cela je suis allé dans Outils d'administration->Configuration
Microsoft .NET Framework 2.0 afin d'allouer à mon application .NET 2
d'avantages de droits.
Ensuite je clic sur "Stratégie de sécurité du runtime" puis "Augmenter le
niveau de confiance d'un assembly".
Ensuite je choisis l'adresse du .exe du client .NET REMOTING et choisit de
"faire confiance à toute les assemblys avec la même clef publique
d'assembly". A partir de là, je suppose que le fichier .dll métier, le
serveur et le client .NET REMOTING.
Ensuite je choisis de faire une confiance totale à cette assembly.
Là je m'attend à ceux que le serveur, le client et le fichier .dll qui
partage la même clef bénéficieront des droits complets sur ma machine mais
... ce n'est pas le cas ... j'obtiens toujours la même exception malgré
d'autres tests du même type dans le logiciel de configuration du .NET 2.
Ci-dessous l'exception complète qui est lancée par le client .NET REMOTING
lorsque j'essaye d'envoyer au serveur .NET REMOTING un objet métier
définit dans le fichier .dll que le serveur et le client référence :
Exception non gérée : System.Runtime.Serialization.SerializationException:
En raison de re
strictions de sécurité, le type System.Runtime.Remoting.ObjRef est
inaccessible. ---> Syst
em.Security.SecurityException: Échec de la demande.
à
System.Runtime.Serialization.FormatterServices.nativeGetSafeUninitializedObject(Runti
meType type)
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
L'action qui a échoué était :
Demand
Le type de la première autorisation qui a échoué était :
System.Security.Permissions.SecurityPermission
La première autorisation qui a échoué était :
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
La demande était pour :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
</PermissionSet>
Les seules autorisations permises étaient :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="SerializationFormatter"/>
</PermissionSet>
La méthode qui a causé l'échec était :
System.Runtime.Remoting.Channels.ServerProcessing
ProcessMessage(System.Runtime.Remoting.C
hannels.IServerChannelSinkStack,
System.Runtime.Remoting.Messaging.IMessage, System.Runtim
e.Remoting.Channels.ITransportHeaders, System.IO.Stream,
System.Runtime.Remoting.Messaging
.IMessage ByRef, System.Runtime.Remoting.Channels.ITransportHeaders ByRef,
System.IO.Strea
m ByRef)
--- Fin de la trace de la pile d'exception interne ---
Server stack trace:
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.ParseObject(ParseRecord
p
r)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Parse(ParseRecord
pr)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryObjectWithMapTyped record)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryHeaderEnum binaryHeaderEnum)
à System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler
handler, __BinaryParser serParser, Boolean fCheck, Boolean
isCrossAppDomain, IMethodCallM
essage methodCallMessage)
à
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream
ser
ializationStream, HeaderHandler handler, Boolean fCheck, Boolean
isCrossAppDomain, IMethod
CallMessage methodCallMessage)
à
System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessage(String
o
bjectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel
securityLevel)
à
System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChan
nelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders
requestHeaders, Stream requ
estStream, IMessage& responseMsg, ITransportHeaders& responseHeaders,
Stream& responseStre
am)
Exception rethrown at [0]:
à System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
reqMsg, IMessa
ge retMsg)
à System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
msgData, Int32 t
ype)
à ng.mapping.IDBManager.saveOrUpdateBusinessObject(Object o)
à remoting_client.Program.Main(String[] args) dans C:Documents and
Settingsa.UNI
-24064DMes documentsVisual Studio
2005Projectsmappingremoting_clientProgram.cs:ligne
28
Quelqu'un a une idée d'un truc que j'aurai mal fait ?
Merci d'avance
Bonjour
J'ai un problème de sécurité avec .NET 2 et le remoting.
Lorsque j'essaye d'envoyer un objet du client vers le serveur cela lance
une exception lié à la sécurité.
J'essaye donc depuis de donner les privilèges complets à mon application
cliente mais sans résultat.
Voici ce que j'ai fais :
-création d'un nom fort et ajout de la directive [assembly:
AssemblyKeyFile("protec.snk")] avec l'adresse de ma clef que j'ai généré
avec sn -k protec.snk au client et au serveur .NET REMOTING ainsi qu'au
fichier .dll métier.
Après cela je suis allé dans Outils d'administration->Configuration
Microsoft .NET Framework 2.0 afin d'allouer à mon application .NET 2
d'avantages de droits.
Ensuite je clic sur "Stratégie de sécurité du runtime" puis "Augmenter le
niveau de confiance d'un assembly".
Ensuite je choisis l'adresse du .exe du client .NET REMOTING et choisit de
"faire confiance à toute les assemblys avec la même clef publique
d'assembly". A partir de là, je suppose que le fichier .dll métier, le
serveur et le client .NET REMOTING.
Ensuite je choisis de faire une confiance totale à cette assembly.
Là je m'attend à ceux que le serveur, le client et le fichier .dll qui
partage la même clef bénéficieront des droits complets sur ma machine mais
... ce n'est pas le cas ... j'obtiens toujours la même exception malgré
d'autres tests du même type dans le logiciel de configuration du .NET 2.
Ci-dessous l'exception complète qui est lancée par le client .NET REMOTING
lorsque j'essaye d'envoyer au serveur .NET REMOTING un objet métier
définit dans le fichier .dll que le serveur et le client référence :
Exception non gérée : System.Runtime.Serialization.SerializationException:
En raison de re
strictions de sécurité, le type System.Runtime.Remoting.ObjRef est
inaccessible. ---> Syst
em.Security.SecurityException: Échec de la demande.
à
System.Runtime.Serialization.FormatterServices.nativeGetSafeUninitializedObject(Runti
meType type)
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
L'action qui a échoué était :
Demand
Le type de la première autorisation qui a échoué était :
System.Security.Permissions.SecurityPermission
La première autorisation qui a échoué était :
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
La demande était pour :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
</PermissionSet>
Les seules autorisations permises étaient :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="SerializationFormatter"/>
</PermissionSet>
La méthode qui a causé l'échec était :
System.Runtime.Remoting.Channels.ServerProcessing
ProcessMessage(System.Runtime.Remoting.C
hannels.IServerChannelSinkStack,
System.Runtime.Remoting.Messaging.IMessage, System.Runtim
e.Remoting.Channels.ITransportHeaders, System.IO.Stream,
System.Runtime.Remoting.Messaging
.IMessage ByRef, System.Runtime.Remoting.Channels.ITransportHeaders ByRef,
System.IO.Strea
m ByRef)
--- Fin de la trace de la pile d'exception interne ---
Server stack trace:
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.ParseObject(ParseRecord
p
r)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Parse(ParseRecord
pr)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryObjectWithMapTyped record)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryHeaderEnum binaryHeaderEnum)
à System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler
handler, __BinaryParser serParser, Boolean fCheck, Boolean
isCrossAppDomain, IMethodCallM
essage methodCallMessage)
à
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream
ser
ializationStream, HeaderHandler handler, Boolean fCheck, Boolean
isCrossAppDomain, IMethod
CallMessage methodCallMessage)
à
System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessage(String
o
bjectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel
securityLevel)
à
System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChan
nelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders
requestHeaders, Stream requ
estStream, IMessage& responseMsg, ITransportHeaders& responseHeaders,
Stream& responseStre
am)
Exception rethrown at [0]:
à System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
reqMsg, IMessa
ge retMsg)
à System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
msgData, Int32 t
ype)
à ng.mapping.IDBManager.saveOrUpdateBusinessObject(Object o)
à remoting_client.Program.Main(String[] args) dans C:Documents and
Settingsa.UNI
-24064DMes documentsVisual Studio
2005Projectsmappingremoting_clientProgram.cs:ligne
28
Quelqu'un a une idée d'un truc que j'aurai mal fait ?
Merci d'avance
http://dotnet247.com/247reference/msgs/53/268056.aspx
http://www.thinktecture.com/Resources/RemotingFAQ/Changes2003.html
Simon.
www.softfluent.com
"Nico" a écrit dans le message de news:Bonjour
J'ai un problème de sécurité avec .NET 2 et le remoting.
Lorsque j'essaye d'envoyer un objet du client vers le serveur cela lance
une exception lié à la sécurité.
J'essaye donc depuis de donner les privilèges complets à mon application
cliente mais sans résultat.
Voici ce que j'ai fais :
-création d'un nom fort et ajout de la directive [assembly:
AssemblyKeyFile("protec.snk")] avec l'adresse de ma clef que j'ai généré
avec sn -k protec.snk au client et au serveur .NET REMOTING ainsi qu'au
fichier .dll métier.
Après cela je suis allé dans Outils d'administration->Configuration
Microsoft .NET Framework 2.0 afin d'allouer à mon application .NET 2
d'avantages de droits.
Ensuite je clic sur "Stratégie de sécurité du runtime" puis "Augmenter le
niveau de confiance d'un assembly".
Ensuite je choisis l'adresse du .exe du client .NET REMOTING et choisit
de "faire confiance à toute les assemblys avec la même clef publique
d'assembly". A partir de là, je suppose que le fichier .dll métier, le
serveur et le client .NET REMOTING.
Ensuite je choisis de faire une confiance totale à cette assembly.
Là je m'attend à ceux que le serveur, le client et le fichier .dll qui
partage la même clef bénéficieront des droits complets sur ma machine
mais ... ce n'est pas le cas ... j'obtiens toujours la même exception
malgré d'autres tests du même type dans le logiciel de configuration du
.NET 2.
Ci-dessous l'exception complète qui est lancée par le client .NET
REMOTING lorsque j'essaye d'envoyer au serveur .NET REMOTING un objet
métier définit dans le fichier .dll que le serveur et le client référence
:
Exception non gérée :
System.Runtime.Serialization.SerializationException: En raison de re
strictions de sécurité, le type System.Runtime.Remoting.ObjRef est
inaccessible. ---> Syst
em.Security.SecurityException: Échec de la demande.
à
System.Runtime.Serialization.FormatterServices.nativeGetSafeUninitializedObject(Runti
meType type)
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
L'action qui a échoué était :
Demand
Le type de la première autorisation qui a échoué était :
System.Security.Permissions.SecurityPermission
La première autorisation qui a échoué était :
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
La demande était pour :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
</PermissionSet>
Les seules autorisations permises étaient :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="SerializationFormatter"/>
</PermissionSet>
La méthode qui a causé l'échec était :
System.Runtime.Remoting.Channels.ServerProcessing
ProcessMessage(System.Runtime.Remoting.C
hannels.IServerChannelSinkStack,
System.Runtime.Remoting.Messaging.IMessage, System.Runtim
e.Remoting.Channels.ITransportHeaders, System.IO.Stream,
System.Runtime.Remoting.Messaging
.IMessage ByRef, System.Runtime.Remoting.Channels.ITransportHeaders
ByRef, System.IO.Strea
m ByRef)
--- Fin de la trace de la pile d'exception interne ---
Server stack trace:
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.ParseObject(ParseRecord
p
r)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Parse(ParseRecord
pr)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryObjectWithMapTyped record)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryHeaderEnum binaryHeaderEnum)
à System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler
handler, __BinaryParser serParser, Boolean fCheck, Boolean
isCrossAppDomain, IMethodCallM
essage methodCallMessage)
à
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream
ser
ializationStream, HeaderHandler handler, Boolean fCheck, Boolean
isCrossAppDomain, IMethod
CallMessage methodCallMessage)
à
System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessage(String
o
bjectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel
securityLevel)
à
System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChan
nelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders
requestHeaders, Stream requ
estStream, IMessage& responseMsg, ITransportHeaders& responseHeaders,
Stream& responseStre
am)
Exception rethrown at [0]:
à
System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
reqMsg, IMessa
ge retMsg)
à System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
msgData, Int32 t
ype)
à ng.mapping.IDBManager.saveOrUpdateBusinessObject(Object o)
à remoting_client.Program.Main(String[] args) dans C:Documents and
Settingsa.UNI
-24064DMes documentsVisual Studio
2005Projectsmappingremoting_clientProgram.cs:ligne
28
Quelqu'un a une idée d'un truc que j'aurai mal fait ?
Merci d'avance
http://dotnet247.com/247reference/msgs/53/268056.aspx
http://www.thinktecture.com/Resources/RemotingFAQ/Changes2003.html
Simon.
www.softfluent.com
"Nico" <nico@AAA.fr> a écrit dans le message de news:
egqwNnOeGHA.3948@TK2MSFTNGP03.phx.gbl...
Bonjour
J'ai un problème de sécurité avec .NET 2 et le remoting.
Lorsque j'essaye d'envoyer un objet du client vers le serveur cela lance
une exception lié à la sécurité.
J'essaye donc depuis de donner les privilèges complets à mon application
cliente mais sans résultat.
Voici ce que j'ai fais :
-création d'un nom fort et ajout de la directive [assembly:
AssemblyKeyFile("protec.snk")] avec l'adresse de ma clef que j'ai généré
avec sn -k protec.snk au client et au serveur .NET REMOTING ainsi qu'au
fichier .dll métier.
Après cela je suis allé dans Outils d'administration->Configuration
Microsoft .NET Framework 2.0 afin d'allouer à mon application .NET 2
d'avantages de droits.
Ensuite je clic sur "Stratégie de sécurité du runtime" puis "Augmenter le
niveau de confiance d'un assembly".
Ensuite je choisis l'adresse du .exe du client .NET REMOTING et choisit
de "faire confiance à toute les assemblys avec la même clef publique
d'assembly". A partir de là, je suppose que le fichier .dll métier, le
serveur et le client .NET REMOTING.
Ensuite je choisis de faire une confiance totale à cette assembly.
Là je m'attend à ceux que le serveur, le client et le fichier .dll qui
partage la même clef bénéficieront des droits complets sur ma machine
mais ... ce n'est pas le cas ... j'obtiens toujours la même exception
malgré d'autres tests du même type dans le logiciel de configuration du
.NET 2.
Ci-dessous l'exception complète qui est lancée par le client .NET
REMOTING lorsque j'essaye d'envoyer au serveur .NET REMOTING un objet
métier définit dans le fichier .dll que le serveur et le client référence
:
Exception non gérée :
System.Runtime.Serialization.SerializationException: En raison de re
strictions de sécurité, le type System.Runtime.Remoting.ObjRef est
inaccessible. ---> Syst
em.Security.SecurityException: Échec de la demande.
à
System.Runtime.Serialization.FormatterServices.nativeGetSafeUninitializedObject(Runti
meType type)
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
L'action qui a échoué était :
Demand
Le type de la première autorisation qui a échoué était :
System.Security.Permissions.SecurityPermission
La première autorisation qui a échoué était :
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
La demande était pour :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
</PermissionSet>
Les seules autorisations permises étaient :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="SerializationFormatter"/>
</PermissionSet>
La méthode qui a causé l'échec était :
System.Runtime.Remoting.Channels.ServerProcessing
ProcessMessage(System.Runtime.Remoting.C
hannels.IServerChannelSinkStack,
System.Runtime.Remoting.Messaging.IMessage, System.Runtim
e.Remoting.Channels.ITransportHeaders, System.IO.Stream,
System.Runtime.Remoting.Messaging
.IMessage ByRef, System.Runtime.Remoting.Channels.ITransportHeaders
ByRef, System.IO.Strea
m ByRef)
--- Fin de la trace de la pile d'exception interne ---
Server stack trace:
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.ParseObject(ParseRecord
p
r)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Parse(ParseRecord
pr)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryObjectWithMapTyped record)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryHeaderEnum binaryHeaderEnum)
à System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler
handler, __BinaryParser serParser, Boolean fCheck, Boolean
isCrossAppDomain, IMethodCallM
essage methodCallMessage)
à
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream
ser
ializationStream, HeaderHandler handler, Boolean fCheck, Boolean
isCrossAppDomain, IMethod
CallMessage methodCallMessage)
à
System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessage(String
o
bjectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel
securityLevel)
à
System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChan
nelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders
requestHeaders, Stream requ
estStream, IMessage& responseMsg, ITransportHeaders& responseHeaders,
Stream& responseStre
am)
Exception rethrown at [0]:
à
System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
reqMsg, IMessa
ge retMsg)
à System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
msgData, Int32 t
ype)
à ng.mapping.IDBManager.saveOrUpdateBusinessObject(Object o)
à remoting_client.Program.Main(String[] args) dans C:Documents and
Settingsa.UNI
-24064DMes documentsVisual Studio
2005Projectsmappingremoting_clientProgram.cs:ligne
28
Quelqu'un a une idée d'un truc que j'aurai mal fait ?
Merci d'avance
http://dotnet247.com/247reference/msgs/53/268056.aspx
http://www.thinktecture.com/Resources/RemotingFAQ/Changes2003.html
Simon.
www.softfluent.com
"Nico" a écrit dans le message de news:Bonjour
J'ai un problème de sécurité avec .NET 2 et le remoting.
Lorsque j'essaye d'envoyer un objet du client vers le serveur cela lance
une exception lié à la sécurité.
J'essaye donc depuis de donner les privilèges complets à mon application
cliente mais sans résultat.
Voici ce que j'ai fais :
-création d'un nom fort et ajout de la directive [assembly:
AssemblyKeyFile("protec.snk")] avec l'adresse de ma clef que j'ai généré
avec sn -k protec.snk au client et au serveur .NET REMOTING ainsi qu'au
fichier .dll métier.
Après cela je suis allé dans Outils d'administration->Configuration
Microsoft .NET Framework 2.0 afin d'allouer à mon application .NET 2
d'avantages de droits.
Ensuite je clic sur "Stratégie de sécurité du runtime" puis "Augmenter le
niveau de confiance d'un assembly".
Ensuite je choisis l'adresse du .exe du client .NET REMOTING et choisit
de "faire confiance à toute les assemblys avec la même clef publique
d'assembly". A partir de là, je suppose que le fichier .dll métier, le
serveur et le client .NET REMOTING.
Ensuite je choisis de faire une confiance totale à cette assembly.
Là je m'attend à ceux que le serveur, le client et le fichier .dll qui
partage la même clef bénéficieront des droits complets sur ma machine
mais ... ce n'est pas le cas ... j'obtiens toujours la même exception
malgré d'autres tests du même type dans le logiciel de configuration du
.NET 2.
Ci-dessous l'exception complète qui est lancée par le client .NET
REMOTING lorsque j'essaye d'envoyer au serveur .NET REMOTING un objet
métier définit dans le fichier .dll que le serveur et le client référence
:
Exception non gérée :
System.Runtime.Serialization.SerializationException: En raison de re
strictions de sécurité, le type System.Runtime.Remoting.ObjRef est
inaccessible. ---> Syst
em.Security.SecurityException: Échec de la demande.
à
System.Runtime.Serialization.FormatterServices.nativeGetSafeUninitializedObject(Runti
meType type)
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
L'action qui a échoué était :
Demand
Le type de la première autorisation qui a échoué était :
System.Security.Permissions.SecurityPermission
La première autorisation qui a échoué était :
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
La demande était pour :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
</PermissionSet>
Les seules autorisations permises étaient :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="SerializationFormatter"/>
</PermissionSet>
La méthode qui a causé l'échec était :
System.Runtime.Remoting.Channels.ServerProcessing
ProcessMessage(System.Runtime.Remoting.C
hannels.IServerChannelSinkStack,
System.Runtime.Remoting.Messaging.IMessage, System.Runtim
e.Remoting.Channels.ITransportHeaders, System.IO.Stream,
System.Runtime.Remoting.Messaging
.IMessage ByRef, System.Runtime.Remoting.Channels.ITransportHeaders
ByRef, System.IO.Strea
m ByRef)
--- Fin de la trace de la pile d'exception interne ---
Server stack trace:
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.ParseObject(ParseRecord
p
r)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Parse(ParseRecord
pr)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryObjectWithMapTyped record)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryHeaderEnum binaryHeaderEnum)
à System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler
handler, __BinaryParser serParser, Boolean fCheck, Boolean
isCrossAppDomain, IMethodCallM
essage methodCallMessage)
à
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream
ser
ializationStream, HeaderHandler handler, Boolean fCheck, Boolean
isCrossAppDomain, IMethod
CallMessage methodCallMessage)
à
System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessage(String
o
bjectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel
securityLevel)
à
System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChan
nelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders
requestHeaders, Stream requ
estStream, IMessage& responseMsg, ITransportHeaders& responseHeaders,
Stream& responseStre
am)
Exception rethrown at [0]:
à
System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
reqMsg, IMessa
ge retMsg)
à System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
msgData, Int32 t
ype)
à ng.mapping.IDBManager.saveOrUpdateBusinessObject(Object o)
à remoting_client.Program.Main(String[] args) dans C:Documents and
Settingsa.UNI
-24064DMes documentsVisual Studio
2005Projectsmappingremoting_clientProgram.cs:ligne
28
Quelqu'un a une idée d'un truc que j'aurai mal fait ?
Merci d'avance