Критерий один: способность разработчика, который это будет разрабатыать, реализовать систему, удовлетворяющую всем требованиям. Причем, желательно, с минимально-возможными затратами.
Для начала - стоит подобрать эту кучу и... запихнуть ее в класс хотя бы, чтобы не засорять глобальное пространство имен.
Далее, "куча" никому не впилась. Чтобы было легче писать код, используются библиотеки функций, решающих вполне конкретные задачи, типа moment.js
А аналог вашей "кучи" найдется у каждого сколько-нибудь пописавшего программиста, и своим ему пользоваться тупо удобнее, чем искать ваше, а потом разбираться в том, что вы там накосорезили. Учитывая примитивность решенных задач и явное непонимание места вашего кода в чужом проекте, связываться с ним - себе дороже.
Приведу очень условный пример.
Есть база данных банка;
Клиент:
- user_id
- другие поля
Кредит:
- какие-то поля
- user_id (Внешний ключ к Клиент)
- сумма кредита
И вод представьте - пришел условный Вася Пупкин и взял кредит на 10 лямов, чтобы открыть бизнес.
Что-то происходит и запись о Васе из таблицы "Клиент" исчезает.
И тут приходите вы, оформить кредит на 100к на условную мазду. Система, видя свободный Васин id присваивает его вам и теперь вы должны банку 10 миллионов 100 тысяч. Правда круто?
Пример абсурдный, но суть, думаю, вы поняли.
Это sequence. Последовательность. Это - как туалетная бумага. Использованные номера можно выкинуть. Зачем их повторно брать? У вас же нет желания из мусорного ведра тягать грязные бумажки?
В дотнете внешние и межпроектные зависимости (PackageReference, ProjectReference) прописываются и ставятся для каждого проекта отдельно. Более того, по умолчанию каждый library-проект также становится самостоятельным NuGet-пакетом, если в настройках включить сборку последнего.
Солюшен - это лишь примочка для объединения нескольких проектов во что-то, что можно собрать одной командой в IDE или в консоли. Ну и открывать сразу всё в IDE тоже удобно.
Лично я рекомендую в большинстве случаев пользоваться подходом "один Git-репозиторий - один солюшен - много проектов". Репозиторий - единица версионирования (т.е. ВСЕ проекты в репе всегда имеют одинаковую версию), проект/пакет - единица управления зависимостями.
Итого имеем следующие выводы:
вы собираетесь притащить к себе довольно толстые библиотеки, "подружить" которые в рамках одного исполняемого бинарника будет непросто. Т.к. для шарповых MSBuild-проектов каждый проект (csproj) собирается в отдельную сборку (assembly), то логично иметь WPF и WinForms варианты в виде отдельных проектов (и в виде двух разных бинарей на выходе)
если вы планируете общий релиз для обоих приложений - т.е. когда не бывает так, что допустим WPF-приложение релизится, а WinForms - нет - тогда делайте один репозиторий и один солюшен с несколькими проектами;
если вы планируете независимый релиз для каждого приложения - тогда другая история, но надеюсь вам это не нужно
М1 камень реально шустрее. На 7м рязане собирает чуть медленее.
Но не гнались бы Вы сразу за топом пока не будете зарабатывать на этом в месяц (за полгода) как стоит ваш комп.
Для начала хватит 16гигов и любого поноценного камня свежее 8 лет. Ссд пошустрее и побольше только сразу возьмите. Нормально вполне тянет хуавейский ноут трехлетка (рязань 5 / 16 / 512 ) тогда стоил полтинник
Скорее всего, изначально URL файла выглядел наподобие https://домен/папка/файл.js?crc=6, где ?crc=6 использовалось для обозначения версии этого файла на случай, если в кэше браузера могла находиться какая-либо из предыдущих его редакций, предположительно их было пять (при каждом изменении файла - в URL также менялся этот номер, чтобы браузер считал файл другим и не брал из кэша старый). Но потом этот файл был сохранён на диск на стороне клиента, а в файловой системе вопросительный знак недопустим, потому этот символ был заменён на символ @. Так и получилось такое странное расширение файла. Почем именно crc - скорее всего, просто неудачно выбранное название параметра, который в принципе может называться как угодно или вообще не иметь названия, лишь бы символы после ? различались от версии к версии, если выбран именно такой способ обхода кэша.
Во-первых, при чем тут PyCharm, если это IDE?
Во-вторых, проверьте флаги для pyinstaller: может, вы где-то ошиблись?
В-третьих, добавьте в вопрос больше информации, например: комманду/Makefile/*.cmake/*.mak для сборки скрипта, а так же отчет, выведенный в терминал pyinstaller'ом.
В-четвертых, попробуйте эту комманду, она почти 100% сработает:
WinSock2 - это не библиотека, а прикладное API на Винде. Т.е. вы выбираете не между двумя библиотеками, а между апихой самой ОС, и ей же, обёрнутой в кроссплатформенный boost.asio.
Если задача учебная, и нужно прям поработать с сокетами на низком уровне - возьмите WinSock2, это почти что ванильный Berkley Sockets. Если не нужно работать с сокетами на низком уровне - я бы взял asio. Но тогда вам придётся познакомиться с абстракциями этой библиотеки. В целом, ничего неподъёмного там нет.
Я серьезно. Туркменистан - маленькая страна, в которой сейчас происходит строительство местного кванмена. Еще немного - и контур безопасности замкнется и недоступны будут 100% сайтов. Вы не можете противостоять богатой и технически подкованной местной СБ.
Если хотите харда - можно на SFML, MonoGame и прочих таких фреймфорках.
Либо по классике, Unity, Godot, GameMakerStudio.
От ваших запросов всё зависит.