Есть проект в котором есть мсбуилд таск который создаёт файлы во время компиляции. Хотелось бы, что-бы решарпер их видел.

Здравствуйте, ifle, Вы писали:

I>Есть проект в котором есть мсбуилд таск который создаёт файлы во время компиляции. Хотелось бы, что-бы решарпер их видел.
Пока единственнная возможность — это включить генерируемые файлы в проект, так как ReSharper все еще полагается на то, что дает Visual Studio.
Единственная конструкция, которая добавляет файлы кучкой, и поддерживается на данный момент, это — Compile с маской:

<Compile Include="..\Gen\Psi\CSharp\**\*.cs">

У меня есть бранч, в котором мы научились добывать сгенерированные файлы из msbuild'а, но для production'а он еще не готов. В 9.0 будет.

Здравствуйте, qxWork, Вы писали:

W>Здравствуйте, ifle, Вы писали:

I>>Есть проект в котором есть мсбуилд таск который создаёт файлы во время компиляции. Хотелось бы, что-бы решарпер их видел.
W>Пока единственнная возможность — это включить генерируемые файлы в проект, так как ReSharper все еще полагается на то, что дает Visual Studio.
W>Единственная конструкция, которая добавляет файлы кучкой, и поддерживается на данный момент, это — Compile с маской:

<Compile Include="..\Gen\Psi\CSharp\**\*.cs">

Не, не вариант, поскольку VS при изменении файла проекта пытается добавить файлы из маски.


W>У меня есть бранч, в котором мы научились добывать сгенерированные файлы из msbuild'а, но для production'а он еще не готов. В 9.0 будет.

Ну это долго.

Пытался другой вариант. В solution есть несколько проектов А, Б, которые используют генерируемые типы из проекта С. Проект С также включён в solution. Проекты А, Б имеют референс на проект С. Пробовал в А, Б поменять референсы на генерируемую сборку С, но решарпер почему-то игнорирует это и всё равно не видит генерируемые типы.

Здравствуйте, Аноним, Вы писали:

А>Пытался другой вариант. В solution есть несколько проектов А, Б, которые используют генерируемые типы из проекта С. Проект С также включён в solution. Проекты А, Б имеют референс на проект С. Пробовал в А, Б поменять референсы на генерируемую сборку С, но решарпер почему-то игнорирует это и всё равно не видит генерируемые типы.
Потому, что сборка C — это Output-сборка проекта C, с исходным кодом которого ReSharper умеет работать. Если бы проект С был, скажем, на F#, этот номер бы сработал.
Можно проект С выгрузить, тогда решарпер переключится на сборку.
Также можно извратиться и в Post-build event переименовать сборку C.dll, зареференсить переименованную сборку и прописать binding redirect'ы.

Здравствуйте, qxWork, Вы писали:

W>Здравствуйте, Аноним, Вы писали:

А>>Пытался другой вариант. В solution есть несколько проектов А, Б, которые используют генерируемые типы из проекта С. Проект С также включён в solution. Проекты А, Б имеют референс на проект С. Пробовал в А, Б поменять референсы на генерируемую сборку С, но решарпер почему-то игнорирует это и всё равно не видит генерируемые типы.
W>Потому, что сборка C — это Output-сборка проекта C, с исходным кодом которого ReSharper умеет работать. Если бы проект С был, скажем, на F#, этот номер бы сработал.
W>Можно проект С выгрузить, тогда решарпер переключится на сборку.
W>Также можно извратиться и в Post-build event переименовать сборку C.dll, зареференсить переименованную сборку и прописать binding redirect'ы.

А почему решарпер пытается работать с исходным кодом если в референсах прописан не проект, а конкретная сборка?
С переименованием не пройдёт, поскольку сборка С также регистрируется как COM. Вообщем полная ....
В первый раз столкнулся когда решарпер не помогает, а мешает

Здравствуйте, Аноним, Вы писали:

А>А почему решарпер пытается работать с исходным кодом если в референсах прописан не проект, а конкретная сборка?
Проявляет интеллект. Как иначе код рефакторить, который затрагивает этот проект?

Здравствуйте, qxWork, Вы писали:

W>Здравствуйте, Аноним, Вы писали:

А>>А почему решарпер пытается работать с исходным кодом если в референсах прописан не проект, а конкретная сборка?
W>Проявляет интеллект. Как иначе код рефакторить, который затрагивает этот проект?

Ну да, горе от ума . Не совсем понятно где проблема с рефакторингом? В проекте А и Б или С? И в чём проблема

Здравствуйте, Аноним, Вы писали:

А>Ну да, горе от ума . Не совсем понятно где проблема с рефакторингом? В проекте А и Б или С? И в чём проблема
ReSharper может изменять только исходники. Поэтому если проект С рассматривать просто как .dll, тогда мы не можем менять ничего, что в нем определено.
Если же с ним работать как с исходниками, то мы можем изменять все, кроме сгенерированных файлов, так как ReSharper их не видит. Как только ReSharper научится видеть сгенерированные файлы, появится новая проблема: любые изменения, сделанные в сгенерированных файлых, будут потеряны после билда. Для того, что бы такие файлы менять корректно, нужно менять файлы, из которых они генерируются, а эту задачу в общем случае не решить.

Здравствуйте, qxWork, Вы писали:

W>Здравствуйте, Аноним, Вы писали:

А>>Ну да, горе от ума . Не совсем понятно где проблема с рефакторингом? В проекте А и Б или С? И в чём проблема
W>ReSharper может изменять только исходники. Поэтому если проект С рассматривать просто как .dll, тогда мы не можем менять ничего, что в нем определено.

Менять исходники проекта С можно поскольку он находится в solution.
А вот резолвить референсы у проектов А и Б на проект С, надо как указано в их проектах — по конкретной сборке, а не по исходникам как решарпер делает.
Здесь мы на вещи не много по другому смотрим, ты видишь, то что под капотом, а я снаружи. Даже не знаю как лучше разрулить ситуацию.

W>Если же с ним работать как с исходниками, то мы можем изменять все, кроме сгенерированных файлов, так как ReSharper их не видит. Как только ReSharper научится видеть сгенерированные файлы, появится новая проблема: любые изменения, сделанные в сгенерированных файлых, будут потеряны после билда. Для того, что бы такие файлы менять корректно, нужно менять файлы, из которых они генерируются, а эту задачу в общем случае не решить.

Скажем так, менять генерируемые файлы — это экзотика. Другое дело, что генерируемый файл может быть партиал класс, это да.

Здравствуйте, ifle, Вы писали:

I>Скажем так, менять генерируемые файлы — это экзотика. Другое дело, что генерируемый файл может быть партиал класс, это да.
Простой пример: ты сгенерировал тип по имени Foo и использовал его везде, теперь ты понял, что слово 'Foo' правильно писать 'Foe' и хочешь вызвать rename refactoring. В идеальном мире должны поменять использования во всех проектах (зачастую и в С тоже), и то, откуда этот тип генерируется.

Здравствуйте, qxWork, Вы писали:

W>Здравствуйте, ifle, Вы писали:

I>>Скажем так, менять генерируемые файлы — это экзотика. Другое дело, что генерируемый файл может быть партиал класс, это да.
W>Простой пример: ты сгенерировал тип по имени Foo и использовал его везде, теперь ты понял, что слово 'Foo' правильно писать 'Foe' и хочешь вызвать rename refactoring. В идеальном мире должны поменять использования во всех проектах (зачастую и в С тоже), и то, откуда этот тип генерируется.

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