Visual Studio 15 SP 1
Кто-то смотрел что там добавилось?
Из того, что Я знаю, туда впихнули <VS SDK>. Но это точно не 3 Гига...
И еще вопросик - Починил билли <OneClick deployment> или как обычно обещает?
Чистый Update 1 "весит" почти 4 Гб. Разбираться, что же там нового не было времени, поскольку этот монстр все время устанаваливался криво, выдавая ошибки то при обновлениии системы, то при установке КВ с каким-нибудь номером. При этом все настройки становились в позу. После пятой попытки, когда все вроде как стало "как раньше", мне было уже не до разглядывания новшеств,
не смотрел, но ссылок полно
http://habrahabr.ru/company/microsoft/blog/263217/
https://msdn.microsoft.com/ru-ru/library/bb386063....
Как будет третий апдейт может и перейдём.
П.С. Когда же они найдут того, кто в состоянии починить транслит...
Многие вообще ушли от этого метода - он ведь во времена Windows 95 был придуман, устарел.
Если интересно, вот современный подход к подобному вводу (когда F-Ф,А-А,...):
http://foren.germany.ru/showmessage.pl?Number=...
:-)
Многие вообще ушли от этого метода - он ведь во времена Windows 95 был придуман, устарел.
Я даже боюсь вам рассказывать когда появился ISO 9 :)
Если метод из 95-го года "устарел" то что же с 54-м годом делать...
P.S. Для "компьютерщика" KOI8-R с его "автоматической транслитерацией" ближе. Но и тут даже RFC уже к 93-му (или 92-му?) написали. А разработали его аж в 70-х.
В Интернете всё очень быстро развивается (не сравнить с такими бюрократическими вещами, как ISO) - 12-14 лет это, по меркам Интернета, целая эпоха.
Это моя специальность (аж с 1997 года) - "языки в Интернете, операционных системах, программах", поэтому-то я и в курсе. Например - действительно целая эпоха! -
в 1999-2001 г.г. (Windows 3.1/95/98/ME) было очень-очень трудно, а для не-компьютерщиков часто невозможно, работать с японским, русским,... И в Интернете, и в программах. Это тогда были отдельные кодировки, та же KOI8-R.
Но вскоре - распространение Unicode и новые операционные системы привели к тому, что поддержка языков стала очень хорошей и лёгкой - даже такие совсем далёкие от технологий люди, как русскоязычные няни :-) в Италии (italia-ru.com/forum) без труда и напряга пишут кириллицей, не
имея русской клавиатуры (не заходя ни на какие сайты, а именно с современным методом фонетической раскладки) -
это же невозможно было даже представить в 1999 году!
Понимаете?
без труда и напряга пишут кириллицей
-----
Ну давай попробуем прикинуть...
домашняя рабочаяя машинка - могу поставить как мне надо - тут без проблем, даже есть кирилическая клава.
работа... стандартно сконфигурированная машина... обычная английская клава... поменять - можно, но нужно спрашивать... а оно мне нужно?
в паре-тройке мест захожу в библиотеку - там хоть спрашивай, хоть не спрашивай поменять ничего нельзя...
частенько бываю в гостях - поменять можно, но после этого придется отвечать за систему... даже если поменять обратно...
есть и еще варианты...
Вопрос - что будет правильнее - бегать по всем местам и уговаривать сделать как мне надо или все же наплевать на все и писать транслитом?
Правильно - надо пинать разработчика на предмет починки транслита на сайте. И точка.
Про ISO 9 был вам тонкий намек что ваше высказывание
он ведь во времена Windows 95 был придуман
неверно.
Это моя специальность (аж с 1997 года) - "языки в Интернете, операционных системах, программах", поэтому-то я и в курсе.
В смысле "специальность"? Вы получили высшее образование по специальности "языки в Интернете, операционных системах, программах"?
в 1999-2001 г.г. (Windows 3.1/95/98/ME) было очень-очень трудно, а для
не-компьютерщиков часто невозможно, работать с японским, русским,... И в
Интернете, и в программах. Это тогда были отдельные кодировки, та же
KOI8-R
А также NT4/2000/XP. И куча более других операционных систем. Бедные японцы и не в курсе что им было невозможно работать с японским... А уж как с русским в 99-м году было сложно работать и представить невозможно :) Как
я только в 94-м на виндувс 3.1 в write русский текст набирал... Плакал, стирал пальцы до костей, но продолжал нажимать на кнопки клавиатуры... А про русский ms-dos 4.1 вааще - аж вспомнит страшно.
Но вскоре - распространение Unicode
Мнэ. В смысле микроштофф проснулась и заметила что все вокруг используют юникод и только в их операционках с ним невозможно работать (хотя оно и сейчас в консоли того-с)? Так-то юникод с 93-го года. А после 2-й версии (96 или 97?) действительно стал быстро распространятся.
а именно с современным методом фонетической раскладки
это же невозможно было даже представить в 1999 году!
Понимаете?
Не-а, не понимаю. Фонетическую раскладку я себе отлично представляю года так с... 89-го. Знаете такой комплекс Yamaha MSX? У многих русской клавиатуры не было, а бедные школьники для набора русского текста пользовались... (только никому!) фонетической раскладкой.
Фонетическую раскладку я настраивал себе в немецком универе в учебном классе на солярисе, дома на 98-х виндусях и линуксе в 98-м. Инструкции по установке фонетической раскладки на виндуся были доступны в интернете на, с 97-го года 100%, может и раньше.
И у меня один вопрос, а что, в KOI8, cp866, win1251 или в iso-8859-5 с фонетической раскладкой печатать не получится, обязательно юникод нужен?
Специальность в смысле "рабочая специальность", а не в плане образования. Называется "software globalization" :-)
Мы же на форуме в Германии, поэтому все мои высказывания были, во-первых, про нерусифицированные компьютеры, и во-вторых, и это главное, про не-компьютерщиков (это ведь они кнопкой Транслит пользуются), которым таки до появлeния Windows XP было трудно с языками на компьютерах. Такие пользователи не только на Солярисе, но и на Windows редко могли русский настроить - знаю, общался много в те годы (я кстати был вроде первым, кто придумал, как писать кириллицей в Netscape версии 0.9, потом в 1.0 и потом в 2.0 
- даже в фирму Netscape приглашали тогда на их совещания в группе i18n)
Так вот, для них, для "конечных
пользователей", перекодировщики транслита были предложены во времена Windows 95 - на форумах появились кнопки Транслит, возникли сайты типа translit.ru
"Инструкции по установке фонетической раскладки на виндуся были доступны в интернете на, с 97-го года 100%, может и раньше."
Даже раньше (в том числе моя), но я же про тех, кто кнопкой Транслит пользуется - для них те инструкции были сложноваты.
Ты себе не представляешь, сколько раз за последние 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 закрыт... и файл - тоже закрыт...
Очередной моментик в Студии...
Пользую шаблоны Т4... не все устраивает, но - работает... по крайней мере это выглядит проще, чем сборка sql-строки в коде метода...
Моментик об котором хочу написать следующий:
- у Студии, в свойствах файла, есть метод (Build Action) обработки соответствующего файла - от ничего до включения ресурсом.
- шаблоны Т4, по умолчанию, включаются как ресурс.
- генетируемый Студией на основе шаблона класс - нормально компилируется.
Потребовалось мне несколько шаблонов исключить из билда. Привычно поставил свойства шаблона в "none" и ожидал, что генерируемый файлик будет исключен из компиляции.
Не сработало!
Т.е. шаблон лежит в проекте с указанием ничего с ним не делать, а сгенерированный (генерируется при сохранении) на его основе (*.cs) файлик - продолжает компилироваться как ни в чем не бывало...
Еще моментик - после возвращения шаблона в обычный (ресурс) режим оказалось, что пропал установленный Custom Tools Namespace. Это не перепроверял, но споткнулся об отсутствие подставляемых параметров в тех шаблонах, которые переводил в "none".
Нашел еще одну веселую штучку. (пишу руками - могут быть ошибки)
interface IFilename
{
String RootPath { get; set; }
String Basename { get; set; }
}
public abstract partial class TBase : IFilename
{
public void Generate()
{
String filename = TFileManager.BuildFilename(this);
....
}
....
String IFilename.RootPath { get; set; }
String IFilename.Basename { get; set; }
}
class MyTemplate : TBase, IFilename
{
public MyTemplate()
{
RootPath = @"c:\_Generated";
Basename = @"MyDoc.dat";
}
String RootPath { get; set; }
String Basename { get; set; }
}
public static class TFileManager
{
public static String BuildFilename(IFilename pFilename)
{
....
}
}
Как помнится, утверждалось, что при наличии двух определений интерфейсов в конечную реализацию входит последняя.
В данном случае последняя реализация находится в классе MyTemplate - там где происходит декларирование полей и присвоение значений.
Однако при кастинге в передаче параметра - в TFileManager.BuildFilename(this); - эта имплементация не используется, а получается первичная из TBase. А там, естественно, все нулл-нулл.
То, что поправить не сложно - понятно, но все же Я получил доступ к не последней реализации интерфейса...
Еще один глюк Студии.
Сейчас вышел SP2. Довольно объемная штучка.
В процессе исталяции можно много чего поменять в настройках.
У меня, в частности, нет необходимости в Win10 SDK.
Глюк в том. что, не смотря на снятие галочки, данный SDK все одно ставится...
Остальное - не отслеживал, но, думаю, что мои настройки почти полностью игнорируются.
Да, кто там бился за Pyton'а? Добавили его для комплекта...
Добавил пару толоозок для работы с шаблонами - 'T4Toolbox' & 'tangible T4'.
По ощущениям - стало существенно медленнее. Особенно чувствуется на загрузке.
У меня SSD и в обычном варианте все летает. Сейчас, при загрузке, весьма тяжко.
Есть и положительные изменения - появилась подсветка синтаксиса в шаблонах
и возможность работать с параметрами в Свойствах. От последнего толку пока
мало - шаблоны получают параметры из сессии, которая лежит в АппХосте и
которую Я на сейчас не использую. генерируемый для параметров код так же
привязан к использованию АппХоста... но тут его можно подменить.
Слепил псевдосессию и передал через нее параметры. Код стал выглядеть/...
хммм... интересно:
TParams param = Load(fi); // загрузка файла с определениями
// установка параметров
TExecutionContext.Instance[Primitive.TNamespaceDefinition.ID] = param.NamespaceDef;
TExecutionContext.Instance[Primitive.TClassDefinition.ID] = param.ClassDef;
//TExecutionContext.Instance[Primitive.TFieldsList.ID] = param.Fields;
TExecutionContext.Instance["Fields"] = param.Fields; // передача - по имени переменной
// инициализация параметров в ДЛЛке
Code.Templates.Base.TBase.ExecutionContext = TExecutionContext.Instance;
Code.Templates.Base.TBase.FileManager = new Code.FileManager.TFileManager();
// генерация - осталось 2 строки на шаблон
TFieldNames fn = new TFieldNames();
//fn.Namespace = param.NamespaceDef;
//fn.Class = param.ClassDef;
//fn.Fields = param.Fields;
fn.Generate();
//generated = fn.TransformText();
//filename = GenerationPath + param.ClassDef.Name + ".FieldNames.cs";
//File.Delete(filename);
//File.AppendAllText(filename, generated);
TRow row = new TRow();
//row.Namespace = param.NamespaceDef;
//row.Class = param.ClassDef;
//row.Fields = param.Fields;
row.Generate();
//generated = row.TransformText();
//filename = GenerationPath + param.ClassDef.Name + ".Row.cs";
//File.Delete(filename);
//File.AppendAllText(filename, generated);
TSubset ss = new TSubset();
//ss.Namespace = param.NamespaceDef;
//ss.Class = param.ClassDef;
//ss.Fields = param.Fields;
ss.Generate();
//generated = ss.TransformText();
//filename = GenerationPath + param.ClassDef.Name + ".Subset.cs";
//File.Delete(filename);
//File.AppendAllText(filename, generated);
TTable tb = new TTable();
//tb.Namespace = param.NamespaceDef;
//tb.Class = param.ClassDef;
//tb.Fields = param.Fields;
tb.Generate();
//generated = tb.TransformText();
//filename = GenerationPath + param.ClassDef.Name + ".Table.cs";
//File.Delete(filename);
//File.AppendAllText(filename, generated);
Но надо дорабатывать - активно использую подшаблоны - туда еще не передаются параметры.
Проблем две - надо научится из конструктора получать ссылку на переменную (ссылку на файл
куда добавлйать текст) с классе которой создается подшаблон и подумать как, через сессию,
передавать параметры при паралельном выполнении кода... НУ да это не сегодня...
P.S. Кто бы мне сказал где поменять код генерируемый для шаблона и параметров... Где
компилятор шаблонов - Я заню, вопрос в том как поменять его выдачу... 
Я себе эту штуку установила только потому что там больше готовых "форлагов" для разных проэктов. И именно одно форлаге нужно было для моего проэкта. В остальное я пока не вникала, ибо сама в этом деле - новичек... Мне темы надо одну за другой изучать
Da Ja tozhe ne lezu shibko vpered - 4.0 v samyj raz.
да вы прикалываетесь
в C# наконец-то ввели то, что во всяких пыхпыхах существует 100500 лет
вместо
name = string.Format("Employee name is {0}, located at {1}", emp.FirstName, emp.Location); можно писать
name = $"Employee name is {emp.FirstName}, located at {emp.Location}";раньше везде где-нибудь с нумерацией {x} напаришься, вылзит IndexNotBoundException
вместо
string departmentName = emp == null ? null : emp.Department == null ? null : emp.Department.Name;Теперь:
string departmentName = emp?.Department?.Name;Неужели так проблемно написать:
name = "Employee name is " + emp.FirstName + ", located at " + emp.Location;
да и работает (вроде) быстрее.
Ну это безотносительно к тому, что в данном случае все форматирование должно быть пропертью/методом объекта emp.
Меня форматирование строк вообще как-то не сильно заботит - для малых объемов - конкатенации достаточно, для больших - есть текстовые шаблоны. Вот сравнение - да, интересует - в плане быстродействия - в три раза по сравнению со стандартным Я поднял, но мало, надо еще разика в три...
Интереснее начинается, когда тебе нужно вытащить время из даты или дробную часть из числа там.
-----
Да ну? Может стоит работу поменять? Ну или инструмент немного подосвоить?
пишут, что конкатенирование это Айайай
-----
Ну пишут и что? Если совсем критично - есть StringBuilder.
Но еще раз повторюсь - у меня нет проблемы с форматированием строки - иногда эта операция не встречается и на 10-ке страниц...
NP.
public class A
{
String _name;
protected A(String pName) { name = pName; }
}
public class B : A
{
protected B(string pName) : base(pName) {}
До этого момента все ясно и понятно
- два класса с защищенными конструкторами - не будут лепится как попало
- один наследуется от другого и может получить доступ к конструктору базового.
public static readonly A Inst = new A("The Name");
}
А вот последняя строка поставила меня в тупик.
Планировалось, что будет вызван конструктор (как любой protected method) базового класса.
Получился, однако, облом - нет доступа к защищенному(!) конструктору... в наследнике.
Что Я там немножко нарушаю парадигму ООП - это понятно.
Просто у меня B очень частный случай А и Я хочу иметь его в топе иерархии.
Ткните, плс, Кота носом в доку, где описано почему недоступен конструктор...
П.С. Поправить - проблемы нет. Хочу понять почему есть ограничение.
Всё элементарно.
Спецификация C# 5.0, §3.4:
all members of the base class, except instance constructors, destructors and static constructors, become members of the derived type
+ §3.5.4
Let B be a base class that declares a protected instance member M, and let D be a class that derives from B. Within the class-body of D, access to M can take one of the following forms:• An unqualified type-name or primary-expression of the form M.• A primary-expression of the form E.M, provided the type of E is T or a class derived from T, where T is the class type D, or a class type constructed from D• A primary-expression of the form base.M.In addition to these forms of access, a derived class can access a protected instance constructor of a base class in a constructor-initializer.
Расшифровывая:
- protected конструктор базового класса не наследуется (отсутствует в наследнике)
- по форме B() из D вызвать нельзя, т.к. такой член в наследнике отсутствует
- по форме E.B() вызвать тоже нельзя, потому что E может быть либо D (что не работает, ибо см. предыдущий пункт), либо наследником D, что также не работает по предыдущим 2 пунктам
- по форме base.B() вызвать тоже нельзя, потому что base.-доступ разрешается только в нестатическом конструкторе, нестатическом методе или нестатическом акцессоре (§7.6.8)
Доступ к protected конструктору базового класса доступен только в инициализаторе нестатического конструктора наследника, что выделено как отдельный пункт в §3.5.4, см выше.
Удалось найти еще один глюк...
Вчера к обеду рубанули электричество... большая часть сделанной за утро работы сохранилась в рековери файлах... что радует...
Однако, без проблем не обошлось.
Найденная проблема - сбросился тип процессора установленный для откладки.
Что огорчает - непонятно как это происходит - Студия до этого выгружалась и загружалась - все было нормально... видимо что-то в процессе восстановления переписывает настройки...
Нашел еще один глюк.
Исходная диспозиция:
- открыто несколько студий
- в студиях открыты разные проекты
- один из проектов - WEB-из-папки
- в WEB-из-папки используется условная компиляция в нескольких страницах (описывал где-то ранее - Global_asax vs Application)
Глюк заключается в том, что если отсутствует хотя бы один из дизайнерских (*,design.vb/*.design.cs), то условная компиляция работает не как определено условиями. Причем результаты условной компиляции становятся непредсказуемыми - где-то правильно, а где-то - как случится. При наличии дизайнерского файла, пусть даже в нем есть ошибки, все выправляется...
Очередные глюки...
Глюк достаточно странный, связан с файлом проекта.
У меня настраиваются три конфигурации: Release, Debug, Tests
Понятно, что по дефаулту их две и третью надо дописывать руками.
За одно с добавлением конфигурации заменяются и пути сброса Длльок.
Рутина.
Глюк первый.
Если не сохранить файл проекта - Студия предложит его сохранить - это нормально,
но после этого Менеджер Конфигураций не видит добавленную конфигурацию, хотя
она есть в файле проекта.
Глюк второй.
При последовательно производится редактирование нескольких файлов проектов.
Если в Менеджере Конфигураций не выбирать нужную конфигурацию, то в какой-то
момент может оказаться, что изменения утрачены. Как - не отследил пока...
Очередной глюк... хотя скорее фича...
Две Студии, куча проектов в каждой. Часть проектов - общие, т.е. открыты в обоих Студиях.
При редактировании и сохранении все отрабатывает нормально - в второй Студии переспрашивается
надо ли загрузить изменения.
При удалении файлика из проекта (в моем случае - шаблончик Т4), вторая Студия ничего не спрашивала,
но вылетела на компиляции по отсутствующему файлу.
Очередная проблема в Студии.
Сгенерил Я свою задачку в полном - 900+ исходных таблиц - объеме и со всеми ошибками. Затраты по времени - порядка 20 секунд.
Первый прикид - часть кода неправильная, часть ссылок на другие ДЛЛ отсутствует, часть указанных файлов отсутствует - не беда, буду чинить.
Открыл солюшник в Студии.
В нем два проекта.
Объем кода - 12х900+... ну плюс/минус...
Уже почти час Студия валидирует состав проектов и пишет в Оутпут об отсутствующих файлах... ЧАС!!!
Попутно - открыть что либо в Студии невозможно - подвисает...
Глюк в шаблонах Т4
Имею в шаблоне для генерации файла проекта следующий код:
<Compile Include="<#= Table.Name #>\\SQL\\<#= LastGeneratedName #>">
Ожидается построение ссылки на сгенерированный шаблон. Кто не знает - добавьте шаблон в проект, выгрузите проект и посмотрите что там прописалось.
Т.е. ожидается что будет сгенерировано что-то такое:
<Compile Include="MyTable\SQL\Update_Row.cs">
Двойные бакслеши используются т.к. текст "\\SQL\\"
должен трансформироваться в this.Write("\\SQL\\");
но по факту он трансформируется в this.Write("\\\\SQL\\");
Т.е. первый двойной - удваивается, а второй - остается без изменений.
Чинится следующей заменой:
<Compile Include="<#= Table.Name #><#= @"\SQL\" #><#= LastGeneratedName #>">
Нашел еще пару баго-фичь в Студии (СП2).
Первая. Студия не понимает ссылки на линкованные (адд ас линк) файлы используемые в проекте. Неприятно, но не смертельно.
Вторая. При добавлении группы файлов в проект возможна ошибка добавления (в моем случае Я добавлял линк на файл который уже был в папке). В этом случае добавление не откатывается, а остается частично завершенным - что добавилось до ошибки - остается, остальное - не добавляется.
В выходные апгрейдился на СП3 на домашнем лапте... Это полный звизденец... вместе с самыми необходимыми апдейтами системы процедура заняла около 5 часов... Трафик - не считал, но с мобильного - очень не рекомендую...
Процесс выявил слабое место у лаптя - диск. там была 100% (согласно ТаскМанагеру) загрузка диска, но суммарнайa (реад&врите) скорость не превышала 10 Мбипс... Нужен террабайтный ССД... Я тут подумал... возможно, что сделав бекап и ресторе на СДД "старой" системы, затем ее проапгрейдить и тем же путем - бекап и ресторе на обычный диск оно будет быстрее...
Можно конечно.
Открываем студию и идем сюда C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\TextTemplating
Добавляем все что там есть - 2 ДЛЛ и один Таргетс - как линки к проекту.
Теперь выгружаем проект и дописываем Импорт для Таргетса, который добавлен как линк.
Результат - импортируемый Tаргетс не резолвится... пока не сделаешь локальную копию файлов...
Не слишком заморочно описал?
NP.
Очердной сюрприз от билли...
Код:
DirectoryInfo dInfo = new DirectoryInfo(Path.Combine(Environment.CurrentDirectory, "Clients"));FileInfo[] files = dInfo.GetFiles("*.dll");
помещает в филес то, что соответствует "*.dll[red]*[/red]".
Попал на это случайно - поменял один из интерфейсов, либу не перекомпилировал, а переименовал как "*.dll_". Ну а билли ее поднял как живую... и подох, мудак, на загрузке.
А попасть на описание - не суждено было?
"*.abc" returns files having an extension of.abc,.abcd,.abcde,.abcdef, and so on.
https://msdn.microsoft.com/en-us/library/8he88b63(v=vs.110...
https://msdn.microsoft.com/en-us/library/ms143327(v=vs.110...
Хотя отчего именно так сделано не совсем понятно.
отчего именно так сделано не совсем понятно
-----
Да от того что мудень не смог корректно обработать заменители символов.
Бля, поменять систему масок устойчиво используемую с начала 80-х... и объявить фичей... мудак он и есть мудак...
Ну кому нужны все файлы - напишут "*.dll*" ili "*.dll???"... но подгребать все в кучу? Ох, мудень...
Вопрос - как получить нормальный список соответствующий стандартной/старой маске?
Понятное дело - профильтровать список Я могу, но Я хочу получить то, что мне надо, от системы.
Не помню, может уже описывал...
Имеем Студию.
Имеем Солюшен с несколькими проектами.
Имеем дополнительную конфигурацию - у меня Тестс - для построения тестов.
Создаем новый Проект. В нем - две конфигурации. Третью надо добавлять руками.
Перед добавлением - выбираем Тестс и проверяем что выставлено в Конфигуратион Менеджере для созданного Проекта. Там должно быть Релеасе.
Выгружаем созданный проект, редактируем руками дописывая конфигурацию Тестс.
Сохраняем и загружаем Проект.
Пытаемся выставить Тестс для Проекта в Конфигуратион Менеджере...
Сюрприз - его там нет.
Высказываем все что думаем об мудаке билли, выгружаем Студию, загружаем Студию, выставляем вожделенный Тестс...
Сегодня словил очередного глюка...
Солюшен с 48 проектами (еще 40-45 проектов-тестов не включены в солюшен).
В прошлый четверг все проекты были скомпилированы и деплойнуты. Все работает как надо.
Никаких изменений в проекты не вносились.
Насколько помню - компилировал проекты на ВМ, выгрузив солюшен на основной машине.
Т.е. никакой вероятность того что поглючило на одновременном открытии проекта двумя Студиями - нет.
Тем не менее - сегодня проекты не компилируются - в одном из проектов откуда-то появилась ссылка на файл с тестами...
Я бы понял, если бы Я ее туда как-то добавил... но тогда не смог бы задеплоить новую версию... но версия - работает, а солюшен - не компилируется...
Нашелся еще один глюк.
Причем место такое, что должно быть вылизано на все 100%.
И так - метод: System.IO.Path.Combine(part1, part2);
Ожидается - составленный из двух частей путь. Предлагается выполнить следующее:
string myPath;
// ссылаемся на каталог World на один уровень выше.
myPath = Path.Combine(AppContext.BaseDirectory, @"../World");
// ссылаемся на каталог Afrika в World
myPath = Path.Combine(myPath, @"/Afrika");
Можно смеятся - реальная ссылка - на Африку в корневом каталоге диска...
Прэлэстно! (с) Пробито очередное днище.
MSDN:
If path2 does not include a root (for example, if path2
does not start with a separator character or a drive specification),
the result is a concatenation of the two paths, with an intervening
separator character. If path2 includes a root, path2 is returned.
Ну не то, так это...
Шаблончик:
<#@ template language="C#" #><#@ assembly name="System.Core" #><#String part1 = @"C:\inetpub\ftproot\";String part2 = @"My\Best\Folder";#>cd <#= part1 #>\<#= part2 #>
Никаких нарушений синтаксиса не вижу, но... не компилируется.
Проблема - некорректная обработка бэкслеша перед <#=.
Очередная клямпочка от мелкомягких...
Файл проекта.
В ПостБилде Проекту предписано проверить наличие двух папок и скопировать библиотеки в другую папку...
Сделано - для плугинов, чтобы сложить их в отдельную папочку и не парится.
Стандартный код выглядит так:
if not exist "$(TargetDir)" EXIT /B 89
if not exist "$(TargetDir)..\..\Publish\" EXIT /B 88
echo f | xcopy /Y /F "$(TargetDir)$(TargetFileName)" "$(TargetDir)..\..\Publish\$(TargetFileName)"
Для КруисеКонтрол мне потребовалось это дело отменить - там у меня другой механизм отработки. Стало выглядеть так:
if not exist "$(TargetDir)" EXIT /B 89
if not exist "$(TargetDir)..\..\Publish\" EXIT /B 88
echo f | xcopy /Y /F "$(TargetDir)$(TargetFileName)" "$(TargetDir)..\..\Publish\$(TargetFileName)"
Выравнивание и переносы студия сделала сама.
МсБуилд сломался на пробеле после .
Все три десятка проектов надо перепахивать...
Ндаа... форматирование... Ладушки - в ПостБуилде не должно быть пустых строк в начале и в конце - МсБуилд их не понимает...
Постбилд не может быть условным.
-----
А что ему должно мешать? Любая PropertyGroup может иметь Condition=.
PostBuildEvent всего лишь элемент одной из PropertyGroup...
У меня - вполне работает стандартным образом.
А жалуюсь Я на то, что билли у себя никак не смог обеспечить нормальную обработку этого дела.
придумали Solution Configuration
-----
Пока не видел описания. Где почитать без воды, но полно?
Билли - это вообще что-то.
Взял пример из МСДН...
https://msdn.microsoft.com/en-us/library/microsoft.build.b...
Отдал классу Проект один из своих файлов.
Все подохло с криком - Неможу парсить - комментарий встретился...
Да, что депрцировано - Я в курсе, но варианта как жевать проекты актуальным методом пока не попались...
Пока не видел описания. Где почитать без воды, но полно?
Ты никогда не пользовался Solution Configuration'ом или просто троллишь? Solution Configuration
Грубо говоря, делаешь еще одну конфигурацию (скажем Release CI), в этой конфигурации убираешь Post Build Events и в круиз контроле говоришь, что билдить надо не Release, а "Release CI".
в этой конфигурации убираешь Post Build Events
-----
А он не зависит от конфигурации. Студия его создает для ВСЕХ конфигураций.
Собственно, об этом выше и было написано - не понимает билли в Студии условий на ПостБуилде, но МсБуилд будет строить так как написано в условиях. 
Ты никогда не пользовался Solution Configuration'ом
-----
Пользовался, разумеется. Только вот задачки он решает более чем ограниченные...
Я, кстати, просил ссылку на вменяемое описание, а не на биллин бред - что мне толку от интерфейсов, если Я 100% не буду писать расширение?
А вот что-то простое:
- постановка задачи
- действия по использованию
- связанные изменения в системе
- что и где будет работать по-другому
в природе похоже отсутствует... 
----
Блин, проблема выплыла где не ждал - SortedSet неправильно сортируется хотя IComparer вроде корректный...
В результате проектик получает другой приоритет и КИ примитивно зависает...
Пойду искать что не так.
А он не зависит от конфигурации. Студия его создает для ВСЕХ конфигураций.
Как это не зависит?
Прикреплённые файлы
Еще раз тебе повторяю, приведенный скрин - от C++ проекта и его билдет TeamCity и естественно msbuild'ом. Post-Build events различные для резиза и для дебага и все билдится так, как надо.
Проблема где-то в другом месте.
Кстати, пост-билд-эвенты всегда различались для релиза и для дебага хотябы только из-за того, что, как правило, релиз и дебаг имеют разные зависимости (в одном случае релиз-версии, в другом случае - дебаг версии) и, соответственно, зависимости эти бедутся либо из разных катологов, либо файлы называются по разному, либо и то и другое. Кстати, в мире C++ это обычная практика добавлять букву "d" к дебаг версии.
Так что проблемы где-то у тебя, а у Билли ;)
-----
Можно добесконечности повторять, но...
https://social.msdn.microsoft.com/Forums/en-US/14b5ef06-79...
пункт 1. ФАКа...
Провел у себя на домашнем компе эксперимент - поискал файлик с именем vcbuild.exe и... такого файлика нету.
У меня дома правда VS2017, но думаю, что в этом плане VS2015 на том же уровне.
Т.е. VS2017 ну никак не может билдить С++ проекты vcbuild'ом. FAQ - это все конечно хорошо, но совсем не обязательно, что то, что было правильно в 2010-ом году, остается правильным и в 2017-ом.
Кстати, у меня так выглядят проперти C# проекта на VS2017, а не C++.
Настройки C++ проекта выглядят так:
Ну а для для C# можно написать условие для каждой конфигурации:
if $(ConfigurationName) == Debug ( copy "$(TargetDir)myapp.dll" "c:\delivery\bin" /y copy "$(TargetDir)myapp.dll.config" "c:\delivery\bin" /y ) ELSE ( echo "why, Microsoft, why". )
Прикреплённые файлы
Я не знаю чем последние Студии билдят С++ проекты, но...
...то что ты привел в качестве конфига не обрабатывается МсБуилдом.
МсБуилд работает с ХМЛ-документом.
В нем есть возможность определить Пред- и Пост- евенты.
По одному Пост- и Пред- на проект обернутые в ПропертиГроуп.
При определении для ПропертиГроуп можно дописать условие и МсБуилд будет его обрабатывать.
Но Студия не умеет обрабатывать условия для ПропертиГроуп Пост- и Пред- евентов.
Просто не понимает.
Элементарно - пишет второй набор Пред- и Пост- евентов вместо апдейта существующих.
Студии ПРО у меня нету - смотреть не на чем.
Вариант.
Зачем делаю в окошке... хммм... ну так получилось... копи-пасте рулит - копировать одну строку или десяток - без разницы, а копи-паст в окошко плюс копи-паст файлика - вдвое больше работы.
Вопрос был в том, что механизм управления этим делом уже имеется, но не используется и инструментарий не умеет его использовать корректно.
Ааа... понял...
Возьми обычный файл проекта и поправь < PropertyGroup > на <PropertyGroup Condition=" '$(ConfigurationName)' == 'Debug' " >
Получишь тот же самый результат, но не скриптовым языком, средствами МсБуилд - Кондитион для него стандартное средствo.