все же ты не правЯ, конечно, не уверен, но на сервере, если используется C#, как в твоём случае, должен быть собранный проект (то есть .dll), а ты пытаешься скормить файл проекта .cs.
Ни разу не пытался кормить серверу файлы проекта, поэтому и сказал, что не уверен.все же ты не прав
Ты можешь напрямую в xml проекта своего прописать пути к каждому файлу и забыть про компилНи разу не пытался кормить серверу файлы проекта, поэтому и сказал, что не уверен.
А в чём плюс данного метода? Не вижу ни 1 преимущества перед полностью собранным проектом.Ты можешь напрямую в xml проекта своего прописать пути к каждому файлу и забыть про компил
По сути, плюсов и разницы нет, только проект не собираешь и таким образом делай хоть в блокнотеА в чём плюс данного метода? Не вижу ни 1 преимущества перед полностью собранным проектом.
Я не знаю как собрать тогда проект в длл. Подскажешь?Я, конечно, не уверен, но на сервере, если используется C#, как в твоём случае, должен быть собранный проект (то есть .dll), а ты пытаешься скормить файл проекта .cs.
Как js-еры в шарп пытаютсяПо сути, плюсов и разницы нет, только проект не собираешь и таким образом делай хоть в блокноте![]()
Конкретно в дллЯ не знаю как собрать тогда проект в длл. Подскажешь?
Открываешь проект в своей среде (Я, например, пользуюсь Visual Studio 2019 Community), сверху есть кнопка 'Сборка', внутри 'Собрать решение'. При этом желательно ставить конфигурацию 'Release x64', потому что х86 бессмысленно, сейчас все системы на машинах под серваки на 64 битах (ибо 32 (86) битная система не поддерживает более 4гб оперативной памяти), когда проект успешно собирается - снизу будет вывод пути, где находится готовый файл .dll, его и нужно использовать так же, как ты используешь сейчас .cs, записать в мете и правильно расположить.Я не знаю как собрать тогда проект в длл. Подскажешь?
Ну как разницы нет. При полной самостоятельной сборке ты заранее можешь видеть все ошибки в проекте, плюс неизвестно какая конфигурация сборки будет через рейдж? Да и безопасность в плане чтения исходного кода третьими лицами, если что, какая-никакая у собранного проекта на 0.001% получше xD (ясное дело, что его точно так же можно разобрать и смотреть). Я бы никогда не выбирал такой вариант, хз.По сути, плюсов и разницы нет, только проект не собираешь и таким образом делай хоть в блокноте![]()
При этом ошибка, кстати, очевидно даже написана:
Хорошо попробуюОткрываешь проект в своей среде (Я, например, пользуюсь Visual Studio 2019 Community), сверху есть кнопка 'Сборка', внутри 'Собрать решение'. При этом желательно ставить конфигурацию 'Release x64', потому что х86 бессмысленно, сейчас все системы на машинах под серваки на 64 битах (ибо 32 (86) битная система не поддерживает более 4гб оперативной памяти), когда проект успешно собирается - снизу будет вывод пути, где находится готовый файл .dll, его и нужно использовать так же, как ты используешь сейчас .cs, записать в мете и правильно расположить.
Спасибо помогПри этом ошибка, кстати, очевидно даже написана:
'Some assemblies are not fully loaded from memory at runtime, you may have to copy your assembly into 'runtime\' folder
В проекте ты можешь использовать дополнительные сборки из NuGet'а, например, которые сами уже являются dll'ками. Так вот они у тебя должны лежать в папке dotnet/runtime/, как говорит ошибка. То есть проблема в том, что твоя сборка не может сбилдиться без сборок, которые присутствуют в коде.
Пример:
Если в своём коде на сервере ты используешь jsonnewtonsoft, то у него есть своя dll'ка, которая уже скачена на твоем пк из nuget'а (можно найти её на своём пк) и она должна лежать в папке, которую я писал выше.