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.
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
add a comment |
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.
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
add a comment |
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.
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
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 2 days ago
Steve McNiven-Scott
573416
573416
add a comment |
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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 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
add a comment |
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
add a comment |
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