enableDefinition = Помилка 'MachineToApplication' при публікації з VS2010 (але тільки після попередньої збірки)


103

Я можу запускати свою програму Asp.Net MVC 2 без проблем на своєму локальному комп'ютері. Просто запустіть / налагоджуйте.

Але якщо я вже створив його, я не можу його опублікувати! Я повинен очистити розчин і опублікувати його ще раз. Я знаю, що це не є критично важливим для системи, але це насправді дратує. "Опублікувати одним клацанням" не є "Очистити рішення, а потім опублікувати одним клацанням"

Точна помилка така:

Помилка 11 Помилка використання розділу, зареєстрованого як enableDefinition = 'MachineToApplication' поза рівнем програми. Ця помилка може бути викликана тим, що віртуальний каталог не конфігурується як програма в IIS.

Я підозрюю, що це пов’язано з Web.Config у папці Views, але чому тоді лише після того, як я буду буду один раз раніше. І лише зауважимо, що додаток працює чудово після опублікування.


1
Якщо в дочірньому каталозі є додаткова web.config, спробуйте її видалити.
користувач1154664

Відповіді:


76

У мене була така ж проблема з моїми програмами MVC. це засмучувало, тому що я все ще хотів перевірити мої погляди, тому я не хотів вимикати MvcBuildViews

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

<BaseIntermediateOutputPath>[SomeKnownLocationIHaveAccessTo]</BaseIntermediateOutputPath>

І зробити цю папку не в папці вашого проекту. Працює для мене. Це не ідеальне рішення, але це добре на даний момент. Переконайтесь, що ви видалите папку пакета (розташовану всередині папки obj \ Debug та / або obj \ Release ) зі своєї папки проекту, інакше ви продовжуєте отримувати помилку.

FWIW, MS знають про цю помилку ...


1
phil haack має оновлення цього питання для тих, хто працює проти SP1 2010: haacked.com/archive/2011/05/09/…
benpage

3
nb рішення, яке phil має у цьому блозі, не працює для мене. вищевказане рішення - моє єдине рішення.
benpage

9
Я думаю, що видалення папки obj - це набагато простіше рішення і менше пам’ятати / підтримувати інформацію про зміни у файлі проекту. Здається, це має бути головною відповіддю тут. (станом на середину 2011 року)
RyanW

FWIW, ця запис фактично змінює проміжний шлях виходу для публікації ( \objшлях), а не MvcBuildViews. Різниця тонка, але значна.
новонароджений

40

Я видалив усе з папки obj / Debug, і він виправив цю помилку. Це дозволило мені залишитись у

<MvcBuildViews>true</MvcBuildViews>

варіант у моєму проектному файлі (який корисний із шаблоном T4MVC T4).

Редагувати: Це можна досягти набагато простіше, просто скориставшись меню "Збірка" -> "Перебудувати рішення" (оскільки фактично відбудуватися - очистити папку obj / Debug, а потім створити рішення).


26

Я використовую це рішення в MS Connect для цієї помилки. Перед очищенням AspNetCompiler він очищає всі obj та temp-файли під вашим проектом (усі конфігурації).

Змініть ціль MvcBuildViews у файлі проекту так, щоб вона залежала від цілей, які очищають файли упаковки, створені Visual Studio. Ці цілі автоматично включаються до проектів веб-додатків.

Усі файли упаковки будуть видалятися кожного разу, коли виконується ціль MvcBuildViews.

<Target Name="MvcBuildViews" AfterTargets="AfterBuild" Condition="'$(MvcBuildViews)'=='true'" DependsOnTargets="CleanWebsitesPackage;CleanWebsitesPackageTempDir;CleanWebsitesTransformParametersFiles;">
    <AspNetCompiler VirtualPath="temp" PhysicalPath="$(MSBuildProjectDirectory)" />
</Target>

Працює для мене. Я також прокоментував роботу наступної цілі: <Target Name = "AfterBuild" Condition = "'$ (MvcBuildViews)' == 'true'"> <AspNetCompiler VirtualPath = "temp" PhysicalPath = "$ (ProjectDir)" /> < / Target>
kaptan

Оновлення - оновлення інструментів MVC 3 має виправити це. haacked.com/archive/2011/05/09/…
jrummell

