Почему VSCode панель Outline view не показывает классы и функции из C# кода?

Question

Drovosek01 @Drovosek01

Почему VSCode панель Outline view не показывает классы и функции из C# кода?

Я работаю над своим проектом-велосипедом в котором есть код на нескольких языках, в том числе на C# - https://github.com/Drovosek01/ReplaceHexPatcher/bl...

Я хочу получить список всех функций, которые ест в этом файле/классе - как это сделать?

Я погуглил и на Stackoverflow говорят, что в VSCode давно встроена панель Outline которая показывает все методы из файла, но у меня она не работает с этим файлом
В ней написано "No symbols found in document HexHandler.cs"

скрин

Вопрос задан 01 окт.
145 просмотров

Комментировать

Подписаться 1 Простой Комментировать

Помогут разобраться в теме Все курсы

Merion Academy

C# разработчик с нуля

4 месяца

Далее
Stepik

Профессия "C# разработчик"

1 неделя

Далее
Skillfactory

Профессия C#-разработчик

12 месяцев

Далее

Пригласить эксперта

Ответы на вопрос 1

18 комментариев

Drovosek01 @Drovosek01 Автор вопроса

Все верно - у меня не проект на C#
Проект на Powershell, который при выполнении компилирует C# код и подключает к текущему скрипту...

Получается оглавление/содержание отдельно взятого C#-файла не удастся посмотреть (то есть не существует инструментов ля этого)?

Написано 01 окт.
Василий Банников @vabka

Drovosek01, а нужно ли на лету генерировать этот код? Нельзя заранее его скомпилировать в dll?
Вообще если поменять расширение на ".csx", то тогда стандартное расширение для C# будет воспринимать его как C# interactive и вот он уже может сам по себе существовать.

Естественно нужно заранее установить .NET SDK и плагин для C#.
https://marketplace.visualstudio.com/items?itemNam...
https://dotnet.microsoft.com/en-us/download

Хотя ещё в .NET 10 по идее можно .cs отдельно от csproj иметь
https://devblogs.microsoft.com/dotnet/announcing-d...

Написано 01 окт.
Drovosek01 @Drovosek01 Автор вопроса

а нужно ли на лету генерировать этот код?

Василий Банников, в данном случае - да, нужно)

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

Если распространять заранее скомпилированные бинарники, то это уже не будет нативно

Написано 02 окт.
Василий Банников @vabka

Drovosek01, что понимается под словом "нативно"?

Написано 02 окт.
Drovosek01 @Drovosek01 Автор вопроса

Василий Банников, это значит что код выполняется непосредственно силами/средствами чистой системы.

То есть переустановили вы Windows, еще ничего в нее не устанавливали, а просто скачали текстовый файл - скрипт. И он не докачивания никаких бинарников и исполняемых файлов - делает свою работу.

Это достигается за счет того, что C# код компилируется самим Powershell'ом при выполнении

Написано 03 окт.
Василий Банников @vabka

Drovosek01, чтобы скомпилировать C# на целевой машине - на ней должен быть компилятор.

А вот если скомпилировать его заранее, то компилятор не понадобится.

То есть заранее скомпилированный бинарник будет иметь меньше требований, чем скрипт, который его компилирует.

Написано 03 окт.
Drovosek01 @Drovosek01 Автор вопроса

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

Drovosek01, чтобы скомпилировать C# на целевой машине - на ней должен быть компилятор.

Так в Windows еще с 7 версии компилятор C# идет из коробки

Написано 06 окт.
Василий Банников @vabka

Drovosek01, а вот отсюда подробнее. За всё время, сколько я работаю с C# - всегда нужно было либо .NET Framework DevPack ставить, либо .NET SDK.
Вот .NET Runtime какой-то древней версии действительно есть

И всё равно: зачем добавлять лишний шаг с компиляцией на целевой машине?

Написано 06 окт.
Drovosek01 @Drovosek01 Автор вопроса

Вот .NET Runtime какой-то древней версии действительно есть

Ну для компиляции то только он и нужен)
Скармливаем файл с C# кодом компилятору - csc.exe и получаем dll или exe

Посмотрите файл build.cmd в моем репозитории и вы поймете

И всё равно: зачем добавлять лишний шаг с компиляцией на целевой машине?

Потому что цель проекта - нативная работа в Windows.
То есть установил чистую и официальную Windows - и можно применить скрипт-утилиту.

