nuget.exe не распознает целевую структуру в файле nuspec

У меня есть проект, который создает пакет NuGet непосредственно в Visual Studio, установив следующий параметр в файле CSPROJ:

<GeneratePackageOnBuild>true</GeneratePackageOnBuild>

Это приводит к тому, что сгенерированный пакет включает все встроенные файлы ресурсов, которые были помечены как «копировать в выходной каталог = не копировать».

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

К сожалению, автоматический упаковщик Visual Studio предпочитает всегда копировать эти файлы в пакет NuGet, несмотря ни на что.

Чтобы решить эту проблему, я пытался отредактировать файл .NUSPEC и использовать NUGET.EXE из командной строки для создания пакета.

Тогда я столкнулся с новой проблемой. Используя NUGET.EXE вместо Visual Studio, сгенерированный пакет показывает раздел зависимостей как «неподдерживаемый», что я вижу, открыв пакет в «NuGet Explorer»:

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

Вот файл .bat для создания пакета:

c:\nuget\nuget.exe config -Set repositoryPath="%USERPROFILE%\.nuget\packages"
c:\nuget\nuget.exe pack -IncludeReferencedProjects -properties Configuration=Release

А вот файл NUSPEC:

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
  <metadata>
    <id>Integrative.Lara</id>
    <version>0.5.3</version>
    <authors>Pablo Carbonell, Integrative Software LLC</authors>
    <owners>Pablo Carbonell, Integrative Software LLC</owners>
    <requireLicenseAcceptance>true</requireLicenseAcceptance>
    <license type="file">LICENSE</license>
    <projectUrl>https://github.com/integrativesoft/lara</projectUrl>
    <iconUrl>https://integrative.b-cdn.net/Integrative.ico</iconUrl>
    <description>Lara is ...</description>
    <copyright>Copyright (c) 2019 Integrative Software LLC</copyright>
    <tags>lara, web, html, html5, desktop, gui, cross, framework, mac, osx, platform, ui, blazor, razor</tags>
    <repository url="https://github.com/integrativesoft/lara" />
    <dependencies>
      <group targetFramework=".NETStandard2.0">
        <dependency id="Microsoft.AspNetCore" version="2.2.0" exclude="Build,Analyzers" />
        <dependency id="Microsoft.AspNetCore.WebSockets" version="2.2.1" exclude="Build,Analyzers" />
      </group>
    </dependencies>
  </metadata>
</package>

Есть ли способ исправить «неподдерживаемую» цель? Я пытался использовать также «netstandard2.0» и другие идентификаторы, и все равно получаю то же самое «неподдерживаемый».

В качестве альтернативы есть ли способ использовать автоматическое создание пакета Visual Studio и предотвратить включение файлов в пакет?


c# nuget nuget-spec
person cat_in_hat    schedule 27.08.2019    source источник
comment
Не уверен, что это единственная проблема, с которой вы столкнулись с ожидаемой структурой, но пробовали ли вы переустановить структуру 2.2? dotnet.microsoft.com/download/dotnet-core/2.2   -  person wilaponce    schedule 27.08.2019
comment
Все еще вижу Неподдерживаемый, Версия = v0.0   -  person cat_in_hat    schedule 27.08.2019

Ответы (1)


arrow_upward
1
arrow_downward

Как видите, когда вы используете нуспек, вы несете ответственность за правильность каждой мелочи. Использование целей пакета NuGet MSBuild проще, поскольку оно автоматизирует такие вещи, как создание зависимостей, включая использование правильного TFM в группе.

Документы NuGet по pack target содержат информацию относится к упаковке с помощью msbuild (что происходит, когда вы используете dotnet pack или GeneratePackageOnBuild). В частности, раздел включая содержимое в пакете имеет этот образец:

<Content Include="..\win7-x64\libuv.txt">
 <Pack>false</Pack>
</Content>

Поскольку ваш файл встроен, ваш csproj будет содержать что-то вроде <EmbeddedResource Include="whatever.ext" />. Итак, используя информацию из документов, вы можете сделать <EmbeddedResource Include="whatever.ext" Pack="false" /> или использовать многострочную версию, как это делают документы. MSBuild позволяет задавать метаданные элемента любым способом.

<GeneratePackageOnBuild>true</GeneratePackageOnBuild>

Примечание по GeneratePackageOnBuild: удобно, когда сборка создает пакеты для вас, но это означает, что когда вы отлаживаете и вам нужно изменить одну строку кода перед повторным тестированием, вам придется ждать не только сборки, но и пакет. Если ваш пакет небольшой, он, вероятно, довольно быстр, но все же замедляет ваш «внутренний цикл». Большинству разработчиков нужно упаковывать гораздо реже, чем создавать, поэтому я предлагаю отключить GeneratePackageOnBuild и вместо этого запускать dotnet pack в проекте (или решении), когда вам действительно нужен nupkg.

person zivkan    schedule 27.08.2019
comment
Это должно было сработать, но не сработало, все равно проголосовал. Я подозреваю, что это проблема: github.com/aspnet/AspNetCore/issues/2166, и предложенные обходные пути тоже не работают. - person cat_in_hat; 27.08.2019
comment
В итоге я решил проблему, выполнив это ПЛЮС, разделив все файлы TypeScript на их собственный проект NodeJS. - person cat_in_hat; 27.08.2019