Ниже расскажу о реализации проброса WCF запросов от одного сервера через несколько промежуточных, так называемый wcf tunneling, вопрос о реализации которого уже поднимался на gotdotnet.ru. Там автор предлагал использовать Castle.DynamicProxy для динамической генерации прокси-классов для создания канала. Однако комментаторы отметили, что полученный функционал дублирует лишь стандартные возможности при прямом взаимодействии точка-точка.
Актуальность приобретается, когда добавляется набор промежуточных точек. При этом на клиенте идет перехват вызова произвольной удаленной функции FuncName на вызов абстрактной функции object _DataTransfer(HeaderAuthen auth, object ServiceLink, object FuncName, object[] param); Далее обращение транслируется через серию промежуточных машин и в итоге обращение передается на ServiceLink, где обрабатывается. Также возвращается результат. Грубо говоря примитивный функционал Biztalk своими руками по передачи soap сообщений в многосвязной сети. Кроме того мы без ведома пользователя накладываем на канал защиту через HeaderAuthen auth.
Отдельно выкладываю реализацию класс DynamicServiceProxy и ServiceChannelManagerInterceptor, подменяющие вызов, а также сам вызов в ServiceChannelManager. Соответственно все закладывается в библиотеку, которая должна быть на всех точках, а на туннельных-промежуточных точках еще и реализуется Контранкт, в котором важно описать передаточную функцию _DataTransfer, все функции на конечных точках, а также все классы и типы через KnownTypeContainer. Также важно включить сериализатор XmlSerializerFormat, так как по умолчанию в WCF используется DataContractSerializer, которых не позволяет передавать object. То есть вызовы проходить будут, а данные - нет. Кроме того у XmlSerializerFormat тоже есть особенность, кто нельзя передать некоторые стандартные типы, например, DataSet как параметр, так как в них используется нетипизированный ArrayList. Вот пожалуй и все, что нужно знать.

...негры нашего времени. За прошлый 2010 год имел неприятность переработать с различными типами программистов .Net, так как сам программирую на Chsarp. Ниже своеобразный обзор о печальной картине подрастающего поколения, выводы и может в следующем посте приведу перевод одной интересной книги о том, как искать хороших программистов.
Итак, задачу я ставил достаточно сложно и общно, описывая что должно работать глазами пользователя и разрешая задавать мне вопросы по хожу и ограничивая в зарплате рамками разумного. Что получилось или входные данные:

• Первый тип. Женат. Москва. В соц-сетях время не тратит. Ведущий разработчик мелкого коммерческого предприятия. Имел хорошие практические навыки и требовательно относился к коду по части реализации, для работы с данными переваривал только Linq. Не справился, нехватка времени.
• Второй. Женат. Москва. Сидит вконтакте. Ведущий разработчик в около-государственной структуре. Имел плохие практические навыки, по образованию - программист. Не справился, по качеству реализации.
• Третий. Холост. Приехал в Москву на учебу-заработки. Сидит в Твиттере, пишет статьи на хабр. Имел средние практические навыки, по образованию - программист. Не справился, нехватка времени.
• Четвертый. Женат. Москва. Сидит в Живом Журнале. Имел обширные практические навыки, по образованию - программист. Реализовывал все по теории - от абстрактной модели. Не справился, по качеству реализации.
• Пятый. Холост. Не Москва. Не сидит в соц.сетях. Имел плохие практические навыки. В целом справляется, делает не совсем то, как надо, но на замечания, что это нужно переделать потому-то, реагирует нормально, потому что если не справится, то ему в Замкадье будет нечего кушать.

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

• Холост. Говорит о том, что у него есть время работать.
• Не сидит в соц.сетях и не пишет статьи о том как надо программировать. Ибо одно дело учить, а другое дело реализовывать.
• По образованию технарь, но не специализировался на программировании в вузе. Ему должно быть наплевать на теоретическую базу, а волновать только то, что написано в документации и как это сделать побыстрее, да чтобы работало.
• Не живет в Москве.
• Уже делал несколько других проектов в том числе и для себя. То есть само-обучаем!

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

Всегда не любил выдачу JSON за то, что она подразумевает обработку в JS на стороне клиента, а значит много гемора для программиста. Но оказывается существует уже и полноценное решение делающее JSON не сложнее обычной XML сериализации. Речь про newtonjson.dll, написанную на .Net и неплохо документированную. Отдельно порадовала возможность конвертации конечного листа дерева в произвольный тип путем простого вызова типа cursor["leafname"].Value();. Вот бы все значения ячеек для датагридов тоже имели такой шаблонизатор, чтобы не прописывать каждый раз приведение типа.

Пример JSON сериализатора в .Net для результатов выдаваемых гуглом при поисковых запросах через AJAX API - можно найти в последних изменениях blogsapi

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

Что такое RSS большинство должно знать - это форма экспорта текстовых данных с сайта. Лично меня в RSS не устраивает то, что нельзя задать идентификатор сообщения уникальный для моего поста в рамках сегодняшнего дня, а не в рамках ресурса, за что отвечает поле guid. Это нужно для того, чтобы RSS агрегатор, типа reader.google.com, мог понять, что эти 3 новости перекопированные на разные сайты - есть одно и тоже. Например новости Яндекса копируются на хабр и на яру, а у меня из-за этого в 3 раза больше сообщений. Введение такого хэш-идентификатора "на день" вполне оправдано. И согласуется с тем, как работают сервисы сокращения ссылок, замещая старые короткие ссылки, новыми значениями, что позволяет короткой ссылке оставаться короткой.

Другая интересная несогласованность проявляется при попытке создания RSS выдачи при помощи сериализации объекта класса (рекомендую библиотеку RssToolKit 2.0 для этого). Как мы знаем все строки в CSharp храняться в виде UTF-16, поэтому при сериализации мы получаем XML в этой кодировке, жестко указанной в заголовке. Но, как оказалось, некоторые браузеры - FireFox, IE8 (в Opera все впорядке) - наотрез отказываются воспринимать такой XML, требуя UTF-8 и жесткого задания версии RSS, поэтому пришлось дописать RssToolKit, добавив преобразование кодировок следующим образом:Читать далее...

Как оказалось делать скриншоты сайтов не такая уж и простая задача. Но выход из нее можно найти создавая отдельным потоком скрытую форму с объектом WebBrowser и используя некоторые компоненты MS IE7 .
Ниже идет малокомментированный код, который подскажет Вам, как это правильнее всего сделать. Если есть вопросы, то гуглите и разбирайтесь в документации:

Copy

При индексировании архива офисных файлов мне понадобилось извлекать текстовую информацию из различных файлов таких как DOC или PDF. Решение несложное, достаточно воспользоваться несколькими библиотеками. Для PDF - это PDFBox, портированный с Java на CSharp. Для DOC - это Microsoft.Office.Interop.Word.dll из набора OfficeAPI. Для удобства, необходимые библиотеки можно скачать одним архивов по ссылке

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