Василий Банников

Jenkins:
- Бесплатный
- Можно развернуть на Windows, что тебе нужно для net framework

Ещё бы порекомендовал Teamcity - вроде первые несколько раннеров у него тоже бесплатные и он достаточно хорошо с .net интегрирован

1. https://www.linuxatemyram.com/
2. Особенности замера.

Ну и 3:
Даже если действительно на винде эта программа жрёт 11мб, а в докер-контейнере 200мб. Что это тебе даёт?
Винда всё ещё будет отжирать минимум гиг, а линуксовое ядро будет болтаться около 100мб. И не забывай про п1 и 2

вообще нет, но можно попробовать упороться в автоматизацию:
Вариант раз:
Написать соответствующие скрипты для ansible.

Вариант два:
Контейнеризироваться и использовать кубер или хотябы голый докер.

Вариант три, о котором я немного забыл:
Octopus Deploy - ни разу не пользовался, но многие хвалят.

Даже на винде трогать IIS Manager руками - не кошерно.

https://ohmyposh.dev/ или https://starship.rs/ поставь и будет у тебя нужный результат.

Ну и тему нужно выбрать соответствующую.

fixed запрещает перемещать объект в памяти.
Сборщик мусора может и не соберёт объект, но без fixed он может его переместить и тогда указатель станет невалидным.

stackalloc выделяет данные на стеке, а по тому с ним такой проблемы нет, ну и да - он не нагружает gc, хоть и обладает кое-какими другими потенциальными проблемами.

1. Финализация вполне может быть отложена по усмотрению сборщика мусора
2. JIT вполне может так скомпилировать твой код, что вот этот = null будет опущен => при поиске ссылок, ссылка всё ещё будет на стеке.
Попробуй вынести в новый метод и посмотреть там.

Ну и такой код как у тебя в реальном мире лучше не использовать (это я про принудительный вызов гц, логи в финализаторе, и финализатор который не чистит неуправляемые ресурсы)

PS: читаем внимательно документацию и особенно слова "не гарантирует"

Используйте параметр , mode чтобы указать, должна ли сборка мусора происходить немедленно или только при оптимальном времени для освобождения объектов. Использование этого метода не гарантирует, что вся недоступная память в указанном поколении будет освобождена.

Чтобы настроить навязчивость сборки мусора в критические периоды в приложении, задайте LatencyMode свойство .

Сборщик мусора не собирает объекты с номером поколения, превышающим указанное параметром generation . Используйте свойство , MaxGeneration чтобы определить максимально допустимое generationзначение .

Чтобы сборщик мусора учитывал все объекты независимо от их создания, используйте версию этого метода, которая не принимает параметров.

Чтобы сборщик мусора отнимает объекты до указанного поколения объектов, используйте перегрузку GC.Collect(Int32) метода . При указании максимального поколения собираются все объекты.

Плохо тем что JIT будет нагружаться лишний раз там, где это не требуется.
Лучше этим атрибутом помечать только очевидные hot path.
Аналогично с агрессивным инлайнингом - только с ним ещё страшнее.

Если совсем боишься - можешь брать CancellationToken не из аргументов, а из контекста (HttpContext.RequestAborted)

А подсовывает его тебе рантайм через процесс под названием model binding:
https://learn.microsoft.com/en-us/aspnet/core/mvc/...
Биндинг происходит чисто по совпадению типа и имя аргумента не влияет на него.

Можно к примеру попробовать создать Mutex указав его имя.
Если удалось открыть - значит ещё не запущен второй экземпляр.
Если не удалось открыть - значит уже запущен.

Это по идее должно быть надёжнее, чем создавать файл.
Вот рабочий код:

using var globalMutex = new Mutex(false, "Global\\test_mx");
var result = globalMutex.WaitOne(1000);
Console.WriteLine(result ? "Owned" : "Not owned in 1s");
Console.ReadLine();

При попытке запустить сразу два экземпляра, в одном будет выведено: Owned, а в другом Not owned in 1s

Префикс Global\ обязателен. Без него мутекс будет локальный для текущего процесса.

Если ты не используешь unsafe, то сборщик мусора сам все ссылки после передвижения поправит - ради этого он все managed потоки останавливает.

Если ты используешь unsafe и передаёшь куда-то сырые указатели, то тогда тебе надо запинить объект чтобы гарантировать, что объект не будет перемещаться. Для этого, например, есть конструкция fixed, но оно работает только в рамках блока и одного потока.

Это особый класс, вот он и знает то, чего простым смертным не положено.

Информация о типе хранится в самом начале экземпляра объекта - по тому даже не обязательно его как-то по особенному переопределять, чтобы что-то работало.

Вот тебе ещё немного для взрыва мозга:
Object - ссылочный тип.
Все структуры - значимые типы.
Но при этом все структуры каким-то образом наследуют от Object, хотя в обычной ситуации структуры вообще ни от чего наследовать не могут.

UPD: а во втором случае всё работает, тк все объектынаследуются от object => происходит вполне легальный апкаст (или боксинг в случае int)

В случае с .net (core) ты можешь собрать self contained приложение.
https://learn.microsoft.com/en-us/dotnet/core/depl...

В случае с net framework такого нет, но ты можешь просто вместе со своим приложением распространять инсталлятор net framework нужной версии

Зависит от того, что именно нужно с docx делать.
Есть npoi - для высокоуровневых абстракций, есть openxml SDK для низкоуровневых абстракций, есть templateengine для шаблонов.
https://www.nuget.org/packages?q=Docx

Да и интероп вроде тоже должен работать, но только на винде, и если офис установлен, и на десктопе, но не сервере.

И как можно например выводить что либо на консоль не используя эту библиотеку(если конечно так можно)?

Нельзя.

Как работают методы такие как: Awake, Start, Update. Если точнее их вызывает главный скрипт Main и как работает Update?(while(true){}?)

Вызывает сам юнити. Это детали реализации, о которых тебе думать не нужно.
Update вызывается перед отрисовкой кадра.
Если сделать while true, то всё зависнет.

И еще один общий вопрос, можно ди взглянуть на их код?

На стандартную библиотеку dotnet ты можешь посмотреть на сайте source.dot.net либо на гитхабе.

На код юнити ты посмотреть не можешь, тк он проприетарный и написан на C++

Языки и технологии: C# WPF EntityFramework Windows

С таким желаемым набором технологий единственный вариант - RDP к машине, где будет установлена студия.

Если убрать Windows и WPF, а Entity Framework заменить на EF Core, то тогда можно попробовать Github Codespaces.
Естественно, адекватно это можно будет использовать только на планшете с клавиатурой и мышью/трекпадом