Гарантировать ту же версию пакетов nuget

Ответ 1

Оказывается, вы можете вызвать Install-Package $package.Id -version <someVersion> внутри Install.ps1, который затем приведет к удалению изначально установленной версии и установленной версии.

Несколько упрощенная версия выглядит следующим образом:

param($installPath, $toolsPath, $package, $project)

function GetInstallingVersion() {
    $package.Version
}

# Gets the current version of the used framework. 
# If no framework is yet installed, we set the framework version 
# to the one that being installed right now.
function GetCurrentFrameworkVersion() {
    $solutionPath = Split-Path $dte.Solution.FileName
    $fwkVersionFile = "${solutionPath}\framework_version.txt"
    if (Test-Path $fwkVersionFile) {
        return Get-Content $fwkVersionFile
    } 
    else {
        $installingVersion = GetInstallingVersion
        $installingVersion > $fwkVersionFile
        return $installingVersion
    }
}

$currentFwkVersion = GetCurrentFrameworkVersion
$installingVersion = GetInstallingVersion

if ($currentFwkVersion -ne $installingVersion) {
    Install-Package $package.Id -version $currentFwkVersion
}

Ответ 2

вы можете ограничить версию своего пакета, используя следующий синтаксис в вашем файле packages.config:

<package id="jQuery" version="1.9.1" allowedVersions="[1.9.1]" />

Также из оригинальной документации nuget: Когда вы создаете пакет NuGet, вы можете указать зависимости для пакета в файле .nuspec.

<dependency id="ExamplePackage" version="[1,3)" />

В этом примере допустимы версии 1 и версии 2.9, но не 0,9 или 3,0.

Я предполагаю, что вы можете ограничить его таким образом до одного или нескольких диапазонов версий. Здесь вы можете узнать больше об этом.

Ответ 3

Я бы вырвал "пакет NuGet решения уровня решения" и разделил вашу структуру на компоненты и создавал пакет NuGet для каждого компонента. Никто не будет иметь один единственный проект, который ссылается на пакет NuGet "Framework Wrapper", а также код для бизнес-логики, доступа к данным и WCF внутри этого единого проекта.

Тогда то, что вам нужно сделать, заключается в том, чтобы скрыть, какова ваша логика зависимости, и какова причина того, что вы хотите строго придерживаться политики одинаковой версии.

Например, скажем, что My.Framework.BL имеет зависимость от My.Framework.DAL. Итак, на данный момент у вас есть только 2 файла Nuspec и 2 пакета NuGet, с .nuspec вашего My.Framework.BL выглядит так:

<dependencies>
  <dependency id="My.Framework.DAL" version="1.0.0" />
</dependencies>

И с вашим My.Framework.DAL, не содержащим зависимых от My.Framework зависимостей.

Это хорошо, и ваше решение о том, чтобы сильно связать число, связанное с версией, проблематично по нескольким причинам. Первым и самым важным является то, что он смутит ваших пользователей инфраструктуры, если вы обновите My.Framework.DAL, если у него есть 0 изменений, но вам пришлось обновить его, потому что вы изменили My.Framework.BL.

Вы могли бы пройти месяц или, возможно, и не должны обновлять зависимость My.Framework, в зависимости от уровня абстракции вашей структуры и от того, какую степень низкоуровневого программирования вы делаете. На мой взгляд, необходимость обновлять версии dll Core Framework при отсутствии каких-либо новых изменений - это БОЛЬШАЯ БОЛЬШАЯ проблема, чем номера версий всех DLL My.Framework. Приветствия.:)

Здесь - ссылки duspec ссылок.