Visual Studio 15 SP 1
Ты себе не представляешь, сколько раз за последние 15 лет писали именно это (неверное, просто из-за отсутствия информации):
Ну давай попробуем прикинуть...
домашняя рабочаяя машинка - могу поставить как мне надо - тут без проблем, даже есть кирилическая клава.
работа...
стандартно сконфигурированная машина... обычная английская клава...
поменять - можно, но нужно спрашивать... а оно мне нужно?
в паре-тройке мест захожу в библиотеку - там хоть спрашивай, хоть не спрашивай поменять ничего нельзя...
частенько бываю в гостях - поменять можно, но после этого придется отвечать за систему... даже если поменять обратно...
есть и еще варианты...
Вопрос
- что будет правильнее - бегать по всем местам и уговаривать сделать
как мне надо или все же наплевать на все и писать транслитом?
Правильно - надо пинать разработчика на предмет починки транслита
на сайте. И точка.
Главное - а что, на таких, чужих машинах, люди только на данном сайте пишут??? А если им надо письмо отправить? Или на другом сайте поучаствовать в обсуждении, а там нет кнопки Транслит или она совсем по-другому работает? Поэтому - на большинстве форумов (и на данном сайте тоже - в компьютерном форуме) обычно рекомендуют всё же современный подход (мы говорим о тех, кто не знает русской раскладки и пишет в режиме латинской клавиатуры - F-Ф,А-А,G-Г,...) - более логичный:
дома мало кто из таких людей будет - в 2016 году - для ввода кириллицы в
почте или где ещё специально заходить на форум (и потом копировать), сражаясь с исключениями Транслита (ставя пробелы а потом убирая, чтобы например vyuchil не дало "вючил") - это был подход времен Windows 95, когда сами системы не позволяли вводить в режиме F-Ф,А-А,G-Г,... Последние лет 12-14 (начиная с Windows XP) такие люди вводят русский обычным образом (как вводят немецкие или чешские или... тексты) - с системной клавиатурой, просто раскладка - фонетическая (уже есть в поставке Макинтошей, а под Windows ставится одним щелчком штатно, средствами Микрософта, не то, что в 1998 году, где надо было использовать "ухищрения русских программистов"). Если интересны детали про данный подход: http://zabl.winrus.com
А тогда встаёт вопрос - зачем же вне дома вводить не так, как дома?
Ведь логичнее (и проще) одинаково вводить на своём компьютере и на чужом.
Поэтому появились сайты, где - для ситуации "ЧУЖОЙ компьютер" - эмулируется именно "домашний" ввод с фонетической раскладкой, то есть, сел в отеле в Ницце за их (французскую) клавиатуру,
и вводишь сразу, привычно, как дома. Это сайты современных Виртуальных Клавиатур, где ввод не мышкой, а с физической клавиатуры, например (можно выбрать свою Фонетическую раскладку в меню, привычную, "домашнюю"):
- раздел "Русская Клавиатура" (там и Фонетические есть) на http://translit.ru
- специализированная страница (разные Фонетические, на выбор) - http://porusski.net
:-)
Все эти вопросы десятки раз обсуждались за последние 10 лет на компьютерном форуме данного сайта. И уже давно всем, кто хочет вводить в режиме латинской клавиатуры (F-Ф,А-А,...) там предлагают обычный, системный ввод (с фонетической раскладкой), а не перекодировщики транслита. Даже в FAQ компьютерного форума это внесено.
Потому что перекодировщики транслита - устаревший метод (да ещё с проблемами типа "rajon"--"раён" и т.п.) и не логичный - зачем же посторонние средства, раз сейчас сами системы (Windows, Mac) предлагают такой ввод, в режиме F-Ф,А-А,...?
кто не знает русской раскладки
-----
Они не знают не только русской раскладки, но и не подозревают что существуют языки, отличные от того, которым они пользуются.
сколько раз
------
Меня очень мало интересует сколько раз. Меня интересует, чтобы зайдя на сайт на котором заявлено двуязычное общение у меня не возникало проблемы написать текст на выбранном языке. Неважно откуда Я зайду и какая конфигурация у системы.
просто раскладка - фонетическая
-----
Приезжай - зайдешь в библиотеку и попросишь поставить тебе раскладку.
Ну или сходи в гости и поменяй конфигурацию на компе англика и обьясни ему надо делать чтобы вбить пароль для банка в програмке которая автоматически переключается на транслит...
Или ты
действительно не понимаешь сути проблемы, или прикидываешься...
В любом случае - топик для обсуждения ньюансов новой версии Висуал Студио, а не местного гемороя...
Ты не стал читать мой ответ (а ведь он такой же, как и в здешнем компьютерном форуме раз за разом новичкам отвечают уже лет 10):
Приезжай - зайдешь в библиотеку и попросишь поставить тебе раскладку.
Прочти всё же - в библиотеке или в бизнес-центре отеля в Ницце не надо ничего ставить, чтобы вводить точно как дома, привычно.
НП.
Переставил систему и поставил новую Студию.
Выглядит так, что чем дальше тем хуже.
1. Скачанная в Декабре Студия на голую систему Вин7 СП1 - не встала. Почему - не знаю, не смотрел. Скачал еще 7 гиг - эта поставилась.
2. В процессе установки получил кучу сбоев при выборе полноюстановки. Работает без сбоев только установка по умолчанию и последующий апдейт на полную.
3. После полной установки в референсах на .Нет имелось по две ссылки на каждую либу. Починилось, как ни странно, установкой ИИС 10.
4. После полной устрановки остался так и не инсталированным SqlLocalDB. На машине, тем не мение, имеется соответствующий мсй и он ставится без проблем.
5. Скачал и проинсталил русские ресурсы для студии. Встало все с полутыка... правда вся студия так и осталась на английском.
6. в редакторе не работают горячие клавиши комментирования-де-комметирования блоков. Через меню - работает.
7. в студии не получается получить диаграмку классов - ни кнопками, ни через меню.
7.а. Редактирование текста представляет цирк с конями - в зависимости от предистории в последние 5-6 нажатий автокомплете может работать совершенно по-разному.
8. Где-то что-то отличается в дефаултовых ключах компиляторов - мой вб.нет сайт так и не компилируется - ошибки там где не ожидаю. в настоящее время - потрял предкомпилированную мастер-паге.
9. вб.нет работает весьма отлично от предыдущей версии, в шрапе - получше.
10. для сравнения версий файлов конфигурации (хмл) системы взял XmlDiff от мелкомягких. На стандартном конфигурационном файлике он свалился - не умеет обрабатывать аттрибыт со значением "один пробел". Это починил, но следующее поставило в тупик - они пишит свой дифф-файл в хмл и затем используют его для разметки исходных файлов... так в разметчике они не в состоянии обработать свой файл - не проходит каст смезхных типов... писсец...
Пока вроде все.
По ощущениям - надо будет все сносить, ставить систему, конфигурить ИИС, СКЛ, ЛокалДБ, ОДАК, все .Неты и только потом ставить Студию.
Нашел еще один геморой.
Первая библиотека First.dll, класс TMyRow, поле объявленное как protected internal DataRow dr;
Так же разрешен доступ к интернал - [assembly: InternalsVisibleTo("Second.dll")] для второй либы.
Вторая (Second.dll) библиотека:
TMyRow mr = new TMyRow();
mr.dr = table.NewRow();
mr.dr - Error CS0122 'Row.dr' is inaccessible due to its protection level
В 12-й Студии - вроде работало... ну по крайней мере в доках прописано что так должно работать.
Может кто потестить - меня в очередной раз поглючило или реальный глюк Студии?
Еще один глюк Студии 2015... хотя, возможно и мой...
На используемом в компании веб-сайте написана кучка репортов.
Написано - ужасно - все в одном - создание представлений таблиц, бизнес-логика, управление контролами - один файл.
Когда пришлось что-то чинить - порезал на более-мение приемлемые классы, классы сложил на том же сайте в подпапочке в App_Code. В проектах построения DLLok (проекты лежат отдельно, вне сайта) используются линки на файлы. Все более-мение работало.
Единственное - но - у прежнего прогера не было SVNa и он плодил копии и зиппы...
Когда начали регулярно наваливать редакции репортов, а багов там несчесть, перетащил рабочую копию к себе и положил ее в SVN. Там она и живет - была уже куча редакций, включая полное стирание и взятие последней копии.
Переполз на новую Студию. Диск с проектами получил другую буковку... надо было бы еще из My Documents вытащить, но поленился. Надо будет все же сделать...
Вчера выполнил очередную редакцию DAL - упростил код до безобразия и подредактировал базирующиеся на нем DLLки. Все должно было бы работать. Но это же биллина поделка - одна из DLLок, после смены буковки диска, была построена из старого кода... мало того - редактирование кода так же меняло старый код.
Вот такой глюк...
Нашел два момента которые весьма-весьма неожиданны... для меня.
1. Если в проекте какой-то DLL используются шаблоны Т4, то каждый шаблон компилируется в отдельную дополнительную DLL.
Мило так - скомпилировал проект, перекинул пост-скриптом полученный файлик в нужное место... и получил облом...
Где отключить - пока не смотрел.
2. Веселости в настройке ИИС. Теперь имеется множество applicationhost.config (см .vs/config). Каждый веб-проект имеет свою запись в этом файлике. Напомню - файликов плодится много.
Все бы ничего, но туда прописываются постоянные ссылки (полные пути) на местоположение кода и если есть желание все почистить перенеся в другое место - начинаются пляски с бубном - добавлять туда инфо Студия умеет, а вот удалять или изменять, похоже, никак...
Ну а результат малейшего несоответствия записей в солюшнике и конфиге - некомпилируемый проект.
Еще одна фича.
Как большинство прогеров знает, в вебе уже давно отходят от прописывания Style в теле HTML-документа в пользу Class и включения соответствующего CSS.
Но не у билли. У билли все по-прежнему - Style и меняем его... а что там в CSS прогер определил - не важно.
.Net шуршит уже почти три пятилетки, а простейшую работу - сбросить содержимое Style в CSS и включить ссылку в страницу - так и не осилили... 
1. Если в проекте какой-то DLL используются шаблоны Т4
------
Был не совсем прав.
Правильнее будет так:
- в какие-то моменты времени Студия создает указанные маленькие DLLки, видимо для своих внутренних нужд.
- в результирующую DLL проекта классы шаблонов все же включаются.
Захотелось мне локально хостить NuGet'ы по собстренным билдам.
Пришлось ставить Azure.
Ставить в двух комбинациях - для 2010/13 и для 2015.
После установки начались... фокусы.
1. запущенное из Студии выполнение странички... у меня "простые", без MVC наворотов... не терминируются ни при закрытии браузера (ну это Я могу понять), ни при Stop Debugging в Студии (этого Я уже не понимаю)...
2. время ожидания загрузки страницы существенно возросло. Существенно - между кликом Старт и отрисовкой страницы проходит до 5 минут. Большую часть этого времени ничего не происходит - процессор 0%, память - стабильна по обьему. Возможно связано с загрузкой отладочной информации по мелкософтовским сборкам.
3. клики по кнопкам происходят... дважды... т.е. запускаем страничку, дожидаемся пока нарисуется в браузере, аккуратно ОДИН раз кликаем кнопу... отслеживается вход в обработчик... ожидается окончание выполнения... делается отметка об окончании - делаю лейблочку видимой... лейблочка на страничке не показывается, а вместо этого происходит повторный вход в обработчик нажатия конопы... После второго выхода из обработчика лейблочка уже отображается...
4. В дополнение к предыдущим - отвалился Oracle.DataAccess... видимо надо думать над переходом на Oracle.ManagetDataAccess...
На 7-ке assembly складываются в 3 папки:
GAC_32
GAC_64
GAC_MSIL
IIS ищет в пяти, но не ищет в GAC_32... вместо него пользуется просто GAC.
На понедельник:
- проверить апп.пулл на IIS - может где-то надо указать 32 бита...
- удалить добавленную папку GAC - все одно не работает
- попробовать сослаться на Oracle.ManagetDataAccess и добавить ссылку на него в предопределенные.
5. IIS Manager - это полная задница - сохраняет данные до того как нажата кнопа Save...
Кроме этого, при создании нового пула создает юзера для этого пула, но не дает права на папки куда аппликациям пула необходим доступ...
По поводу 3. - onclick & With Event - указанные одновременно дают второй вызов обработчика.
По поводу 4. - ошибка вызывалась неправильной записью в системном web.config для Framework64. Почему не проверялась - GAC_32 - не выяснил, мелкомягкие тоже не в курсе...
Еще несколько проблем:
- при разрешенной загрузке .Нетовских *.PDB (ну надо мне кое-что смотреть там) собственные (т.е. для сборок в проекте) *.PDB ищутся на том же мелкософтовском сервере. Получается - дольше чем ожидается...
- при наличии нового солюшника (т.е. там где нет папочки .vs) происходит загрузка *.PDB даже если они лежат в общем кеше,,, Что мне тут не понятно - нафига это делать? Понятно ведь, что если работают с таким режимом отладки, то это не какой-нибудь юзер, а разработчик - почему бы не положить *.PDB рядом с *.DLL в GAC и больше об этом не волноваться?
- зверски надоело добавлять в проекты теряемые Студией референсы. Как только проект перемещается, а у меня это довольно часто, ссылка на него становится невалидной. Починить ее, средствами Студии у меня не получилось (руками в солюшнике могу), а при удалении проекта все ссылки удаляются. Добавление, разумеется, их на место не возвращает... хотя ДЛЛка лежит там где должна... неудобно...
Еще один моментик - тестирование.
В Community версии Студии 2015 отсутствует целая куча DLL связанных с тестированием.
В частности - ЛоадТестс & ВебТестс...
У кого есть статрые инсталяции - в частности полная Студия 2010 - там их есть.
Знаю, что будут работать в кучке (все от Студии 2010), но не тестил на смеси 2010/2015.
Это не сама студия, но тесно связанная штука... причем из старых...
Задача - дописать в ХМЛ-файл (во фрагмент данных) очередную порцию данных.
Решается - элементарно:
using(StreamWriter sw = File.AppendText(filename.DataFilename))
using(XmlWriter xmlDataWriter = XmlWriter.Create(sw, xws))
{
// работаем по добавлению данных
}
Код получился не слишком красивым и повторять его каждый раз не хочется - убираем создание XmlWrite в какой-нибудь класс и пишем:
using(XmlWriter xmlDataWriter = filename.XmlDataWriter)
{
// работаем по добавлению данных
}
XmlDataWriter имплементируем как:
XmlWriter xmlDataWriter = null;
public XmlWriter XmlDataWriter
{
get
{
if (xmlDataWriter == null || xmlDataWriter.WriteState == WriteState.Closed)
{
XmlWriterSettings xws = new XmlWriterSettings();
xws.ConformanceLevel = ConformanceLevel.Fragment;
xws.Indent = false;
xws.NewLineHandling = NewLineHandling.None;
xws.OmitXmlDeclaration = true;
xmlDataWriter = XmlWriter.Create(File.AppendText(filename.DataFilename), xws);
}
return xmlDataWriter;
}
}
Тестим - все работает...
Теперь пишем два раза подряд :
using(XmlWriter xmlDataWriter = filename.XmlDataWriter)
{
// работаем по добавлению данных
}
using(XmlWriter xmlDataWriter = filename.XmlDataWriter)
{
// работаем по добавлению данных
}
И имеем... облом... на втором открытии... да-да, несмотря на using и тот факт что XmlWriter закрыт... и файл - тоже закрыт...
