Тоже занимался данной проблемой недавно, искал тоже в сторону <assemblyBinding>, но не докопал.
Нашел только решение через AssemblyResolove. А вот хотелось бы как раз просто конфиг. Поэтому спасибо огромное.
В дополнение: у вас среди вариантов processorArchitecture нет варианта ARM, а это уже актуально с WinRT. В доке <assemblyBinding> варианта ARM нет, а вот в самом перечислении ProcessorArchitecture появился Arm. Так что можно опробовать.
То же самое, что делает ваша функция, только строготипизировано. Использовать from… where… select конечно нельзя.
А есть и более сложное, но элегантное решение. Можно подменить QueryProvider и там при конструировании .Where анализировать деревья выражений на наличие замыканий и также переписывать выражения.
в полученное выражение подставляется замыкание на values.
Для решения этой простой задачи вы наворотили какое-то странное решение, где вы начисто убили строгую типизацию, в чем есть смысл LINQ (intergrated!).
Тут много достаточно хороших способов решения.
Например, можно транслировать дерево выражения, заменив замыкание values на составляющие Or.
А еще лучше сделать отдельную Where Where(this IQueryable<T> source, Expression<Func<T,TResult>> selector, IEnumerable<TResult> values). Там бы и конструировался ваш запрос с помощью Or.
Если речь идет о SharpKit, то отлаживать непосредственно C# исполняемый в виде JavaScript'а на браузере нельзя. Можно просто отлаживать JavaScript — там все понятно: что, где и откуда. Конечный код почти полностью соответствует исходному.
Да, есть немного. Только технологический стек другой.
Всегда с усложнением задач, нужен инструментарий для более эффективной работы. В ручную писать JavaScript, без контроля типов, совсем сложно стало. Вот появляются инструменты.
Ответ линчевателям от Sebro (проект 3)
Большое спасибо за разбор проекта. Если в общем, то изложенные проблемы нам понятны, и мы, конечно же, о них задумывались.
SEO-продвижение – не стандартизированная услуга. Во многом это так, но мы все-таки пытаемся формализовать. Но формализуем мы не услугу, а контракт. Описание контракта может быть довольно гибким в системе, что позволит охватить довольно большой спектр потребностей.
Узкая специализация на SEO. Во-первых, у нас, как у команды, есть смежные проекты, и есть пути их пересечения в дальнейшем, просто на данный момент это не нужно. Мы только нащупываем для них уверенный курс. Во-вторых, конечно же, проект не останется в том виде, как он есть сейчас — есть довольно большие планы как по расширению функционала так и охвата смежных услуг. Мы понимаем, что одна из составляющих залога успеха — в непрерывном развитии. К, сожалению счастью есть негативный опыт. В-третьих, мы не считаем, что узкая специализация это всегда плохо — это может быть наш «голубой океан».
Разрешение споров. Позиция по данному вопросу не окончательна и требует большего анализа. Мы себя не позиционируем как всеобъемлющий God-сервис, который должен решать все возникающие проблемы между сторонами. Мы берем на себя функцию контроля и гарантии оплаты по результатам этого контроля. Не больше и не меньше. Контракт в системе — это некоторая базовая позиция, договоренность и гарантии. Но для взаимовыгодного сотрудничества надо, в том числе, и договариваться самим в спорных ситуациях. А по поводу объективных причин недостижения результатов — здесь тоже не все так просто, это вопрос рисков и того кто должен их на себя брать.
Мы сейчас на первой волне запуска получили достаточно большое количество обратной связи как со стороны исполнителей так и со стороны заказчиков. Мы хотим соблюсти баланс в интересах.
Мы многие аспекты серьезно проработали и работаем над соответствующими изменениями в системе. Они появятся уже в ближайшее время.
Пока, в общем-то, мы работаем на малом ходу, оставляя пространство для маневра. Собираем и учитываем проблемы, обратку и пр.
Чуть позже мы подробно ответим на комментарии от FLV. Конечно, не перепалку, а просто наше видение тех возможных проблем, о которых они сказали.
<assemblyBinding>, но не докопал.Нашел только решение через AssemblyResolove. А вот хотелось бы как раз просто конфиг. Поэтому спасибо огромное.
В дополнение: у вас среди вариантов
processorArchitectureнет варианта ARM, а это уже актуально с WinRT. В доке <assemblyBinding> варианта ARM нет, а вот в самом перечислении ProcessorArchitecture появился Arm. Так что можно опробовать.Также отмечу, что все исходники доступны свободно.
В планах:
Использовать очень просто:
Реализовать такую функцию можно без проблем, использую ExpressionVisitor.
Такое выражение развернется в:
То же самое, что делает ваша функция, только строготипизировано. Использовать from… where… select конечно нельзя.
А есть и более сложное, но элегантное решение. Можно подменить QueryProvider и там при конструировании .Where анализировать деревья выражений на наличие замыканий и также переписывать выражения.
в полученное выражение подставляется замыкание на values.
Для решения этой простой задачи вы наворотили какое-то странное решение, где вы начисто убили строгую типизацию, в чем есть смысл LINQ (intergrated!).
Тут много достаточно хороших способов решения.
Например, можно транслировать дерево выражения, заменив замыкание values на составляющие Or.
А еще лучше сделать отдельную Where
Where(this IQueryable<T> source, Expression<Func<T,TResult>> selector, IEnumerable<TResult> values). Там бы и конструировался ваш запрос с помощью Or.За ссылку спасибо, интересно.
Всегда с усложнением задач, нужен инструментарий для более эффективной работы. В ручную писать JavaScript, без контроля типов, совсем сложно стало. Вот появляются инструменты.
Большое спасибо за разбор проекта. Если в общем, то изложенные проблемы нам понятны, и мы, конечно же, о них задумывались.
сожалениюсчастью есть негативный опыт. В-третьих, мы не считаем, что узкая специализация это всегда плохо — это может быть наш «голубой океан».Мы многие аспекты серьезно проработали и работаем над соответствующими изменениями в системе. Они появятся уже в ближайшее время.
Пока, в общем-то, мы работаем на малом ходу, оставляя пространство для маневра. Собираем и учитываем проблемы, обратку и пр.
Чуть позже мы подробно ответим на комментарии от FLV. Конечно, не перепалку, а просто наше видение тех возможных проблем, о которых они сказали.