Visual Studio 2012 Web Publish не копіює файли

У мене є проект веб-додатків у VS 2012, і коли я використовую інструмент веб-публікації, він створюється успішно, але не копіює жодного файлу до цілі публікації (файлова система в цьому випадку).

Якщо я дивлюся на вихід збірки, я можу побачити, що все копіюється в obj \ Release \ Package \ PackageTmp \ правильно, але тоді все, що я бачу на виході збірки, це:

4> Виконано проект будівництва "{Project} .csproj".
4> Видалення існуючих файлів ...
4> Публікація папок / ...
4> ========== Складання: 3 вдалося, 0 не вдалось, 1 оновлено, 0 пропустив ===== =====
========== Опублікувати: 1 вдалося, 0 не вдалося, 0 пропустило ==========

Незважаючи на те, що він каже, що публікація вдалася, у цільовому каталозі для публікації немає файлів.

Я бачив це в багатьох проектах, і іноді здається, що конфігурації рішення / платформи викликають цю проблему, але я не зміг точно визначити причину для цього.

Хтось ще бачив, як це відбувається, чи має ідею, як правильно це зробити?

ОНОВЛЕННЯ:

Я, можливо, знайшов рішення для цього. У мене просто це повторилося, і я заплутався з налаштуваннями публікації. Як тільки я змінив вибрану Конфігурацію на вкладці Налаштування на іншу конфігурацію, а потім повернувся до тієї, яку я хотів використати, всі мої файли знову почав публікувати. Сподіваємось, це буде працювати і в інших проектах у майбутньому.

ОНОВЛЕННЯ 2:

Я опублікував помилку в Microsoft Connect і почув відповідь від розробника в команді VS Web Developer. Він сказав, що вони вирішили цю проблему у своїх внутрішніх складах і незабаром випустять оновлення до інструменту публікації, що вирішить цю проблему.

ОНОВЛЕННЯ 3:

Це нещодавно було виправлено за допомогою Visual Studio 2012 Update 2

Це може бути спричинено рішеннями / проектами, які були створені разом з РЦ vs2012. Це трапилось зі мною місяці тому і виправив проблему, переконавшись, що конфігурації побудови рішення збігаються з моїми конфігураціями проектів ...

Нещодавно у мене з’явилася та ж проблема, коли відкривалося те саме рішення, яке було створене в vs2012RC за допомогою VS2012 Express для Web. Я зробив саме те, що запропонував оригінальний плакат, і це вирішило мою проблему.

Ось нитка, яка веде мене до відповіді:

connect.microsoft.com/VisualStudio/feedback/details/746321/publish-web-application-fails

Відповідна відповідь із розмови, яка допомогла мені:

Опубліковано Microsoft 13.06.2012 о 12:00 Привіт Ендрю,

