csproj reference local nuget package folder
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
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.
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
asked Nov 16 '18 at 18:42
Steve McNiven-ScottSteve McNiven-Scott
636718
add a comment |
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.
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
asked Nov 16 '18 at 18:42
Steve McNiven-ScottSteve McNiven-Scott
636718
add a comment |
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.
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
asked Nov 16 '18 at 18:42
Steve McNiven-ScottSteve McNiven-Scott
636718
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.
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
nuget csproj
asked Nov 16 '18 at 18:42
Steve McNiven-ScottSteve McNiven-Scott
636718
asked Nov 16 '18 at 18:42
Steve McNiven-ScottSteve McNiven-Scott
636718
asked Nov 16 '18 at 18:42
Steve McNiven-ScottSteve McNiven-Scott
636718
asked Nov 16 '18 at 18:42
Steve McNiven-ScottSteve McNiven-Scott
636718
asked Nov 16 '18 at 18:42
Steve McNiven-ScottSteve McNiven-Scott
636718
636718
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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.
answered Nov 17 '18 at 0:00
zivkanzivkan
1,7691918
Man, i thought i HAD migrated 😑
– Steve McNiven-Scott
Nov 17 '18 at 0:03
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.
– zivkan
Nov 17 '18 at 0:07
add a comment |
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',
autoActivateHeartbeat: false,
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
answered Nov 17 '18 at 0:00
zivkanzivkan
1,7691918
Man, i thought i HAD migrated 😑
– Steve McNiven-Scott
Nov 17 '18 at 0:03
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.
– zivkan
Nov 17 '18 at 0:07
add a comment |
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.
answered Nov 17 '18 at 0:00
zivkanzivkan
1,7691918
Man, i thought i HAD migrated 😑
– Steve McNiven-Scott
Nov 17 '18 at 0:03
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.
– zivkan
Nov 17 '18 at 0:07
add a comment |
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.
answered Nov 17 '18 at 0:00
zivkanzivkan
1,7691918
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.
answered Nov 17 '18 at 0:00
zivkanzivkan
1,7691918
answered Nov 17 '18 at 0:00
zivkanzivkan
1,7691918
answered Nov 17 '18 at 0:00
zivkanzivkan
1,7691918
answered Nov 17 '18 at 0:00
zivkanzivkan
1,7691918
1,7691918
Man, i thought i HAD migrated 😑
– Steve McNiven-Scott
Nov 17 '18 at 0:03
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.
– zivkan
Nov 17 '18 at 0:07
add a comment |
Man, i thought i HAD migrated 😑
– Steve McNiven-Scott
Nov 17 '18 at 0:03
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.
– zivkan
Nov 17 '18 at 0:07
Man, i thought i HAD migrated 😑
– Steve McNiven-Scott
Nov 17 '18 at 0:03
Man, i thought i HAD migrated 😑
– Steve McNiven-Scott
Nov 17 '18 at 0:03
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.– zivkan
Nov 17 '18 at 0:07
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.– zivkan
Nov 17 '18 at 0:07
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
