{Изучаю .NET Remoting, тестируя его VB.NET, пишу сюда потому как сама технология не затрагивает язык}

Не могу врубиться в чем дело! Помогите плз, кто сталкивался с такой проблемой!

есть две библиотеки: RemotingInterfacesLIB и RemotingClassesLIB
есть консольное приложение сервер(хост для удаленного объекта с режимом Singleton) и есть клиентское.

В RemotingInterfacesLIB есть всего один интрефейс, а в RemotingClassesLIB - одна реализация этого интерфейса.

В клиенте я навешиваюсь на событие удаленного объекта.
Все прекрасно, отлично работает при тестировании на одном компе.
Но попробовал перенести серверную часть (все что было в папке bin) на другой комп в локальной сети, как тут же в клиенте вывалился эксепшн:
Server encountered an internal error. For more information, turn on customErrors in the server's .config file.

Убираю прикрепление к событию, все в порядке, вызываю методы удаленного объекта чтобы убедиться в том что он действительно создан на сервере, а не локально.

В принципе объект на сервере создается в любом случае, даже после ошибки.
Ну блин в голову не приходит в чем дело!!! Когда на одном компе проверял (сервер и клиент) b вешался на событие , все работало!!! Перенес на другой комп сервер, перестало работать....
Блин ребята, срочно поможите кто может! Спасибо всем! Очень срочно жду!

Попробуй скопировать на сервер сборку клиента.

Скопировал, без нее и на одном компе не работало...

Вот что я нашел в нете по этому поводу

Цитата

Exceptions are serializable (ISerializable too). Exceptions are serialized from the server back the client. Thus if you see a client side exception with the following stack trace, there is a good chance you are actually seeing an exception which was thrown on the server: [OutOfMemoryException: Exception of type System.OutOfMemoryException was thrown.] [TargetInvocationException: Exception has been thrown by the target of an invocation.]System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) Starting in v1.1 of the framework, for security reasons server exceptions dont propogate to the client by default, if the client isnt on the same machine as the server. Instead the client will see a generic exception of this form: System.Runtime.Remoting.RemotingException: Server encountered an internal error. For more information, turn on customErrors in the server's .config file. For the server to flow exceptions add the following to the server side config file <configuration>         <system.runtime.remoting>               <customErrors mode="Off"/>         </system.runtime.remoting> </configuration>

Заодно проверь, сервер и клиент ссылаются на одну и ту же версию объекта?

после того как выклычил customErrors в конфиге на сервере, вот что выводит:

Type System.DelegateSerializationHolder and the types derived from it (such as System.DelegateSerializationHolder) are not permitted to be deserialized at this security level.


Слушай, а может быть это из-за того, что компилю прогу я под Фреймворк v1.0, а на удаленном компе стоит v1.1

блин... терзает смутное подозрение что v1.1 не поддерживает работу v1.0 .....
Добавлено @ 09:35
Извеняюсь за вопрос не по названию темы:
Если это из-за версий Framework'a, то как можно сконфигурировать MSVS .NET 2002, чтобы он при компиляции использовал Framework v1.1

Сам Framework v1.1 у меня уже стоит на компе....


а пока пойду компилить вручную, через коммандную строку....

Попробуй в визарде конфигурации .NET Framework добавить свою локальную сеть в зону FullTrust (но только на время, для тестирования) на компе сервера.

Короче поставил себе MSVS .NET с версией FW 1.1

Теперь вааще блин... даже когда на одном компе запускаещь (сервера и клиента) выводит исключение:

Type System.DelegateSerializationHolder and the types derived from it (such as System.DelegateSerializationHolder) are not permitted to be deserialized at this security level.

Тип System.DelegateSerializationHolder и унаследованные от него типы не разрешено Десериализовать при этом уровне безопастности

Через Конфигуратор поысил до FullTrust локальную сеть и на серваке и на клиенте(на всякий случай)...

Полагаю что делегат, который находится на удаленном объекте, должен иметь какой-нить аттрибут, или иметь уровень доступа, или еще что-нибудь... дело в нем, потому как если не вешаться на событие, то все в порядке... кто знает че он хочет от меня? как ему этот уровень, или че там, дать...
2-е сутки не сплю, бошка уже бум-бум... в инете копаюсь, ищю, но видимо мне пора выспаться...

Кажется что-то нашел...

Цитата