Це було помилкою в тому, як ми обробляємо конфігурацію рішення проти конфігурації проекту. Ми помилково припускали, що вони будуть однаковими (наприклад, Solution's Release | x86 також буде встановлений для кожного проекту Release | x86), що спричинило використання неправильних властивостей збірки для публікації файлів.

Вирішення завдання полягає в тому, щоб зрівняти конфігурацію рішення та скласти конфігурацію. Ця проблема буде виправлена ​​у наступному випуску Visual Studio 2012.

Дякую, - Jimmy Lewis SDET, команда Visual Web Developer

Та ж проблема. Вирішення проблеми було змінити параметри публікації з Release на Debug. Повторно публікуйте, а потім поверніться до Release ...

Щоб взяти це трохи далі. У вас є два файли, які створюються під час створення профілю публікації.

• NewProfile.pubxml
• NewProfile.pubxml.user

Коли ви відкриваєте проект, який містить ці файли у папці PublishProfile з джерела управління, у нього є лише .pubxmlфайл, а не .publxml.userфайл, тому він створює .publxml.userфайл під час руху під час відкриття проекту. Коли він створює нове .publxml.userз льоту, xml виглядає так:

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
</Project>

Коли ви створюєте новий профіль, він створює xml, який виглядає так:

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
    <LastUsedPlatform>Any CPU</LastUsedPlatform>
    <TimeStampOfAssociatedLegacyPublishXmlFile />
    <EncryptedPassword />
  </PropertyGroup>
</Project>

Якщо ви візьмете <PropertyGroup>вузол і помістите його у .pubxml.userфайл, ваші PublishProfiles почнуть працювати знову.

Просте виправлення - видалити профіль публікації та створити новий.

коли ви клацніть правою кнопкою миші на вашому рішенні та виберіть опублікувати, у вас встановлений профіль. видаліть це та створіть нове.

це виправить.

У мене була ця проблема від переходу з 2010 на 2012 рік

У мене була така ж помилка, і я змінив налаштування від випуску до налагодження, і проблема вирішена ..

У мене була така ж проблема, проте жоден з відповідей у ​​цій темі не працював на мене. Моя проблема полягала в тому, що існує каталог, який містить динамічно генеровані (моїм додатком) статичні HTML-файли. Весь каталог не публікувався.

Рішення , яке працювало для мене було знайдено тут :

Один випуск, який я повернув, і подумав, що слід документувати, - це те, що певні типи файлів не завантажувались, коли я публікував проект.

Розглянуті типи файлів: .pdf файли та .rtf.

Причина цього сталася через те, що розширення файлів не були визнані такими, що вимагають публікації Visual Studio. На щастя, це можна змінити у Visual Studio.

Виберіть файли, які не копіюються. У властивостях забезпечити Побудувати Дія встановлюється в Content .

Якщо це не працює, можна спробувати наступне.

У меню Проект виберіть Пакет / Публікація в Інтернеті та помітьте це спадне меню:

Спробуйте змінити це на Усі файли в цій папці проекту.

Це відбувається тому, що .pubxml.user містить необхідну інформацію для публікації, і цей файл не повинен (і не повинен) бути включеним до контролю джерел. Щоб виправити цю помилку VS, скопіюйте інформацію з файлу .pubxml.user у файл .pubxml. Відповідні властивості:

<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>

Помістіть їх у свій .pubxml, і ви маєте добре піти.

Я спробував усі ці рішення, але це те, що працює кожен раз.

Ми просто змінюємо "Опублікувати метод:" з "Файлової системи" на, наприклад, "Веб-розгортання", і негайно повертаємо його назад на "Файлова система".

У мене були (були) однакові проблеми для кількох проектів. Єдиним, хто вражає, здаються веб-проекти. Видалення та відтворення профілю вирішує проблему лише один раз. Крім того, порівнюючи створений файл публікаціїxml не дає ніяких відмінностей, тому воно зовсім не схоже на профіль.

Наразі єдине надійне рішення, яке згадує ОП, щоб змінити проблеми з побудовою.

Я зіткнувся з тією ж проблемою на VS 2010, після перевірки публікації публікацій, журналів подій, включення та перевірки журналів візуальної студії тощо. Потім я вирішив видалити веб-публікацію (через додавання / видалення), яку, на мою думку, нещодавно оновлено до v1. 0.30810.0. Це вирішило проблему.

Тут у нас була така ж проблема.

Ми просто змінюємо "Опублікувати метод:" з "Файлової системи" на, наприклад, "Веб-розгортання", і негайно повертаємо його назад на "Файлова система".

Для мене працювало наступне:

Просто перейдіть у меню Release> Debug> Release (або навпаки), а потім опублікуйте.

Не потрібно видаляти, редагувати, публікувати все, що вам не потрібно.

Моя проблема полягала в неправильній конфігурації файлу myproject.csproj. Файл '_address-step1-storage.cshtml' не копіюється при публікації. 'None' змінено на 'Content', тепер це нормально.

Та ж проблема з VS 2012 Pro з ціллю публікації на диску. Проект використовувався для правильної публікації, але почав робити цю проблему там, де не вдалося скопіювати файли в папку призначення.

Рішенням було відредагувати профіль публікації, змінити режим з випуску (будь-якого процесора) на налагодження, потім повернутися до випуску (будь-який процесор). Це призведе до того, що файл PublishProfiles \ projname.pubxml.user буде переписаний (як описано вище). Схоже, додані елементи LastUsedBuild, LastUsedPlatform та TimeStampOfAssociatedLegacyPublishXmlFile під вузлом групи властивостей. Після публікації буде додано ще одну ItemGroup з окремими файлами та часом публікації.

Ця дія була для мене вдалою:

Убийте опублікувати профілі у "Властивості> PublishProfiles> xxxx.pubxml" і знову встановіть їх знову.

Що я того вартий, я врешті-решт відмовився від боротьби з Web Deploy, щоб змусити його робити те, що хотів (копіювати розгорнуті файли та більше нічого), тому я написав це в PowerShell і дуже задоволений результатом. Це набагато швидше, ніж усе, що я пробував через MSBuild / Web Publish, імовірно, тому що ці методи все ще робили речі, які мені не потрібні.

Ось суть ( буквально ):

function copy-deployable-web-files($proj_path, $deploy_dir) {
  # copy files where Build Action = "Content" 
  $proj_dir = split-path -parent $proj_path
  [xml]$xml = get-content $proj_path
  $xml.Project.ItemGroup | % { $_.Content } | % { $_.Include } | ? { $_ } | % {
    $from = "$proj_dir\$_"
    $to = split-path -parent "$deploy_dir\$_"
    if (!(test-path $to)) { md $to }
    cp $from $to
  }

  # copy everything in bin
  cp "$proj_dir\bin" $deploy_dir -recurse
}

У моєму випадку я називаю це в середовищі CI (TeamCity), але це також може бути легко підключено до події після складання.

Я виявив, що міг подолати цю проблему, змінивши цільове місце розташування з obj / [випуск | етап | ..] на новий шлях поза папками рішення, наприклад, c: \ розміщення. Схоже, VS 2012 заплутався і, можливо, здався десь під час публікації.

Метт

З тією ж проблемою нещодавно у VS 2013 був проект MVC, в який я імпортував Umbraco CMS. Я не міг опублікувати. Відповідь вище допомогла, хоча мені знадобився деякий час, щоб зрозуміти, що я насправді повинен робити у VS. Для знаходження цього потрібні були деякі дослідження, наприклад, в блогах MS. Я намагаюся сказати це просто:

• Виберіть на панелі інструментів VS певну конфігурацію, наприклад, Release та Any CPU. Запустіть проект.
• Після цього клацніть правою кнопкою миші в Провіднику рішень щодо відповідного рішення, виберіть Опублікувати. Створіть новий профіль публікації або скористайтеся заданим, але завжди переконайтесь, що в налаштуваннях вибрана та сама конфігурація (наприклад, Release і Any CPU), як і перед тим, як ви запускали проект в останній раз.
• Крім того, у моєму випадку довелося видалити папку OBJ, оскільки тут застрягли налаштування з моїх останніх невдалих спроб опублікувати, хоча я перезапустив VS та видалив усі профілі публікації.

У мене є веб-додаток з декількома іншими згаданими проектами в рішенні. У минулому я багато разів успішно розгортався з однією конфігурацією Publish. Я змінив Конфігурацію проекту з Налагодження на Випуск для проекту, який був пропущений в минулому. Наступного разу, коли я спробував розгорнути, у мене з’явилися ці симптоми, коли Publish просто тихо виходить з ладу - він нічого не робить і каже, що це вдалося:

1>------ Build started: Project: Project, Configuration: DeployProduction Any CPU ------
1>  
2>Publishing folder /...
========== Build: 1 succeeded, 0 failed, 9 up-to-date, 0 skipped ==========
========== Publish: 1 succeeded, 0 failed, 0 skipped ==========

Єдиний спосіб відновити це - стерти профіль Publish, закрити Visual Studio, щоб змусити його зберегти видалення, знову відкрити його та відтворити профіль Publish з нуля. Як тільки я це зробив, я міг знову опублікувати штраф.

Win8 VS2012, хитрий ноутбук.

У Visual Studio 2012 перемикання між випусками все ще викликає проблеми.

Ми додали подію попереднього збирання для видалення objпапки: del /s /f /q $(ProjectDir)\objі вона виправила проблему публікації. Прибирання працює іноді, але не завжди.

Нарешті я знайшов відповідь сам. Всі перераховані вище рішення для мене не працюють.

Що я зробив, це те, що я переміщу проект на диск c, щоб змінити папку проекту на щось коротше і стрімко публікувати його.

Причиною того, що він не вдався з мого боку, є те, що у мене була дуже довга назва проекту / герархія.

C: \ Користувачі \ Користувач \ Настільний \ Система управління дотриманням \ ComplianceIssueManagementSystem \ ComplianceIssueManagementSystem

Я думав про це, тому що іноді, коли я витягував файл rar, він говорить, що ім'я / шлях занадто довгий. Я думав, що це буде те саме, що публікує візуальна студія 2012 року. і це робить!

сподіваюся, це допоможе вам, хлопці.

Перевірте свій поточний проект на те, чи ви зробили копію із тим самим іменем класу та іншим ім'ям сторінки (ім'я класу успадкує скопійований файл). Зрештою, це заплутає компілятор !!!

