Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>нужно рассматривать максимально широкий спектр задач потенциальных пользователей.
Цитату плиз. Проглядел топик — везде не про "максимально широкий", а про основные сценарии использования aka usage scenarios.
AS>А теперь говорите — нужна одна конкретная проблема и вообще поменьше усилий, чтобы обойтись одним изменением в отдельном случае.
Ну так вы определитесь наконец — вы абстрактный фреймворк ваяете, или пытаетесь поверх существующей инфраструктуры и существующих форматов файлов конкретную проблему решить?
И давайте конкретику уже, а то у нас какой-то холивар вместо собственно обсуждения получается
S>> я бы решил дело простым парсером sln + csproj-файлов. AS>Это всё равно что сказать, что компилятор только из парсера состоит, а кодогенерация это фигня.
огосспидя. Жаргонизм это обычный. Название пошло от типового вида API Xxx.ParseYyy(). XDocument.Parse() не смущает же?
S> вы определитесь наконец — вы абстрактный фреймворк ваяете, или конкретную проблему решить?
Так я сразу определился. Мне нужен фреймворк. Интересуюсь, как делают фреймворки вообще, абстрактно. Выяснил, что методики нет.
S> пытаетесь поверх существующей инфраструктуры и существующих форматов файлов
Существующие форматы файлов — это часть требований. Нельзя просто взять их и выкинуть.
Поэтому даже совершенно новый фреймворк всё равно будет дело с этими же форматами иметь.
S> И давайте конкретику уже, а то у нас какой-то холивар вместо собственно обсуждения получается
Да уж куда конкретнее-то? Вся конкретика есть уже в первом посте.
Интересуюсь я не просто так, не на голом месте интерес. И я конкретно расписал, какой мне нужен фреймворк и для чего.
Моя проблема конкретная в том смысле, что В КАЧЕСТВЕ ПРИМЕРА я привел конкретный фреймворк существующий, а мне нужен тоже КОНКРЕТНЫЙ, но с необходимыми мне возможностями.
Существующую инфраструктуру хотелось бы проанализировать на возможность допилки. Потому что в этом случае есть надежда снизить вероятность ошибок проектирования.
Про .csproj вы выше всё сами расписали.
С ошибками правда, указав что бывают Project Reference (в .csproj), Assembly Reference (в .csproj)
и ссылки (dependencies) между проектами в .sln, только вы смешали второе и третье понятие.
Другой коллега не в курсе, что если преобразовывать XML при помощи XSLT, то форматирование слетает.
И вообще XML — это третий уровень, а изменять хочется средствами пятого.
AS>>нужно рассматривать максимально широкий спектр задач потенциальных пользователей. S>Цитату плиз.
2.1 PROGRESSIVE FRAMEWORKS
Designing a single framework for a broad range of developers, scenarios, and languages is a difficult and costly enterprise.
Они не говорят, что нужно делать именно так.
Но указывают, что если фреймворк прогрессивный, то сценариев он покрывает как правило много.
А если он покрывает мало сценариев, то какой же это прогрессивный фреймворк?
Там ещё ниже есть сравнение
multiframework approach
и
progressive framework.
Так вот то, что есть сейчас для обработки .csproj — это гораздо скорее первое, чем второе.
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>Интересуюсь я не просто так, не на голом месте интерес. И я конкретно расписал, какой мне нужен фреймворк и для чего.
Гааах. Я правильно понял, что оно нужно для того, чтоб заменить существующую инфраструктуру sln/csproj/msbuild?
А то вопрос пока выглядит примерно так: "я хочу написать фреймворк. Для начала, в нём должна быть своя субд..." и на дальнейшие вопросы — "всё, что мне нужно, я уже расписал", без обид.
Я уже не знаю, как ещё раз намекнуть на очевидный факт, но сделать простенькое API, чтобы удобно было править ссылки в проектах и целиком реализовать поддержку редактирования csproj или разруливание зависимостей внутри солюшна — это таки две большие разницы. И не зная исходной проблемы, которую вы собрались решать этим фреймворком, вам точно ничего хорошего никто не посоветует.
AS>Моя проблема конкретная в том смысле, что В КАЧЕСТВЕ ПРИМЕРА я привел конкретный фреймворк существующий, а мне нужен тоже КОНКРЕТНЫЙ, но с необходимыми мне возможностями. AS>Существующую инфраструктуру хотелось бы проанализировать на возможность допилки. Потому что в этом случае есть надежда снизить вероятность ошибок проектирования.
Ну блин, снова то же самое. "Я хочу сделать автомобиль. У него должна быть дверь и он должен ездить. Хотя допилить готовый меня тоже устроит".
Где, бляха-муха конкретный сценарий? AKA
* У меня есть x
* Я хочу получить y, затратив z1 и с дополнительными условиями z2
* для этого мой фреймворк должен уметь a, b и c.
Вы расписываете только последнюю часть, да и то отдельные частные случаи, из которых первые два пункта не восстановишь.
AS>Про .csproj вы выше всё сами расписали. AS>С ошибками правда, указав что бывают Project Reference (в .csproj), Assembly Reference (в .csproj) AS>и ссылки (dependencies) между проектами в .sln, только вы смешали второе и третье понятие.
Блин, давайте всё-таки читать то, что вам пишут
И ещё надо учитывать, что помимо csproj нужны sln , т.к. в них прописывается порядок сборки (отдельные гении добавляют ссылки на сборки не как project reference, а как ссылку на собранную библиотеку в общей папке bin).
AS>>С ошибками правда, указав что бывают Project Reference (в .csproj), Assembly Reference (в .csproj) AS>>и ссылки (dependencies) между проектами в .sln, только вы смешали второе и третье понятие.
S>Дано: проект A с S>[code] S><Reference Include="somelib.dll"> S> <HintPath>..\proj\bin\somelib.dll</HintPath> S></Reference> S>[code]
S>Как вы правильно определите зависимости (и порядок сборки) без .sln-файла?
Наличие зависимости запросто определю — увижу в .csproj элемент Reference вместо ProjectReference.
Собрать правильно без .sln файла не смогу, но меня это не волнует, потому что задача парсинга .sln проще, чем задача парсинга .csproj,
в ней всего три уровня — нет XML и нет MSBUILD-элементов.
И конкретно у меня задача парсинга .sln уже решена, мне хватает
(это та самая библиотека CWDev.SLNTools которая занимается тем, что мержит солюшены)
То есть для зависимость записана в .csproj для определения наличия зависимости .sln не нужен.
Конечно, хорошо бы и код работы с .sln переписать, чтобы сохранялось форматирование. Но я спрашивал про проектирование абстрактно,
если мне дадут методику для .csproj,
то для .sln, .nuspec, .package и .config я её уже сам применю по-аналогии.
S> Я правильно понял, что оно нужно для того, чтоб заменить существующую инфраструктуру sln/csproj/msbuild?
нет, неправильно. Я согласен и на интеграцию. Просто существующая реализация этой инфраструктуры не решает мои задачи.
А мне надо, чтобы они решались.
S>* У меня есть x S>* Я хочу получить y, затратив z1 и с дополнительными условиями z2 S>* для этого мой фреймворк должен уметь a, b и c. S> Вы расписываете только последнюю часть, да и то отдельные частные случаи, из которых первые два пункта не восстановишь.
Я это делаю СПЕЦИАЛЬНО для того, чтобы акцентировать внимание именно на задаче разработки фреймворка.
Если я опишу общую задачу, разговор уйдет в нейронные сети или ещё куда не туда свернёт.
Скажете, "нет, это слишком сложно" и на этом обсуждение закончится.
С другой стороны, написать технико-экономическое обоснование того,
что мой фреймворк подарит миру больше счастья меньшими суммарными усилиями жителей планеты
чем сушествующий multiple framework от microsoft
мне пока трудновато.
Здравствуйте, Arsen.Shnurkov, Вы писали:
S>>Цитату плиз. AS>2.1 PROGRESSIVE FRAMEWORKS AS>Designing a single framework for a broad range of developers, scenarios, and languages is a difficult and costly enterprise.
Так, давай наконец как-то чётче формулировать свои мысли. А то внезапно
Вы путаетесь. Сначала вы (ссылаясь на FDG) говорили, что при дизайне фреймворка
нужно рассматривать максимально широкий спектр задач потенциальных пользователей.
превращается в цитату, которую я не приводил, и которая ещё и понята неверно.
AS>Но указывают, что если фреймворк прогрессивный, то сценариев он покрывает как правило много.
Гхмм... вообще-то там говорится о переходе от отдельных узкоспециализированных фреймворков (mfc/atl, как пример) к фреймворку как к платформе, которая включает в себя разные наборы API для разных задач.
Т.е. широта охвата — это не отдельное API-всемогутор, а возможность использовать в одном приложении разные API от разных вендоров без особых проблем, т.к. они выполнены в общем архитектурном стиле.
The main drawback3 is that the multitude of frameworks makes it difficult for developers using one of the frameworks to transfer their knowledge to the next skill level or scenario (which often requires a different framework). For example, when there is a need to implement a different application that requires more powerful functionality, developers hit a very steep learning curve, because they have to learn a completely different way of programming,
______ 3Other drawbacks include slower time to market for frameworks that are wrappers on top ofother frameworks, duplication of effort, and lack of common tools.
AS>Итак, текущее состояние обсуждения:
А, как обычно — с каждой стороны выглядит по своему
За всех участников не скажу, но как минимум я точно никаких набросов аля "ты дурачок" делать не собирался, если так было воспринято — мои извинения. Серьёзно, сорри.
Насчёт остального — да, фреймворки это сложно. Не в том смысле сложно, что "не знаешь — не лезь и даже не пытайся", это дурость полная. Тут любой проектировщик API в одинаковых условиях будет. Смысл в том, что на начальном этапе очень легко допустить ошибки, которые потом так и останутся. Или, в лучшем случае, просто сделать кучу работы на выброс.
Поэтому перед тем как "делать что-то" обязательно надо определиться, что именно должно получиться в итоге и провести предварительную разведку. Если такой подход не нравится, то можно посмотреть на альтернативу — проектирование от паттернов — но это уже к яве.
А вот определиться у нас хронически не получается, не в последнюю очередь из-за того, что тебе пишут одно а ты воспринимаешь совсем другое. Серьёзно. Сформулируй наконец ответ на простой вопрос: какие ключевые сценарии использования у будущего фреймворка. Я не про отдельные фичи, а про проблемы, которые с его помощью можно решать, типовой шаблон "что есть-что надо-ограничения" в прошлом посте писал. После этого уже можно будет определиться с тем, что брать за основу — всё с нуля, форк проекта, или просто набор хелперов поверх библиотеки и уже тогда задумываться об архитектуре.
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>Наличие зависимости запросто определю — увижу в .csproj элемент Reference вместо ProjectReference. AS>То есть для зависимость записана в .csproj для определения наличия зависимости .sln не нужен.
Подвох не заметили. Имя проекта — B. Имя бинарного файла для этого проекта — somelib.dll, причём у отдельных эстетов оно ещё и от build conditions зависит. Без разбора зависимостей в sln-файлах правильно сопоставить зависимости даже в средних солюшнах из пары сотен пректов — это тот ещё гемморой. В общем .sln надо парсить обязательно. А то на первой же копии проекта, не включённой в солюшн всё обломается.
AS>если мне дадут методику для .csproj, AS>то для .sln, .nuspec, .package и .config я её уже сам применю по-аналогии.
Как охранять форматирование при записи xml-документов? Вот точно помню, что там был какой-то подвох, поищу. Вот это за основу + XmlWhitespace и IXmlLineInfo для форматирования новых тегов / атрибутов.
DO understand and explicitly design for a broad range of developers with different programming styles, requirements, and skill levels.
...
Therefore the Word team puts in many more features that my mom might find helpful rather than the features the development team finds helpful.
Ну вот я и пытаюсь сделать такой фреймворк, чтобы он решал задачи, которые мне кажутся полезными в принципе, а не только те, которые нужны в ближайшие две недели.
Примеры задач, решение которых должен обеспечивать фреймворк:
1) дан .csproj и пожелания по его изменению (в каком-то формате, например как вызовы API).
Нужно сформировать патч в формате RFC 5261 (не помню номер точно, в общем есть RFC на XML Diff) минимального размера с минимальным количеством операций
2) сформировать обычный патч для diff минимального размера
3) просто изменить непосредственно .csproj, породив минимум разницы (а не переформатирвов все отступы во всём файле)
Уже поверх этого я собираюсь навернуть БД nupkg и всю остальную логику по
скачиванию архивов, распаковне, анализу nuspec, скачиванию исходников, дополнительным файлам с метаданными,
изменению и обновлению зависимостей
и это в scope фреймворка не входит.
Текущие инструменты не дают возможностей для точечных изменений. Это раздельные мелкие фреймворки — либо только для XML, либо только для build items и т.д.
S> Имя проекта — B. Имя бинарного файла для этого проекта — somelib.dll
да не парит меня это. И я уже написал почему. Потому что солюшены я и так читаю во-первых,
а во вторых — моя задача разобрать репозиторий на отдельные проекты, а не собрать.
Соберется оно потом само, потому что dll-ки встанут в GAC и найдутся через Reference-ы, которые я пропатчу.
А каждый проект будет собираться независимо от своего .sln
I believe that LoadOptions.PreserveWhitespace and SaveOptions.DisableFormatting only instruct XDocument on how to handle whitespace in terms of indentation and the content of text nodes. It would still normalize the attributes, etc.
You may wish to use an overload where you specify an XmlWriter that is configured to do what you want, and if you can't find a configuration that works with the default XmlTextWriter, you could always create your own XmlWriter.
XDocument.Save has a SaveOptions argument which can be set to disable formatting. This has the same effect as putting the XmlWriterSettings "Indent" property to "false"
У меня мысль была — раз рослин служит для создания редакторов разных синтаксисов,
то научиться описывать синтсаксис .csproj для Roslyn как платформы.
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>Примеры задач, решение которых должен обеспечивать фреймворк:
О, ну так гораздо интереснее получается. Забавная штука должна выйти если не секрет, для чего? Это уже не в рамках темы, просто любопытно.
Вот что я точно могу подсказать — это сохранение форматирования при правке. Тут два варианта. Или используем XDocument с preserve whitespace = true + расставляем XmlWhitespace для новых тегов / атрибутов, или, если документ целиком нельзя держать в памяти, городим свой visitor поверх пары xml reader + xml writer, как всё в том же XDocument.
Всё остальное — это уже на ваш выбор. Я бы обратил внимание на следующее:
1. Семантическая модель для csproj и прочих xml-based форматов. Она вам поможет, но не очень сильно, т.к.
* csproj позволяет очень много вольностей, вот это к примеру — валидный файл
* куча зависимостей может быть разобрана некорректно, особенно если они помечены как conditional symbols или спрятаны в Import.
В общем, если делать — посмотрите, как сделаны типизированные теги в OpenXml SDK (наследниками от XElement). Что-то более сложное будет выглядеть оверкиллом
2. Обработка csproj xml-патчем. Будет хорошо работать только при условии, что csproj не правился кардинально. Ну и кроме того, что-то я не припомню готовой реализации этого дела на шарпе.
Может, отказаться от этого функционала и сразу превращать пожелания по изменению проекта в код, который правит xml / семантическую модель?
А это дубовый вариант как раз, без сохранения форматирования. В общем тут три варианта сходу нарисовываются:
* или вообще забить на форматирование атрибутов (ага, именно в этом был подвох, спасибо, что напомнили),
* или делать мегаизвращение — вытаскивать начало-конец элемента через XmlLineInfo и заменять текст между ними новым значением.
* или городить свою логику поверх xmlReader с запоминанием позиций элементов, кавычек (ага, одиночные заменяются на двойные) и кучу других вещей.
UPD ещё модно поспрошать kirill osenkov, он в своё время делал парсер xml на базе рослина
Нам в своё время хватило первого варианта, т.к. csproj-файлы редко форматируются нестандартным способом.
Он может быть и парсер,
но не очень похож на API для изменения. Узлы там поудалять, повставлять я не вижу как с помощью этой библиотеки...
Допустим надо превратить Reference в ProjectReference. То есть один узел удалить, другой (в другое место) вставить. И чего?
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>Он может быть и парсер,
Ну так я ж не зря сказал про "поспрошать kirill osenkov" Он по крайней мере подскажет куда копать. В недрах студии xaml lang services точно на roslyn, насчёт xml не уверен.
S> Что-то более сложное будет выглядеть оверкиллом
А сложнее нужно.
Потому что очевидным образом есть два уровня абстракции — просто проекты msbuild
и конкретно шарповые проекты, у них, например, бывают конфигурации с именами. А имена конфигураций — это важно.
AS>Потому что очевидным образом есть два уровня абстракции — просто проекты msbuild AS>и конкретно шарповые проекты, у них, например, бывают конфигурации с именами. А имена конфигураций — это важно.
Конфигурации работают с любыми msbuild-проектов и не является обязательными. Я ж выше приводил пример csproj-файла без конфигураций.
Пропись конфигов ч/з SolutionConfigurationPlatforms и ProjectConfigurationPlatforms в .sln-файле — лишь один из способов.
Microsoft's own recommendation for API developers and developers of third-party libraries is that they use the Collection<T>, KeyedCollection<TKey, TItem>, and ReadOnlyCollection<T>.
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>Если хочется иметь полный контроль над всем, AS>но при этом не давать доступ к нижним уровням на прямую,
По-моему, ключевое противоречие зарыто здесь.
Нельзя в одной архитектуре объединить полный контроль всего и абстрагирование пользователей интерфейсов от деталей реализации, т.к. они влекут за собой противоположные решения и последствия.
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>Итак, текущее состояние обсуждения:
AS>Q) мне нужен фреймворк. AS>A) ты дурачок, фреймворки это сложно, тебе фреймворк не нужен, есть полно готовых решений (более 10 способов)
такое бывает)
Хорошо бы конкретизировать ваш случай деталями, а именно — какие именно есть слои с кратким описанием сути и для какого сценария надо выставить апи более нижнего слоя...
если не секрет, для чего? Это уже не в рамках темы, просто любопытно.
