С некоторого момента времени Visual Studio стал показывать ошибку.
Ссылка на картинку ошибки: //vkontakte.ru/photo589737_136054109.
Текст ошибки: "Visual Studio cannot start debugging because the debug target 'C:\….\Project\WindowsApplicatio6\bin\Debug\WindowsApplicatio6.exe' is missing. Please build the project and retry, or set the OutputPath and AssemblyName properties appropriately to point at the correct location for the target assembly."
Я не так давно начал работать в этой среде, поэтому не могу в точности раззобраться от чего появилась эта ошибка. Понятно, что Вижуал Студия не может запустить процесс отладки, т.к. не может найти откомпилированый файл .exe в соответствующем каталоге "\bin\Debug\". Когда компилирую проект отдельно (Build), Студия не выдаёт никаких ошибок, а наоборот уверяет меня, что всё прошло превосходно. Не смотря на это в каталоге "\bin\Debug\" экзешника всё ещё не наблюдается. Хотя в папке "\obj\Debug\" лежит файл "WindowsApplicatio6.exe". Тот ли это экзешник? Может достаточно просто сменить в настройках путь "\bin\Debug\" на "\obj\Debug\"?
18 августа 2009 в 0:03
Да не, это мож и важно тем кто такты считает, ассемблерщикам мож. А для Сишников достаточно собрать проект с другими опциями. И вуаля, полный юникод. Хотя тож есть свои заморочки. Ну прошли времена Win95, а в Win7 вообще что твориться, обычные проги на эмуляторе WinXP запускаются. А для родных все по своему.
18 августа 2009 в 0:02
Да, радуюсь, круто же, целых 32 тыщи
А про время конвертации – не знаю, может и ощутимо. Все таки маппинг тысяч символов юникода на ANSI и обратно, со всеми там разными code pages, навряд ли осуществляется супербыстро, и так далее, не говоря уже о выделении промежуточного буфера для строки, который наверняка берется из кучи, за время, далеко не всегда константное. Так что вполне возможно, что времени на среднюю строку наберется больше, чем каких-то жалких тысячу, на сколько я помню, тактов, требуемых для перехода между user и kernel. Правда действительно, навряд ли это может кого-то беспокоить. Но интересно бы замерить
18 августа 2009 в 0:00
> раз пошёл такой оффтоп, то на сколько всё-таки фактически быстрей?
На столько что в вашей программе это будет не существенно заметно. т.к время на конверацию несоизмеримо меньше чем переход через шлюз из user-mode в kernel-mode и обратно, где фактически происходит обработка ваших API вызовов. Обычно узкие места можно отловить профилировщиком. А если хочется уж очень заоптимизировать, то можно вызывать Zw*, Nt* аналоги WinAPI функцкий. Но есть ли в этом смысл когда уже .NET на дворе и мало кого интерисует производительность программы.
17 августа 2009 в 23:05
> Я с некоторого времени только Unicode и использую.
Вот вы через это прошли.. и теперь радуетесь полноценным длинным путям до 32000 символов… а некоторым хватает и 260
> Его выгодно использовать хотя бы потому, что ANSI-версии функций
> только и делают, что конвертируют строки и передают их Unicode-
> версиям
Ну делают они так по той причине, что в kernel-mode все функции только Unicode… и там уже хочешь/не хочешь а приходится только с Unicode работать.
17 августа 2009 в 23:05
раз пошёл такой оффтоп, то на сколько всё-таки фактически быстрей? а то слышать слышал, а дойти до нира по теме не дошёл, вроде не критично, а знать так для галочки интересно.
17 августа 2009 в 23:05
Тута соглашусь, сколько раз под Olly видел такие фокусы, конвертим туды, конвертим сюды. Даже какой нить MessageBoxA перегоняется в MessageBoxW.
А с NOD32 я пересел на Eset Smart Security. Быстро, четко и все корректно.
17 августа 2009 в 23:03
Ну, я как-то тестировал антивирус NOD32, по-видимому, он работает с такими путями
Кроме того, он безошибочно (совершенно не зависая и находя все спрятанные вирусы) прошел мои тесты типа запутанных мягких/жестких ссылок NTFS на файлы, каталоги, в том числе и циклические ссылки на дереве каталогов, потоки NTFS, и некоторое множество других хитровывернутых тестов, после чего я проникся большим почтением к его создателям 
Так что корректные программы существуют 
17 августа 2009 в 23:03
2 Cyber Max:
Я с некоторого времени только Unicode и использую. Его выгодно использовать хотя бы потому, что ANSI-версии функций только и делают, что конвертируют строки и передают их Unicode-версиям, а выходные строки конвертируют обратно, то есть могут работать гораздо медленнее. Да и вообще из-за понятных преимуществ юникода.
17 августа 2009 в 23:02
> К сожалению, используют их немногие, к примеру:..
А вы часто используете Unicode версии апишный функций? Microsoft дала небольшую вольность и разрешила выбирать между ANSI и Unicode функциами, но тем самым уменьшила и рамки дозволеного…
17 августа 2009 в 23:00
Оффтоп пошел, ну да ладно. А какая прога смогет такой путь корректно обработать ?
Я наблюдал как то, что дискета сбойнула а получилось что в папке A:\NC\ находилась папка NC (ну это в старые времена было), при чем это была не другая папка, а сама же она. И винда вычисляя занятое место прошлась по этому пути вглубь рекурсивно пока хватило длины пути. Дискета получилась ооооооочень объемной
17 августа 2009 в 22:04
Собственно говоря, я к этому и сказал
Это распространенное заблуждение, что путь ограничен 260 символами, практически все файловые функции WinAPI поддерживают очень длинные имена, если уметь их использовать:
//msdn.microsoft.com/en-us/library/aa365247.aspx
(см. в разделе Maximum Path Length)
К сожалению, используют их немногие, к примеру, Проводник Windows (проверял вплоть до висты включительно) или Far Manager до сих пор не могут открывать каталоги и файлы с путями больше 260 символов.
17 августа 2009 в 22:02
2 Алиев ˜”*°•ShooshpanchiK•°*”˜ Дамир:
Немного оффтоп, но:
малость спутаны понятия длины имени файла и длины пути к файлу.
На самом деле в WinAPI максимальная длина пути составляет порядка 32000 символов. Имя же файла действительно ограничено 255 символами и в FAT, и в NTFS.
17 августа 2009 в 22:02
Что такое максимальная длина имени файла?
Windows обычно ограничивает имена файлов 260 символами. Но фактически имя файла должно быть короче, ____так как в это число включен полный путь____ (например, C:\Program Files\filename.txt). Поэтому иногда можно столкнуться с ошибкой при копировании файла с очень длинным именем в папку, имеющую более длинный путь, чем текущая папка.
Взято с
//windowshelp.microsoft.com/Windows/ru-RU/Help/...
(Выделено мною)
17 августа 2009 в 20:05
Ну а бинарник то хоть заново создался ?
17 августа 2009 в 20:05
Да. Всё работает. Больше никуда не лезу))
17 августа 2009 в 20:04
Кстати, ребилд и удаление бинариков не решили проблему.
17 августа 2009 в 18:00
Как известно, длина имени файла в Windows ограничена 256 символами. В программировании используется константа MAX_PATH, которая равна 260. Судя по названию, она означает максимальную длину пути в Windows, которая складывается из максимальной длины имени каталога 255 символов + слэш на конце + завершающий нулевой символ, и из символов, означающих букву диска в количестве трёх штук (например, "C:\"). Всё это вместе даёт длину пути 260. На самом деле это ограничение в 260 символов есть только в Windows API. В самой файловой системе (FAT32 или NTFS) максимальная длина имени файла ограничена 255 символами.
Хотя да, в пути
C:\Documents and settings\admin\Мои документы\Visual studio 2005\Projects\WindowsApplicatio6\WindowsApplicatio6\bin\Debug\WindowsApplicatio6.exe
я насчитал 147 символов.
17 августа 2009 в 16:00
>>Удали тот файлик и снова скомпиль, тогда и увидишь он это или нет. Делов то.
Программа на выполнение вообще не запускается. Пробовал запустить файл в "\obj\Debug\", запускается и по обычному работает вроде…
Посмотрел в старых проектах фалы в двух каталогах "\bin\Debug\" и \obj\Debug\", затем сравнил их и оказалось, что они полностью одинаковы, файлы всмысли… Поменял OutputPath в настройках проекта и вроде заработало всё…
17 августа 2009 в 15:02
Крякер Красноярцев
Удали тот файлик и снова скомпиль, тогда и увидишь он это или нет. Делов то. А вообще путь длинноват, тама вроде есть какое-то ограничение на длину пути.
17 августа 2009 в 15:02
Нормальный путь. ребилд или удаление бинарников решают подобные проблемы.