3
Так ... додавання rmdir /S /Q "$(ProjectDir)\obj"до розділу для створення публікацій відповідно до Microsoft Ticket вирішило проблему!
Леніел Маккаферрі

У 2012 році цільових CleanWebsitesPackageTempDir та CleanWebsitesTransformParametersFiles не існує, і все одно отримують помилку.
Дейв

2
@jrummell цікаво, я отримую цю помилку MachineToApplication, коли в моєму проекті mvc4 включено представлення збірок, я вважав, що це якось пов'язано.
Дейв

24

Ця проблема виникає, коли в папці obj є вихід веб-проекту (шаблонна web.config або тимчасові файли публікації). Використовуваний компілятор ASP.NET недостатньо розумний, щоб ігнорувати речі в папці obj, тому він замість цього видаляє помилки.

Ще одне виправлення полягає в тому, щоб зняти вихідний результат прямо перед викликом <AspNetCompiler>. Відкрийте свій .csproj і змініть це:

<Target Name="MvcBuildViews" AfterTargets="AfterBuild" Condition="'$(MvcBuildViews)'=='true'">
  <AspNetCompiler VirtualPath="temp" PhysicalPath="$(WebProjectOutputDir)" />
</Target>

до цього:

<Target Name="MvcBuildViews" AfterTargets="AfterBuild" Condition="'$(MvcBuildViews)'=='true'">
  <ItemGroup>
    <ExtraWebConfigs Include="$(BaseIntermediateOutputPath)\**\web.config" />
    <ExtraPackageTmp Include="$([System.IO.Directory]::GetDirectories(&quot;$(BaseIntermediateOutputPath)&quot;, &quot;PackageTmp&quot;, System.IO.SearchOption.AllDirectories))" />
  </ItemGroup>
  <Delete Files="@(ExtraWebConfigs)" />
  <RemoveDir Directories="@(ExtraPackageTmp)" />
  <AspNetCompiler VirtualPath="temp" PhysicalPath="$(WebProjectOutputDir)" />
</Target>

Це видалить усі web.configs під \ obj, а також усі папки PackageTmp під \ obj.


ПЛЮСЬ ОДИН усі мої результати. У мене в objпапці був детрит .
ta.speot.is

Редактор скаржиться, що елементи всередині <ItemGroup>недійсні, але ігнорує це - він все одно працює.
Kjell Rilbe

Працювало чудово і рятує мене від головного болю при видаленні папки obj кожного разу, коли я хочу переключити конфігурацію з налагодження на випуск
Todd Skelton

4

Якщо ви використовуєте Web Publish, ви можете встановити MvcBuildViews=falseі PrecompileBeforePublish=true, що попередньо компілюється після копіювання, у тимчасову папку (безпосередньо перед публікацією / пакуванням).

ПРИМІТКА: PrecompileBeforePublishпідтримується лише "новий" стек трубопроводів веб-публікацій (VS2010 SP1 + Azure SDK або VS2012 RTM). Якщо ви використовуєте VS2010 RTM, вам знадобиться один з альтернативних методів.


Я не бачу цього рішення, що формує погляди. Я навмисно поставив помилку в моєму огляді і встановив PrecompileBeforePublish = Істинно, і збірка не пройшла. (Я використовую VS2012)
Хулла

Це вирішило це для мене, працюючи в збірці VSO, де я намагався виконати попередню компіляцію з / p: PrecompileBeforePublish = true
Стівен Макдауелл

3

Щодо рішення jrummell, налаштування:

DependsOnTargets="CleanWebsitesPackage;CleanWebsitesPackageTempDir;CleanWebsitesTransformParametersFiles;"

Він працює у VS 2010 , але не у VS 2012 . У 2012 році вам належить поставити:

DependsOnTargets="CleanWebsitesPackage;CleanWebsitesWPPAllFilesInSingleFolder;CleanWebPublishPipelineIntermediateOutput"

Джерело:

VS 2010: C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ Web \ Microsoft.Web.Publishing.targets

VS 2012: C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v11.0 \ Web \ Microsoft.Web.Publishing.targets


3

Я знаю, що на це відповіли, але я просто хотів додати щось цікаве, що знайшов.

Я встановив "MvcBuildViews" значення false в проекті, видалив усі папки bin та obj, і я все ще отримував помилку. Я виявив, що був файл ".csproj.user", у якому "MvcBuildViews" все ще встановлено на "true".

