Такой функции нет и не может быть в ASP.NET, ведь ОЗУ управляет операционная система, а не фреймворк. Ограничить размер физической памяти процесса в Windows можно, например, с помощью функции SetProcessWorkingSetSizeEx. Но я думаю, вместо того, чтобы ограничивать память (что довольно бессмысленная затея для веб-приложения), нужно определить реальную проблему и решать ее. См. например Garbage Collection and Performance. Просто растущий размер Working Set - это не проблема, а нормальное состояние. Каждый запрос выделяет память под некоторые объекты, которые сразу не освобождаются, так как сборка мусора еще не запустилась. Эта память будет освобождена, когда она понадобится другим приложениям. Вот если не освобождается, а вместо этого падает с OutOfMemoryException, тогда нужно искать утечку или оптимизировать потребление памяти.

Существует параметр конфигурации System.GC.HeapHardLimit для ограничения максимального размера управляемой кучи, возможно вам это нужно. Или просто периодически вызывать GC.Collect с четвертым параметром true, это вызовет сборку мусора и сжатие кучи, что должно освободить всю ненужную память. 

Опишите подробнее ситуацию:

- Какая ОС

- По какой характеристике оцениваете потребление памяти (рабочий набор, виртуальная память) и через какое ПО ее получаете

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

- До какого значения уменьшается потребление памяти после сборки мусора

Да, я имел в виду именно такой вызов GC.Collect. Абсолютно правильно было бы использовать GC.MaxGeneration вместо константы 2, но это пока не важно. 

138 - 130 = 8 MB, это слишком мало. Когда выделено так мало памяти, судить о том, что там освобождается, а что нет, довольно трудно. Возможно, CLR решает, что при таком малом потреблении нет смысла что-то освобождать, так как память скоро понадобится снова. Кроме того, сам первый вызов GC.Collect может выделять память под что-то. Выполните больше запросов, чтобы количество неиспользуемой памяти было ощутимым: создайте скрипт, который будет отправлять запросы автоматически (с той частотой, которую позволяет хостинг, чтобы сайт не заблокировали) и оставьте его работающим на некоторое время. Затем померяйте эффект от GC.Collect при большом потреблении памяти.

Потому что GC.CollectionCount возвращает количество прошедших сборок мусора (автоматически или вызовом GC.Collect) - оно и должно увеличиваться. К потреблению памяти оно не имеет отношения.

Еще раз: GC.CollectionCount возвращает количество прошедших сборок мусора. Если не было автоматических сборок, оно равно количеству запусков GC.Collect. Запуск GC.Collect без параметров запускает сборку для всех поколений. Какое другое поведение вы ожидали?

Но это не "количество объектов", это "количество сборок мусора". Откуда вы взяли про количество объектов? Даже русская документация, хоть и машинный перевод, точно отражает суть: "Возвращает количество операций сборки мусора, выполненных для заданного поколения объектов." https://docs.microsoft.com/ru-ru/dotnet/api/system.gc.collectioncount?view=netcore-3.0

Для получения количества объектов в поколении функции нет и никогда не было. Только профилировщики и счетчики производительности могут его показывать, и то обычно объем памяти по поколениям, а не количество объектов.