.NET Remoting — Changes for .NET 1.1 / Visual Studio 2003 Handling of app.config Visual Studio .NET 2003 changed the handling of application configuration files. In previous versions, it was ok to have a configuration file named <application>.exe.config directly in the debug\bin output directory. Since Visual Studio 2003, this file will be deleted when you build and/or run the application. To correct this behavior, you have to add the configuration file to your project BEFORE compilation. You can do this by simply dragging and dropping the file from Explorer. After adding the configuration file to the project, you have to rename it "app.config". Handling of delegates and events [Note: You can download an updated version of Chapter 6's EventsEnhanced sample here.] If you use client activated objects, events or delegates you will receive one of the following exceptions when running on the .NET Framework 1.1: • System.Security.SecurityException. Type System.DelegateSerializationHolder and the types derived from it (such as System.DelegateSerializationHolder) are not permitted to be deserialized at this security level. • System.Runtime.Serialization.SerializationException Because of security restrictions, the type System.Runtime.Remoting.ObjRef cannot be accessed. To revert to the old behavior (i.e. to allow passing of delegates and object references over Remoting boundaries), you have to change the so called "typeFilterLevel". You can do this either by using a configuration file like this (for server side): <configuration> <system.runtime.remoting> <application> <channels> <channel ref="http" port="1234"> <serverProviders> <provider ref="wsdl" /> <formatter ref="soap" typeFilterLevel="Full" /> <formatter ref="binary" typeFilterLevel="Full" /> </serverProviders> <clientProviders> <formatter ref="binary" /> </clientProviders> </channel> </channels> <service> <!-- ... Add your services here ... --> </service> </application> </system.runtime.remoting> </configuration> In this case, a matching client-side configuration file which allows the reception of events and callbacks, would look like this: <configuration> <system.runtime.remoting> <application> <channels> <channel ref="http" port="0"> <clientProviders> <formatter ref="binary" /> </clientProviders> <serverProviders> <formatter ref="binary" typeFilterLevel="Full" /> </serverProviders> </channel> </channels> <client> <!-- ... Add your classes here ... --> </client> </application> </system.runtime.remoting> </configuration> If you prefer to setup your channels in source code, you have to use the extended constructor of the HttpChannel or TcpChannel to pass a custom IFormatterSinkProvider object: BinaryServerFormatterSinkProvider serverProv = new BinaryServerFormatterSinkProvider(); provider.TypeFilterLevel = System.Runtime.Serialization.Formatters.TypeFilterLevel.Full; BinaryClientFormatterSinkProvider clientProv = new BinaryClientFormatterSinkProvider(); IDictionary props = new Hashtable(); props["port"] = 1234; HttpChannel chan = new HttpChannel(props, clientProv, provider); ChannelServices.RegisterChannel( chan ); You can find more details about these changes and the possible type filter levels at http://www.gotdotnet.com/team/changeinfo/B...t.aspx#00000153. Handling of Client-Activated Object with SoapSuds Metadata When you use SoapSuds.exe to generate the metadata for your client-activated objects, and you run your application on version 1.1 of the .NET Framework, an exception similar to the following will be thrown: An unhandled exception of type 'System.Runtime.Remoting.RemotingException' occurred in mscorlib.dll Additional information: Permission denied for activating type soap:SomeObject, http://schemas.microsoft.com/clr/nsassem/S...3D1.0.701.21741 %2C%20Culture%3Dneutral%2C%20PublicKeyToken%3Dnull. This is a bug in the current version of the .NET Framework. Microsoft has released a hotfix which you can obtain from Microsoft Product Support Services. Please read knowledge base article 823445 for more details. If you don't want to contact Microsoft Product Support Services, then you can alternatively change your source code to use a class factory approach as shown in this article

Данный вопрос временно Thread.Sleep(1000000000)... Пока не тратье на него время... Пойду обрабатывать эту цитату своим серым нагретым процессором...................

if (This_Quote == True)
Я.WriteLine GoodResult
else
Я.WriteLine BadResult
endif;
me.end; // в любом случае...

РЕШЕНО!!! СПАСИБО ОГРОМНОЕ ВСЕМ КТО ОТКЛИКНУЛСЯ, ПОДДЕРЖАЛ И ПОМОГ!!!

Проблема решилась когда я сделал так как в предыдущем топике...
Блин, молодцы мелкософты... полезную вещь добавили в v1.1

Более подробней об этой проблеме описано здесь

-Mikle-, 
У меня была та же проблема: Type System.DelegateSerializationHolder and the types derived from it (such as System.DelegateSerializationHolder) are not permitted to be deserialized at this security level.
Когда я сделал как описано в предыдущей ссылке, при навешивании события появилось другое исключение: Exception has been thrown by the target of an invokation. Уже блин не знаю чё делать, везде только написано про typeFilterLevel="Full", которое у меня естественно установлено.
 

Данное исключение пояляется если класс, который обрабатывает событие наследуется от MarshalByRefObject. Если пометить класс как [Serializable] то появляется другое исключение:Unable to find assembly ............ Что делать? Ниужели никто не знает как обрабатывать события в .NET 2.0?