Результаты поиска

FileNotFoundException для mscorlib.XmlSerializers.DLL, который не существует

Я использую XmlSerializer для десериализации определенного типа в mscorelib.dll

XmlSerializer ser = new XmlSerializer( typeof( [.Net type in System] ) );
return ([.Net type in System]) ser.Deserialize( new StringReader( xmlValue ) );

Это выбрасывает пойманный FileNotFoundException , когда загружается assembly:

"Не удалось загрузить файл или assembly 'mscorlib.XmlSerializers, Версия=2.0.0.0, культура=нейтральная, PublicKeyToken=b77a5c561934e089' или одна из его зависимостей. Система не удается найти указанный файл."

FusionLog:

=== Pre-bind state information ===
LOG: User = ###
LOG: DisplayName = mscorlib.XmlSerializers, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=x86
 (Fully-specified)
LOG: Appbase = file:///C:/localdir
LOG: Initial PrivatePath = NULL
Calling assembly : System.Xml, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\localdir\bin\Debug\appname.vshost.exe.Config
LOG: Using machine configuration file from c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Post-policy reference: mscorlib.XmlSerializers, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=x86
LOG: Attempting download of new URL file:///C:/localdir/bin/Debug/mscorlib.XmlSerializers.DLL.
LOG: Attempting download of new URL file:///C:/localdir/bin/Debug/mscorlib.XmlSerializers/mscorlib.XmlSerializers.DLL.
LOG: Attempting download of new URL file:///C:/localdir/bin/Debug/mscorlib.XmlSerializers.EXE.
LOG: Attempting download of new URL file:///C:/localdir/bin/Debug/mscorlib.XmlSerializers/mscorlib.XmlSerializers.EXE.

Насколько я знаю, нет mscorlib.XmlSerializers.DLL, я думаю, что имя DLL было автоматически сгенерировано .Net, ищущим сериализатор.

У вас есть возможность создать myApplication.XmlSerializers.DLL при компиляции для оптимизации сериализации, поэтому я предполагаю, что это часть проверки фреймворка.

Проблема в том, что это, по - видимому, вызывает задержку в загрузке приложения-кажется, что оно зависает на несколько секунд в этот момент.

Есть идеи, как этого избежать или ускорить?

Можно ли сериализовать объект типа C#?

Я пытаюсь сериализовать объект типа следующим образом:

Type myType = typeof (StringBuilder);
var serializer = new XmlSerializer(typeof(Type));
TextWriter writer = new StringWriter();
serializer.Serialize(writer, myType);

Когда я делаю это, вызов сериализации вызывает следующее исключение:

"Тип System.Text.StringBuilder не ожидался. Используйте XmlInclude или SoapInclude атрибут для указания типов, которые не являются известно статически."

Есть ли способ для меня сериализовать объект Type ? Обратите внимание, что я не пытаюсь сериализовать сам StringBuilder , а объект Type , содержащий метаданные о классе StringBuilder .

Большие, сложные объекты как результат работы веб-службы

Еще раз здравствуйте, дамы и господа!

OK, вслед за моим другим вопросом о результатах веб-службы ASP.NET, Прокси-классах и преобразовании типов . Я пришел к той части своего проекта, где мне нужно надеть свою мыслительную шапочку.

В принципе, у нас есть большой, сложный пользовательский объект, который должен быть возвращен из веб-службы и использован в клиентском приложении.

Теперь, основываясь на предыдущем обсуждении, мы знаем, что это будет затем принимать форму прокси-класса(классов) в качестве возвращаемого типа. Чтобы преодолеть это, нам нужно в основном скопировать свойства от одного к другому.

В данном случае, это то, что я бы очень, очень, очень хотел! хотелось бы избежать!

Так что, это заставило меня задуматься, как еще мы могли бы это сделать?

Мои текущие мысли заключаются в том, чтобы включить объект для полной сериализации в XML, а затем вернуть XML в виде строки из веб-службы. Затем мы десериализации на клиенте. Это будет означать изрядную часть украшения атрибутов, но, по крайней мере, код на обеих конечных точках будет легким, а именно, просто используя сериализатор .NET XML.

Что вы думаете по этому поводу?

Принудительное оформление атрибутов классов / методов

Следуя моему недавнему вопросу о больших, сложных объектах Как результате веб-службы . Я думал о том, как я могу гарантировать, что все будущие дочерние классы сериализуются в XML.

Теперь, очевидно, я мог бы реализовать интерфейс IXmlSerializable , а затем бросить в него читателя / писателя, но я хотел бы избежать этого, поскольку это означает, что мне нужно создавать экземпляр читателя/писателя всякий раз, когда я хочу это сделать, и 99.99% времени я буду работать со строкой, поэтому я могу просто написать свой собственный.

Однако, чтобы сериализовать до XML, я просто украшаю класс и его членов Xml? ?? атрибуты ( XmlRoot , XmlElement и др.) и затем передать его в XmlSerializer и StringWriter , чтобы получить строку. И это все хорошо. Я намерен поместить метод для возврата строки в общий метод утилиты, поэтому мне не нужно беспокоиться о типе и т. д.

То, что меня беспокоит, заключается в следующем: если я не украшаю класс(ы) необходимыми атрибутами, ошибка не возникает до времени выполнения.

Есть ли способ применить украшение атрибута? Можно ли это сделать с помощью FxCop? (Я еще не использовал FxCop)

UPDATE:

