весьма неудачная затея. Вы наполовину убиваете преимущества многопоточной обработки запросов тем, что обращаетесь к базе через одно подключение. Работать с ним вам необходимо будет внутри критической секции, чтобы его не схватили несколько потоков сразу, и по большей части запросы будут ждать друг друга. Также почитайте про database connection pooling в дотнете - там будет написано, что создание и уничтожение объекта подключения вовсе не значит, что создается/уничтожается физическое подключение к базе по сети. Общепринятой практикой считается открытие и закрытие подключения в каждом обработчике.
Дело в том что static-поля это далеко не лучший способ хранить состояние в ASP.NET приложении и если это не лабораторный тест, то лучше воспользоваться application state.
Доступ к static-полям нужно синхронизировать, т.к. разные инстансы контроллера могут быть созданы в разных потоках. Блокировки для статических полей не нужны только если вы инициализируете их однократно, а в контроллерах используете только на чтение. А, кстати, зачем вам static-поля?
> Я думал что new только для создания объектов.
new может создавать как единичные экземпляры, так и массивы примитивных или пользовательских типов. Он совмещает выделение в куче нужного объема памяти и вызов конструктора, если вы создаете экзмепляр пользовательского типа (т.е. класса).
Вообще, векторный new это конечно вещь более чем работающая и выполняющая свои задачи, но все же это наследие из Си. И используют ее как правило в критичных к производительности местах, нередко оборачивают в более крупный класс, чтобы быть уверенным в безопасности работы с массивом на куче. Поэтому, почитайте и сравните классы из стандартной библиотеки: en.cppreference.com/w/cpp/container/array , en.cppreference.com/w/cpp/container/vector . Для вашей задачи вектор - самое оно, т.к. вы заранее не знаете сколько вытащите записей из БД.
Если хотите, чтобы вам помогли, опишите подробнее какими библиотеками пользуетесь, какую задачу решаете и что вообще стоит за понятием "векторная карта". Карта мира, вроде OSM?
Ваша программа, новый Qt и эта "библиотека" под одной студией собраны? Если райнтамы разные, и вы обмениваетесь с библиотекой объектами STL-ных классов, то ничего хорошего не будет. Или экзмеплярами классов и структур Qt. Даже передача какого-нибудь QModelIndex может вызвать проблемы, если приложение и библиотека собраны под разные версии С++ runtime (в случае разных райнтаймов передавать по значению можно только примитивные типы, ну или указатели на объекты, которые "живут" внутри библиотеки, т.е. ей создаются, ей уничтожаются и живут в её же куче. тогда проблем быть не должно).
в общем-то можно заглянуть в windows update, если у вас достаточно много приложений, и они устанавливали рантаймы, то у вас наверняка будут установленные обновления на них.
P.S. конечно это все резонно, если прога - нечто более сложное, чем переименовалка mp3-файлов по содержимому тегов (что-то критичное для бизнеса, или дорогостоящий продукт, когда есть опасность потери имиджа компании).
"в любом случае" - я имел в виду, чтобы это оставалось обслуживаемым, например, чтобы на рантайм ставились обновления. Его можно и просто положить рядом с вашим EXE-шником (близзы так делают кстати), и нет проблем. Файлов больше одного, но установка не нужна.
с распространением приложений под винду в любом случае разбираться надо, райнтам вам в любом случае придется поставить вместе с приложением. Что касается Qt, да, есть немного гемора, но один раз разобраться будет достаточно. Ну и Dependency Walker в помощь (хотя с динамически загружаемыми плагинами он ситуацию не прояснит, надо доки читать, все написано).
И вообще, если хотите серьезно решить вопрос распространения приложения, уделите время Windows Installer-у, например ознакомтесь с wixtoolset.org
Раз уж на то пошло, давайте отдельно говорить о Qt как о библиотеке и о QtCreator как IDE. В больших проектах сценарий VS+Qt скорее правило, чем исключение. И, как библиотека, Qt - это серьезный инструмент без "детских" болезней.
Если у вас клиенты: а) не пишут в базу; б) имеют плохой интернет; в) редко требуют у себя полной копии базы - может проще тогда веб-сервис сделать и выдавать данные по запросу? 30 Мб это конечно довольно много, но может проще ответ web-сервера закэшировать, чем базу синхронизировать? Синхронизация обычно нужна либо для master-master сценариев, либо когда один сервер не справляется с запросами на выборку, и данные копируются на другие сервера (для выполнения read-only запросов).
Кстати, можно и постраничную выдачу добавить, например по 1000 записейза запрос.
проверьте, что вы скомпилили под ту версию фреймворка, которая есть на целевой машине. Если нет, установите. Насколько я помню, ошибка при запуске может быть не вполне внятной.
не соглашусь насчет редактирования проектов MSBuild: конечно xml-синтаксис нельзя назвать аккуратным и кратким, но лично я в последнее время чуть ли не вручую редактирую proj-файлы - это помогает следить за параметрами проекта, аккуратно коммитить, еще удобно выносить общие свойства в отдельный файл, и инклудить его в каждый проект (удобно например для настроек вроде output directory или флагов для NuGet).
Интересный вопрос на самом деле. Была даже идея прокси-сервера в пару к bookmark-серверу (например, firefox sync), который бы периодически скачивал и хранил версии страниц, которые у тебя в закладках. Очень удобно, было бы не страшно, если страница меняется или сайт загибается.
