csproj reference local nuget package folder











up vote
0
down vote

favorite












I had to transfer my project over to Microsoft to look into a LiveUnitTesting bug, and the agent I got said there's too many errors to look at and he doesn't want to bother.



enter image description here



Okay so clearly my csproj has ......packages which really is the root of C where nuget is pointing.



Is there no variable I can place in my csproj that would tell VS to "just use whatever location the local nuget uses"



Like {NugetPath}Castle.Core.4.2.1libnet45Castle.Core.dll or something?










share|improve this question


























    up vote
    0
    down vote

    favorite












    I had to transfer my project over to Microsoft to look into a LiveUnitTesting bug, and the agent I got said there's too many errors to look at and he doesn't want to bother.



    enter image description here



    Okay so clearly my csproj has ......packages which really is the root of C where nuget is pointing.



    Is there no variable I can place in my csproj that would tell VS to "just use whatever location the local nuget uses"



    Like {NugetPath}Castle.Core.4.2.1libnet45Castle.Core.dll or something?










    share|improve this question
























      up vote
      0
      down vote

      favorite









      up vote
      0
      down vote

      favorite











      I had to transfer my project over to Microsoft to look into a LiveUnitTesting bug, and the agent I got said there's too many errors to look at and he doesn't want to bother.



      enter image description here



      Okay so clearly my csproj has ......packages which really is the root of C where nuget is pointing.



      Is there no variable I can place in my csproj that would tell VS to "just use whatever location the local nuget uses"



      Like {NugetPath}Castle.Core.4.2.1libnet45Castle.Core.dll or something?










      share|improve this question













      I had to transfer my project over to Microsoft to look into a LiveUnitTesting bug, and the agent I got said there's too many errors to look at and he doesn't want to bother.



      enter image description here



      Okay so clearly my csproj has ......packages which really is the root of C where nuget is pointing.



      Is there no variable I can place in my csproj that would tell VS to "just use whatever location the local nuget uses"



      Like {NugetPath}Castle.Core.4.2.1libnet45Castle.Core.dll or something?







      nuget csproj






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked 2 days ago









      Steve McNiven-Scott

      573416




      573416
























          1 Answer
          1






          active

          oldest

          votes

















          up vote
          1
          down vote



          accepted










          TL;DR Consider migrating from packages.config to PackageReference.



          Long version:



          "Normally" packages are restored automatically on build, and the only ways I know for this to be disabled is either a nuget.config setting, or a Visual Studio setting. It doesn't make sense to me why an agent whose responsibility is to investigate issues using other people's code would disable automatic package restore, so I can only assume that either your repo has disabled it, or there's something non-standard with your project that caused it to fail on the agent's machine. New projects from templates do not have this problem.



          Anyway, this is not what your question asked. The answer to your question is no, there's no built-in MSBuild property that points to the NuGet restore folder.



          However, projects using PackageReference for NuGet dependencies, instead of packages.config, do not modify the csproj to add paths to assembly files. It's calculated automatically at build time, so there is less risk of build failures when people clone your repo at different locations to where you cloned yours, or if you move code around your repo, it will not require modifications to the csproj, only run a nuget restore.



          I assume the reason you're using a packages folder outside the repo is to share the folder with multiple repos and therefore save disk space. PackageReference does this automatically. It no longer creates a package folder per repo/solution, and builds use the assemblies directly from the global packages folder.






          share|improve this answer





















          • Man, i thought i HAD migrated 😑
            – Steve McNiven-Scott
            2 days ago










          • PackageReference no longer puts <Reference /> elements to assembles in the csproj, so if you tried to migrate manually (for example deleting the packages.config file and adding PackageReference>, it's an incomplete migration. not only do the correct Reference elements need to be deleted, there's possibly props and targets Imports that need to be deleted, and maybe other things I don't know about.
            – Ziv
            2 days ago











          Your Answer






          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "1"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














           

          draft saved


          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53343654%2fcsproj-reference-local-nuget-package-folder%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          1
          down vote



          accepted










          TL;DR Consider migrating from packages.config to PackageReference.



          Long version:



          "Normally" packages are restored automatically on build, and the only ways I know for this to be disabled is either a nuget.config setting, or a Visual Studio setting. It doesn't make sense to me why an agent whose responsibility is to investigate issues using other people's code would disable automatic package restore, so I can only assume that either your repo has disabled it, or there's something non-standard with your project that caused it to fail on the agent's machine. New projects from templates do not have this problem.



          Anyway, this is not what your question asked. The answer to your question is no, there's no built-in MSBuild property that points to the NuGet restore folder.



          However, projects using PackageReference for NuGet dependencies, instead of packages.config, do not modify the csproj to add paths to assembly files. It's calculated automatically at build time, so there is less risk of build failures when people clone your repo at different locations to where you cloned yours, or if you move code around your repo, it will not require modifications to the csproj, only run a nuget restore.



          I assume the reason you're using a packages folder outside the repo is to share the folder with multiple repos and therefore save disk space. PackageReference does this automatically. It no longer creates a package folder per repo/solution, and builds use the assemblies directly from the global packages folder.






          share|improve this answer





















          • Man, i thought i HAD migrated 😑
            – Steve McNiven-Scott
            2 days ago










          • PackageReference no longer puts <Reference /> elements to assembles in the csproj, so if you tried to migrate manually (for example deleting the packages.config file and adding PackageReference>, it's an incomplete migration. not only do the correct Reference elements need to be deleted, there's possibly props and targets Imports that need to be deleted, and maybe other things I don't know about.
            – Ziv
            2 days ago















          up vote
          1
          down vote



          accepted










          TL;DR Consider migrating from packages.config to PackageReference.



          Long version:



          "Normally" packages are restored automatically on build, and the only ways I know for this to be disabled is either a nuget.config setting, or a Visual Studio setting. It doesn't make sense to me why an agent whose responsibility is to investigate issues using other people's code would disable automatic package restore, so I can only assume that either your repo has disabled it, or there's something non-standard with your project that caused it to fail on the agent's machine. New projects from templates do not have this problem.



          Anyway, this is not what your question asked. The answer to your question is no, there's no built-in MSBuild property that points to the NuGet restore folder.



          However, projects using PackageReference for NuGet dependencies, instead of packages.config, do not modify the csproj to add paths to assembly files. It's calculated automatically at build time, so there is less risk of build failures when people clone your repo at different locations to where you cloned yours, or if you move code around your repo, it will not require modifications to the csproj, only run a nuget restore.



          I assume the reason you're using a packages folder outside the repo is to share the folder with multiple repos and therefore save disk space. PackageReference does this automatically. It no longer creates a package folder per repo/solution, and builds use the assemblies directly from the global packages folder.






          share|improve this answer





















          • Man, i thought i HAD migrated 😑
            – Steve McNiven-Scott
            2 days ago










          • PackageReference no longer puts <Reference /> elements to assembles in the csproj, so if you tried to migrate manually (for example deleting the packages.config file and adding PackageReference>, it's an incomplete migration. not only do the correct Reference elements need to be deleted, there's possibly props and targets Imports that need to be deleted, and maybe other things I don't know about.
            – Ziv
            2 days ago













          up vote
          1
          down vote



          accepted







          up vote
          1
          down vote



          accepted






          TL;DR Consider migrating from packages.config to PackageReference.



          Long version:



          "Normally" packages are restored automatically on build, and the only ways I know for this to be disabled is either a nuget.config setting, or a Visual Studio setting. It doesn't make sense to me why an agent whose responsibility is to investigate issues using other people's code would disable automatic package restore, so I can only assume that either your repo has disabled it, or there's something non-standard with your project that caused it to fail on the agent's machine. New projects from templates do not have this problem.



          Anyway, this is not what your question asked. The answer to your question is no, there's no built-in MSBuild property that points to the NuGet restore folder.



          However, projects using PackageReference for NuGet dependencies, instead of packages.config, do not modify the csproj to add paths to assembly files. It's calculated automatically at build time, so there is less risk of build failures when people clone your repo at different locations to where you cloned yours, or if you move code around your repo, it will not require modifications to the csproj, only run a nuget restore.



          I assume the reason you're using a packages folder outside the repo is to share the folder with multiple repos and therefore save disk space. PackageReference does this automatically. It no longer creates a package folder per repo/solution, and builds use the assemblies directly from the global packages folder.






          share|improve this answer












          TL;DR Consider migrating from packages.config to PackageReference.



          Long version:



          "Normally" packages are restored automatically on build, and the only ways I know for this to be disabled is either a nuget.config setting, or a Visual Studio setting. It doesn't make sense to me why an agent whose responsibility is to investigate issues using other people's code would disable automatic package restore, so I can only assume that either your repo has disabled it, or there's something non-standard with your project that caused it to fail on the agent's machine. New projects from templates do not have this problem.



          Anyway, this is not what your question asked. The answer to your question is no, there's no built-in MSBuild property that points to the NuGet restore folder.



          However, projects using PackageReference for NuGet dependencies, instead of packages.config, do not modify the csproj to add paths to assembly files. It's calculated automatically at build time, so there is less risk of build failures when people clone your repo at different locations to where you cloned yours, or if you move code around your repo, it will not require modifications to the csproj, only run a nuget restore.



          I assume the reason you're using a packages folder outside the repo is to share the folder with multiple repos and therefore save disk space. PackageReference does this automatically. It no longer creates a package folder per repo/solution, and builds use the assemblies directly from the global packages folder.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered 2 days ago









          Ziv

          744416




          744416












          • Man, i thought i HAD migrated 😑
            – Steve McNiven-Scott
            2 days ago










          • PackageReference no longer puts <Reference /> elements to assembles in the csproj, so if you tried to migrate manually (for example deleting the packages.config file and adding PackageReference>, it's an incomplete migration. not only do the correct Reference elements need to be deleted, there's possibly props and targets Imports that need to be deleted, and maybe other things I don't know about.
            – Ziv
            2 days ago


















          • Man, i thought i HAD migrated 😑
            – Steve McNiven-Scott
            2 days ago










          • PackageReference no longer puts <Reference /> elements to assembles in the csproj, so if you tried to migrate manually (for example deleting the packages.config file and adding PackageReference>, it's an incomplete migration. not only do the correct Reference elements need to be deleted, there's possibly props and targets Imports that need to be deleted, and maybe other things I don't know about.
            – Ziv
            2 days ago
















          Man, i thought i HAD migrated 😑
          – Steve McNiven-Scott
          2 days ago




          Man, i thought i HAD migrated 😑
          – Steve McNiven-Scott
          2 days ago












          PackageReference no longer puts <Reference /> elements to assembles in the csproj, so if you tried to migrate manually (for example deleting the packages.config file and adding PackageReference>, it's an incomplete migration. not only do the correct Reference elements need to be deleted, there's possibly props and targets Imports that need to be deleted, and maybe other things I don't know about.
          – Ziv
          2 days ago




          PackageReference no longer puts <Reference /> elements to assembles in the csproj, so if you tried to migrate manually (for example deleting the packages.config file and adding PackageReference>, it's an incomplete migration. not only do the correct Reference elements need to be deleted, there's possibly props and targets Imports that need to be deleted, and maybe other things I don't know about.
          – Ziv
          2 days ago


















           

          draft saved


          draft discarded



















































           


          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53343654%2fcsproj-reference-local-nuget-package-folder%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          "Incorrect syntax near the keyword 'ON'. (on update cascade, on delete cascade,)

          Alcedinidae

          RAC Tourist Trophy