none
Unable to deploy local nuget packages

    Question

  • Hi,

    we are developping applications using nuget packages deployed locally.

    Using the latest version 3 of Visual Studio 2015, we are adding the local directory as a the source of the packages. It is all working fine, the nuget packages are properly deployed into the c:\Users\olivierr\.nuget\packages\ directory, and applications can be built and run.

    Using the latest Visual Studio 2017, we proceed exactly the same way, but it appears nuget packages are not deployed into the c:\Users\olivierr\.nuget\packages\ directory.

    We then have error messages such as "Unable to resolve "***.uwp" for 'UAP".

    What may have changed in between both flavors of the Visual Studio? Is it still possible to use nuget packages from local directory? Is there something that may have been missed in the nuget packages?

    Thank you,

    Best regards,

    Olivier

    Friday, March 24, 2017 4:31 PM

All replies

  • Hi Olivier Rocher,

    Welcome to MSDN forum.

    >>>but it appears nuget packages are not deployed into the c:\Users\olivierr\.nuget\packages\ directory.

    Whether you can find the local package from the NuGet Package Manager UI? Tools->NuGet Package Manager->Manage NuGet Package for Solution.... If yes, the nuget packages deployed locally should be successfully, this issue should not related to the nuget local directory. If not, please try to use other local package folder, such as, D:\NuGetLocalServe.

    >>>What may have changed in between both flavors of the Visual Studio? Is it still possible to use nuget packages from local directory? Is there something that may have been missed in the nuget packages?

    As far as I know, there is no change about the nuget local directory in between both flavors of the Visual Studio. And you can use the nuget package from the local directory in the Visual Studio.

    If above could not help you, would you mind sharing me the detail information about the error messages or a sample to reproduce this issue? Thanks.


    MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Sunday, March 26, 2017 9:45 AM
  • Dear Leo Liu,

    thank you for the update.

    On our side, we finnally found a workaround, which consists in adding the nuget packages in command line under terminal:

    To proceed:
    -Let's say our solution is deployed in c:/temp directory
    -The nuget files are then located into the c:/temp/Packages directory
    -The whole solution MySolution.sln is located into the c:/temp/Samples directory
    -call nuget restore as follows: nuget restore -Source "nuget directory" "MySolution.sln": nuget restore -Source C:\temp\Packages "C:\temp\Samples\MySolution.sln"

    Do you have any idea what may be missing in our solution that would explain it works while using nuget restore in command line, while it is not workng from Visual Studio 2017?

    Thank you,

    Best regards,

    Olivier

    Wednesday, March 29, 2017 12:07 PM
  • @Olivier Rocher, thanks for you reply.

    >>>Do you have any idea what may be missing in our solution that would explain it works while using nuget restore in command line, while it is not workng from Visual Studio 2017?

    What is version of the nugget.exe that you used in command line? The reason for the different results is that the different version of nuget.exe. The version of nugget is 4.0 in the Visual Studio 2017.

    Since you have found a workaround for the question, you can mark it as answer temporarily which is benefit to other communities who has the same problem before you get a better solution. Thanks.


    MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.


    Thursday, March 30, 2017 4:09 AM