CodeFile = "Consolidated.aspx.vb" Inherits = "Консолідований

Жодне з перерахованих вище рішень не працювало для мене.

Але я помітив, що з наших п'яти проектів ASP.NET MVC в нашому головному рішенні чотири з них поставили пакет розгортання в потрібне місце, а один залишив його під obj \ Debug.

Я порівняв проекти та виявив розбіжність. Рішення було змінити це :

<Import
    Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />

до цього :

<Import
  Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets"
  Condition="'$(VSToolsPath)' != ''" />
<Import
  Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets"
  Condition="false" />

Після того як я внесла цю зміну, усі п’ять проектів поставили свої пакети розгортання в потрібне місце.

(Вибачте за довгі рядки, але я не зміг знайти кращого способу їх ущільнення.)

Я зіткнувся з цим, коли файли посилань на службу, створені Visual Studio, стали занадто довгими щодо загальної довжини шляху.

Скоротіть їх, повторно генерувавши Довідку служби за допомогою svcutil.exe, видаливши всі вихідні файли довідкових служб.

svcutil можна назвати так:

"C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\SvcUtil.exe" /language:CS http://myservice /namespace:*,My.Namespace

Мій простір імен слід замінити наявним простором імен у створеному сервісному проксі (як правило, він знаходиться у файлі Reference.cs), щоб уникнути помилок компіляції.