Не нужно устанавливать никаких питонов, яву, сишарп и прочего рантайма
Все работает только за счет того, что есть в системе "с завода"

P.S.
Это рождает еще один плюс - в Windows ARM это будет работать также нативно, не только для системы, но и для процессора

Написано 06 окт.
Василий Банников @vabka

Drovosek01, оно не будет работать нативно для процессора, так как тот csc, который предустановлен - компилирует только в MSIL, но не в машинный код.

Не нужно устанавливать никаких питонов, яву, сишарп и прочего рантайма
Все работает только за счет того, что есть в системе "с завода"

Ну так раз в системе есть csc и powershell - значит там есть .net runtime.
А раз он есть - значит не нужен никакой промежуточный шаг с компиляцией. Можно сразу dll-ку грузить .

У тебя нет гарантии, что на целевой машине будет именно та версия csc, которая тебе нужна для компиляции. И никто не может гарантировать, что его не удалят в очередной новой версии или в какой-нибудь говносборке.

Написано 06 окт.
Drovosek01 @Drovosek01 Автор вопроса
Ну так раз в системе есть csc и powershell - значит там есть .net runtime.

Ага, а 2+2=4
Зачем писать очевидное?

А раз он есть - значит не нужен никакой промежуточный шаг с компиляцией. Можно сразу dll-ку грузить .

Нафиг мне твоя dll-ка?
если я могу положить скрипт в репозиторий и выполнить его просто 1 строкой в терминале, например

irm "https://github.com/Drovosek01/ReplaceHexPatcher/raw/refs/heads/main/core/v2/ReplaceHexBytesAll.ps1" -OutFile $env:TEMP\t.ps1; & $env:TEMP\t.ps1 -filePath "C:\Program Files\Adobe\Adobe Photoshop 2025\Photoshop.exe" -patterns "B9000000/11111111", "0F 31 89 C2 44 29 C0 41 89 D0 44 39 C8 41 89 C1/11", "EF C4 66 41 0F 6F 22 66/778899" -showMoreInfo -makeBackup -showFoundOffsetsInHex; ri $env:TEMP\t.ps1

Какую проблему решит использование dll-файла?

У тебя нет гарантии, что на целевой машине будет именно та версия csc, которая тебе нужна для компиляции.

Что значит "та версия csc"?
Мне не нужна какая-то конкретная версия, мне подойдет любая, потому что в моем коде только базовые структуры без каких-либо синтаксических навротов.

И никто не может гарантировать, что его не удалят в очередной новой версии или в какой-нибудь говносборке.

А чего вы остановились только на этом?
Надо продолжить мысль - никто не гарантирует, что завтра не упадет метеорит и скрипты и компьютеры станут бесполезны

Вы пишите какую-то фигню.
Осознайте сначала что такое нативное выполнение без скачивания и установки сторонних библиотек
Написано 08 окт.
Влад aka iamkisly @iamkisly

Drovosek01, а это не важно. Создаете решение и проект с этим файлом. Вы можете иметь много решений и проектов для одних и тех же файлов

Написано 09 окт.
Василий Банников @vabka

Drovosek01,
Осознайте сначала что такое нативное выполнение без скачивания и установки сторонних библиотек

Так тебе же и не надо ничего устанавливать и скачивать. Ты можешь dll-ку прямо в powershell-скрипт впихнуть.

Написано 09 окт.
Drovosek01 @Drovosek01 Автор вопроса

Василий Банников, как dll впихнуть в сам powershell-код?
Закодировать в base64 и положить в константу и потом при выполнении раскодировать и подключать?
Это ощутимо увеличит размер самого скрипта и... это сравнимо с компиляцией исходников

И самый главный вопрос:
Какую проблему это решит?

Написано 09 окт.
Drovosek01 @Drovosek01 Автор вопроса

Влад aka iamkisly, а чтобы создать решение мне нужно ставить Visual Studio?
Или есть какой-то "шаблон" в который я просто могу вставить свой файл указав в конфиге строки на него?

Написано 09 окт.
Василий Банников @vabka

Drovosek01, dotnet sdk достаточно поставить и вызвать dotnet new

Написано 09 окт.
Василий Банников @vabka

Drovosek01,
как dll впихнуть в сам powershell-код?

Как base64 в виде текста и при запуске сохранить как файл

Написано 09 окт.
Drovosek01 @Drovosek01 Автор вопроса

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

Как base64 в виде текста и при запуске сохранить как файл

Ok, а какую проблему это решит?

Написано 13 окт.