Кто-нибудь сталкивался с таким явлением: две формы, на них используется DataGridView, каждый под свою таблицу из локальной БД. В каждом из DataGridView применяются DataSet, BindingSours, TableAdapter, bindingNavigator. Компиляция при отладке без ошибок. Приложение работает! Но на Form1 при попытке проверить свойства любого компонента на форме выходит сообщение"Не удалось привести тип объекта “WindowsFormApp1,GKHDataset” к типу “System.ComponentModel.Componet”! При этом на Form2 всё нормально откликается. GKH - имя БД. Что это и есть у кого мысли как с этим бороться. Буду весьма благодарен за советы!.
Это как?
Ну как обычно, кликаешь мышкой на нужном объекте! Например на самом DataGridView. И в окне свойств смотришь.
хм, странно, видимо баг студии.
По “InvalidCastException winforms designer” и т.п. вроде бы ничего похожего не гуглится.
Вообще мне никогда не нравились все эти датасеты и тейбладаптеры, я обычно либо просто делал SQL запросы через SqlCommand и т.д., либо Entity Framework )
Да, возможно придётся пойти по такому же пути. Но…Майкрософт и вдруг такой глюк. Слабо верится.
Майкрософт и лично Гейтса уже лет 25 же ругают при любом глюке винды, за дело и просто так )
Ну и редкий непонятно как воспроизводимый глюк в ПО для разработчиков это мелочь по сравнению с, например, удалением пользовательских папок в одном из обновлений вин10.
Майкрософт и глюк в одном предложении 
Да быть такого не может 
На микрософт не наговаривайте, довольно сильная команда…
P. S.
Оптимизацию если свести на ноль, узриш свои собственные ошибки ))
Прикольно, опять защитники микрософта набежали 
Я и не заметил.
не понял, о чём речь. Если ошибки и так есть (а их не быть не может), то при чём тут оптимизация?
Ну положим мои ошибки, и что? Для чего вся эта система? Чтобы показать пользователю что он неправильно делает! А не глючить, да ещё на собственно системой назначенные имена объектов, например на имена кнопок, говорить что они ошибочны! И привести вам пример глюков в excele когда ставили 2013 Office, правда через две недели майкрософт исправил! Так что…
ИИ Студии предпримет попытку исправления криворукости… Но он не всегда адекватно оптимизирует.
Всегда провожу тестовую сборку при -0 параметре оптимизации. Помогает найти ошибки не кода а в алгоритме.
P. S.
Иногда релиз при -1 уровень оптимизации.
Отладка только при -0 уровне.
P. P. S.
Проблема заключается в том что даже официальные пресс аташе от разработчиков студии не смогут дать конкретный ответ на вопрос: что именно оптимизируется?
А при “0” оптимизации получаем ошибки компилятора и ни чего более.
Дык тут проблема была еще до сборки в дизайнере формы )
Так потому и акцентировал внимание на оптимизации.
Писалось то: при отладке все ОК. Вопрос: уровень оптимизации отладчика?
Тогда как можно быть уверенным в том, что вообще хоть что-то оптимизируется?
Что-то однозначно оптимизируется.
Проверить есть возможность.
Собрать код при “0” оптимизации – смотрим размер выходного файла.
Собрать при “3” уровне оптимизации – смотрим размер.
Чем выше уровень оптимизации – тем больше размер выходного файла.
ИМХО. Для отладочных версий использую 0 оптимизацию, для релизов иногда 1-ый уровень, это если код не с идеальной структурой.
А я думал, что чем меньше ЕХЕ-файл, тем быстрее работает 
Потому что кода на выполнение тупо меньше. Конечно же, при условии, что код написан правильно.
Неа, обратная взаимосвязь.
Чем кривее код и чем выше уровень оптимизации компилятора – тем больше размер исполнителя.