Я видалив файл ".csproj.user", і все це спрацювало.

Тому переконайтесь, що ви змінюєте файл csproj, який ви також можете змінити або видалити файл ".csproj.user".


1

У мене була і ця проблема, тому я створив подію попереднього збирання у властивостях проекту для очищення вихідних каталогів ( ${projectPath}\bin,${projectPath}\obj\${ConfigurationName}). В іншому проекті я також отримував цю помилку, навіть якщо відбулася чистка. У другому проекті я збирав погляди, як зазначено у файлі проекту:

<MvcBuildViews>true</MvcBuildViews>

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


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

0

Проблема пов'язана з проміжними файлами, але є ще одне рішення, яке полягає в очищенні цих проміжних файлів перед тим, як створити представлення даних.

Це рішення було включено до деякої версії VS, але я можу лише сказати, що у мене виникла проблема в оновлення 5. VS 2013 (дивіться "Обережно" нижче, це могло бути виправлено у цій версії, але не працює лише в моїй конкретній нестандартний випадок).

Я запозичив soltuion у Error: enableDefinition = 'MachineToApplication' поза рівнем програми на Visual Studio Connect.

Рішення полягає у включенні цих рядків до проекту ( .csprojфайлу) веб-додатків, який обробляє видалення проміжних файлів, що відступають:

<!--Deal with http://connect.microsoft.com/VisualStudio/feedback/details/779737/error-allowdefinition-machinetoapplication-beyond-application-level, 
we will need to clean up our temp folder before MVC project starts the pre-compile-->
<PropertyGroup>
    <_EnableCleanOnBuildForMvcViews Condition=" '$(_EnableCleanOnBuildForMvcViews)'=='' ">true</_EnableCleanOnBuildForMvcViews>
</PropertyGroup>
<Target Name="CleanupForBuildMvcViews" Condition=" '$(_EnableCleanOnBuildForMvcViews)'=='true' and '$(MVCBuildViews)'=='true' " BeforeTargets="MvcBuildViews">
    <ItemGroup>
     <_PublishTempFolderNamesToCleanup Include="Database;TransformWebConfig;CSAutoParameterize;InsertAdditionalCS;ProfileTransformWebConfig;Package;AspnetCompileMerge" />
    </ItemGroup>
    <!--Force msbuild to expand all the wildcard characters so to get real file paths-->
    <CreateItem Include="@(_PublishTempFolderNamesToCleanup->'$(BaseIntermediateOutputPath)**\%(identity)\**\*')">
     <Output TaskParameter="Include" ItemName="_EvaluatedPublishTempFolderNamesToCleanup" />
    </CreateItem>
    <Delete Files="@(_EvaluatedPublishTempFolderNamesToCleanup)" />
</Target>

Остерігайтеся: чомусь, мабуть, тому, що я сам включив його в проект "BuildViews", замість цього було названо мою ціль побудови для побудови поглядів "MvcBuildViews", тому мені довелося відповідно змінити BeforeTargetsатрибут. Я також спростив ціль, видаливши PropertyGroupта спростивши умову, наприклад:

  <Target Name="CleanupForBuildMvcViews" Condition="'$(MVCBuildViews)'=='true' " BeforeTargets="BuildViews">
    <ItemGroup>
     <_PublishTempFolderNamesToCleanup Include="Database;TransformWebConfig;CSAutoParameterize;InsertAdditionalCS;ProfileTransformWebConfig;Package;AspnetCompileMerge" />
    </ItemGroup>
    <!--Force msbuild to expand all the wildcard characters so to get real file paths-->
    <CreateItem Include="@(_PublishTempFolderNamesToCleanup->'$(BaseIntermediateOutputPath)**\%(identity)\**\*')">
     <Output TaskParameter="Include" ItemName="_EvaluatedPublishTempFolderNamesToCleanup" />
    </CreateItem>
    <Delete Files="@(_EvaluatedPublishTempFolderNamesToCleanup)" />
  </Target>

0

У моєму випадку я бачив, що коли у мене є MvcBuildViews та PrecompileDuringPublish як істинні - це було причиною цієї проблеми.

Тому я видалив PrecompileDuringPublish, і це рішення працювало на мене, і з тих пір я не стикався з цією проблемою.

введіть тут опис зображення

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.