Извините за задержку в получении этого закрыть ребята, много дел!

Определенно нравится идея использовать отражение, чтобы сделать это в тестовом случае, а не прибегать к FxCop (например, чтобы держать все вместе).. Ответ Фредрика Калсета был фантастическим, спасибо за включение кода, поскольку мне, вероятно, потребовалось бы немного копать, чтобы понять, как это сделать самому!

+1 к другим ребятам за аналогичные предложения :)

XML Serialization и унаследованные типы

Следуя из моего предыдущего вопроса , я работал над тем, чтобы моя объектная модель сериализовалась до XML. Но теперь я столкнулся с проблемой (quelle surprise!).

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

Я подумал, что было бы неплохо просто добавить атрибуты XML ко всем задействованным классам, и все будет замечательно. К сожалению, это не так!

Поэтому я немного покопался в Google и теперь понимаю, почему он не работает. В том, что XmlSerializer на самом деле делает некоторые умные размышления, чтобы сериализовать объекты в/из XML, и поскольку он основан на абстрактном типе, он не может понять, с чем, черт возьми, он говорит . Хорошо.

Я действительно наткнулся на эту страницу на CodeProject, которая выглядит так, как будто она может очень помочь (но все же читать/потреблять полностью), но я подумал, что хотел бы также перенести эту проблему в таблицу StackOverflow, чтобы посмотреть, есть ли у вас какие-либо аккуратные хаки/трюки, чтобы получить это и работать самым быстрым/легким способом.

Одно я должен также добавить, что я не хочу идти по маршруту XmlInclude . Там просто слишком много сцепления с ним, и эта область системы находится в тяжелом развитии, так что это будет настоящая головная боль обслуживания!

Как вы преобразуете двоичные данные в строки и обратно в Java?

У меня есть двоичные данные в файле, которые я могу считывать в массив байтов и обрабатывать без проблем. Теперь мне нужно отправить части данных по сетевому соединению в виде элементов в документе XML. Моя проблема заключается в том, что когда я преобразую данные из массива байтов в строку и обратно в массив байтов, данные повреждаются. Я проверил это на одной машине, чтобы изолировать проблему с преобразованием строки, поэтому теперь я знаю, что она не повреждается парсером XML или сетевым транспортом.

Вот что у меня сейчас есть

byte[] buffer = ...; // read from file
// a few lines that prove I can process the data successfully
String element = new String(buffer);
byte[] newBuffer = element.getBytes();
// a few lines that try to process newBuffer and fail because it is not the same data anymore

Кто-нибудь знает, как конвертировать двоичный код в строку и обратно без потери данных?

Ответил: Спасибо, Сэм. Я чувствую себя полным идиотом. Я получил этот ответ вчера, потому что мой парсер SAX жаловался. По какой-то причине, когда я столкнулся с этой, казалось бы, отдельной проблемой, мне не пришло в голову, что это был новый симптом той же самой проблемы.

EDIT: просто для полноты картины я использовал класс Base64 из пакета кодека Apache Commons Для решения этой проблемы.

Как мне маршалировать a lambda (Proc) в Ruby?

Джо Ван Дайк спросил список рассылки Ruby :

Привет,

В Ruby, я полагаю, вы не можете маршалировать объект lambda/proc, верно? Является это возможно в lisp или других языках?

То, что я пытался сделать:

l = lamda { ... }
Bj.submit "/path/to/ruby/program", :stdin => Marshal.dump(l)

Итак, я посылаю BackgroundJob a lambda объект, который содержит контекст/код для того, что нужно сделать. Но, наверное, это было невозможно. Я в итоге был выполнен маршалинг обычного объекта ruby, содержащего инструкции для того, что делать после запуска программы.

Джо

WCF-объекты домена и IExtensibleDataObject

Типичный сценарий. Мы используем старой школы XML internally web-сервисов для обмена данными между серверами фермы и нескольких распределенных и локальных клиентов. Никакие третьи лица не участвуют, только наши приложения, используемые нами и нашими клиентами.

В настоящее время мы размышляем о переходе от модели XML WS к модели WCF/object-based и экспериментируем с различными подходами. Один из них включает в себя передачу объектов домена / агрегатов непосредственно по проводу, возможно, вызывая атрибуты DataContract на них.

Используя IExtensibleDataObject и DataContract с помощью свойства Order на DataMembers, мы должны быть в состоянии справиться с простыми проблемами управления версиями свойств (помните, что мы контролируем всех клиентов и можем легко принудительно обновить их).

Я постоянно слышу, что мы должны использовать выделенные объекты передачи данных только для передачи данных ( DTOs ) по проводу.

Почему? Есть ли еще причина для этого? Мы используем одну и ту же модель домена на стороне сервера и на стороне клиента, конечно, предварительно заполняя коллекции и т. д. только в том случае, когда это считается правильным, и свойства коллекции "necessary." используют принцип Service locator и IoC для вызова либо NHibernate-based "service" для прямой выборки данных (на стороне сервера), либо клиента WCF "service" на стороне клиента для связи с фермой серверов WCF .

Итак-почему мы должны использовать DTOs ?

Десериализация на другом языке

Сетевой адаптер log4j отправляет события в виде сериализованного объекта java. Я хотел бы иметь возможность захватить этот объект и десериализовать его на другом языке (python). Разве это возможно?

Обратите внимание, что захват сети прост; это просто сокет TCP и чтение в потоке. Трудность заключается в десериализующей части