http://myservice слід замінити URL-адресою кінцевої точки обслуговування.

Я потрапив у ту ж проблему. Жодне з перерахованих вище рішень не працювало для мене.

Отже, я виключив файли, які не вдалося скопіювати під час публікації.

Я публікував веб-сайт кілька разів. Але одного разу, коли я змінив якийсь файл aspx, а потім спробував опублікувати веб-сайт, у результаті вийшла порожня опублікована папка.

На своєму шляху я знайшов рішення.

1. Майстер публікації відображатиме будь-які помилки під час публікації, але не копіює жоден файл у папку призначення.

2. Щоб дізнатися файл, який генерує помилку, просто скопіюйте вміст папки веб-сайту у нову папку та запустіть візуальну студію з цього веб-сайту.

3. Тепер, коли ви спробуєте опублікувати, це дасть вам ім'я файлу, що містить помилки.

4. Просто виправте помилку в оригінальній папці веб-сайту і спробуйте опублікувати, вона буде працювати, як було раніше.

Виконайте такі дії, щоб вирішити:

Build > Publish > Profile > New

Створіть новий профіль і налаштуйте його з тими ж налаштуваннями, що і ваш існуючий профіль.

Тепер проект буде опубліковано правильно. Це часто відбувається в результаті керованого джерелом профілю публікації з іншої машини, створеної в новій версії Visual Studio.

ФІКСОВАНО - різні пропоновані рішення не працювали для мене. Що для мене працювало з VS Community 2017, Windows Server 2012 R2, це змінити змінні середовища TEMP та TMP для користувача, а потім перезапустити систему та знову розгорнути (перезавантаження VS було недостатньо). Ці змінні temp - це місце, де VS публікує temp.

Перезапуск візуальної студії після зміни тимчасових змінних не зробив фокус, довелося перезавантажити систему.

Перший:

• Конфігурація вбудованого випуску.
• На сторінці Властивості проекту-> виберіть Усі файли та папки в Пакеті / Опублікувати Інтернет.
• Відновити розчин (після розчину Clean).
• тепер опублікуйте.

Під час публікації перевірте, що ви обрали.
це має робити. Це зробило для мене! :)

Найпростіше,

   1. select the file(s) that are not being copied,
   2. Press <F4> to get the properties window
   3. Make the "Build Action" property "compile" or "content" depending on what it is.
   4. Now this particular file will be included!