Индикаторы - совместный проект

У меня был аналогичный случай.
Я сделал CheckOut только одного Indicators.sln.
И у меня не хватало двух библиотек Ecng в референсах.
Они были, но были помечены предупреждением.

Если посмотреть код файла Indicators.csproj, то там есть такие строки


Что говорит, что два файла лежат где-то выше.

Я просто добавил вручную эти два файла в референс.
Но после этого откатил изменение в файле Indicators.csproj назад, что бы не влиять на основной код.

Сделал реализацию внутри сугубо для ускорения работы.
Так же CMO умножается на 100 в реализации, тогда как в Vidya этого не нужно.
Если кто желает переделать, то я не против.


UPD
Неверно написал последнее предложение.
Так как я делаю этот индикатор, то я за него в ответе.
Если Михаил скажет, что надо переделать с использованием CMO класса, то я переделаю.
Если не скажет, то пределывать ничего не буду.

Предлагаю всем вместе решить как будем поступать в таких случаях, каждый раз изобретать велосипед или использовать готовое[smile]

Maxim, goricap это ваш логин? Сейчас вытянул последнюю версию проекта, там добавлен индикатор Volatility, у метода Add стоит override, хотя в базовом классе такого метода вообще нет, и проект не компилируется, вы перед Check In проект компилируете?

P.s. CCI вроде никто еще не брал?

Мое личное мнение:
Изобретать велосипед по возможности не стоит.
У проекта должен быть куратор, который должен решать политику партии.
Всем вместе решать не стоит. Демократия говно :).
Надо всем вместе обсуждать, а решение должен принимать один человек.


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

Думаю, что окончательное решение будет принимать Михаил, как основатель проекта, либо выберем другого ответственного.

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

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

3. По поведению индикаторов:
- если индикатор еще не сформировался, то его значение равно 0
- пока индикатор не сформировался, событие Changed не вызывается
- после того как индикатор сформировался, событие Changed вызывается при каждом добавлении нового значения
- функция Add принимает или decimal или Candle

4. При коммите указывать какие изменения были внесены, коммиты делать только для работающих версий (по минимуму проект должен собираться)

5. Xml комментарии писать на одном языке

Пока все, если что-то вспомню, добавлю[smile]

Я даже когда с сайта скачиваю последнюю сборку, ссылки в референсе проекта присутствуют, но с восклицательныйм знаком, сами сборки не находятся. Я на 100% не уверен, сейчас нет возможности посмотреть, но вроде из Source Control Explorer и закачиваю последнюю версию.


То есть вы поправили код Indicators.csproj вручную или через add new reference? Вам каждый раз приходится это делать?

Идем в Team Explorer - Source Control, там есть Indicators, а еще есть References, вот их тоже скачиваем и все должно работать, можно скачать не полностью References, а только нужные зависимости.

Вообще суть в том, чтобы нужные зависимости лежали по адресу Indicators\..\References, т.е. рядом с директорией проекта Indicators, должна быть директория References с нужными зависимостями

Вручную не правил.
Добавил библиотеки в референс.
И после этого откатил изменения в файле Indicators.csproj назад.
Сделал это один раз. Каждый раз не нужно делать.

По какой причине после того, как сделал откат Студия видит библиотеки не знаю.
По идее не должна. Но работает. Возможно я просто чего то не знаю.

Возможно стоит сделать по совету esper и скачать References.

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

Всем спасибо за огромный вклад в проект!

Схема такая. Это репозитарий коннекторов. Они все и используют S# сборки. Так же как и проект с индикаторами. Соответственно структура проекта (файловая) должна быть как она есть в TFS. Даже если у кого-то S# был до этого скачал и распакован в какую-то директорию другую, ссылки у проекта с индикаторами не должны вести туда. Используется только локальная копия сборок.

Я думаю надо отпустить файлы. А то сейчас вы все файлы пометили как редактируемые. Еще заметил, что checkin идет с пометкой не просто edit, но и branch. Схема работы следующая:

1. Запустили студию. Открытие Source Control Explorer. Сделали на проект Connectors Get Latest Version.
2. Редактируем файл в студии. Все изменения автоматически подхватываются TFS (в отличие от SVN).
3. Хотим залить изменения. Делаем еще раз Get Latest Version. Если кто-то уже залил свои изменения, и у нас произошел конфликт, то эти конфликты правим из окна Pending Changes.
4. Идем опять в Source Control Explorer, делаем Check In. Появляется окно, где пишет обязательно комментарий и проверяем свои изменения. Иногда бывает так, что студия (или мы сами) поменяли лишнее количество файлов. Лишнее откатываем (в случае сомнений делаем diff чтобы проверить отличия). По идее, в check in должны попасть только cs и csproj файлы. Все лишнее - это уже повод для сомнений.