2016-06-16 2 views
2

У меня есть проект, который, в свою очередь, ссылается на вилку официальной библиотеки nuget'd (прогноз.io). Я уладил свой global.json, чтобы найти свою копию lib, но все же, похоже, доходит до официальной версии, а не моей вилки..NET Core RC2: используйте локальный вилок пакета

я формирую этот вывод, потому что я получаю ошибку:

Package Forecast.io 1.0.0 is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0). Package Forecast.io 1.0.0 supports: net45 (.NETFramework,Version=v4.5) 
One or more packages are incompatible with .NETCoreApp,Version=v1.0. 

Но моя вилка forecast.io не даже предназначаться .NET 4.5 - только «net40» и «netcoreapp1.0».

Как я могу убедиться, что вместо этого используется моя локальная вилка?

Вот мой global.json

{ 
    "projects": [ 
    "../../ext/forecast.io-csharp/src/Forecast.io", 
    "MyOtherLibRefWhichWorks", 
    "MyPrimaryProject" 
    ] 
} 

И отрывок из project.json от основного проекта:

"dependencies": { 
    "Microsoft.NETCore.App": { 
     "type": "platform", 
     "version": "1.0.0-rc2-3002702" 
    }, 
    "MyOtherLibRefWhichWorks": "1.0.0-*", 
    "Forecast.io": "1.0.0-*", 

EDIT: Похоже, global.json идет полностью игнорируется. Он расположен в одном каталоге выше, где расположен project.json ..

+0

Вы пробовали '' Forecast.io ": {" target ":" project "}'? – svick

+0

Выполнение этого результата в «Невозможно разрешить« Forecast.io »(я применил изменение к project.json) - кажется потенциальным шагом вперед, предполагая, что global.json каким-то образом игнорируется – Malachi

+0

Что происходит, когда вы добавляете текущий проект в глобальный .json тоже? – svick

ответ

1

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

Чтобы сделать это локально, вам просто нужна пустая папка и Nuget CLI. Если папка C:\Nuget запустите

nuget add package.nupkg -source C:\Nuget 

Чтобы добавить свой раздвоенный пакет местного сырья. Чтобы убедиться, что нет путаницы, создайте свой разветвленный пакет с другим именем или номером версии, чем официальный пакет.

Затем настройте NuGet использовать локальный канал в качестве источника:

nuget sources Add -Name LocalNuget -Source C:\Nuget 

После этого все настройки, обновите ваш project.json ссылаться на свой раздвоенный пакет и запустить dotnet restore снова рушить локальную копию.

Если вам необходимо восстановить пакет на нескольких компьютерах или в командной среде, вы можете настроить свой собственный сервер NuGet или использовать MyGet.org для размещения вашего пакета.

+0

Это хорошо работает, почти так же, как указано (nuget add не существует для меня, поэтому я просто скопировал nupkg вручную). Тем не менее, меня волнует а) неизбежное отторжение версии-имени в project.json и b) требуется установка для каждой машины - хотя и не потрясающая – Malachi

+0

Вы можете скачать 'nuget.exe' из приведенной выше ссылки и поместить ее в свой PATH, если вы хотите использовать CLI. Вы правы, это не сработает для команды, если вы не поместите пакет в общую сетевую папку. Лучшим решением в этом случае будет MyGet! –

+0

@ Malachi Что вы подразумеваете под «неизбежным изменением названия версии»? –

Смежные вопросы