I've created new solution in Visual Studio, enable nuget package restore and got in soluition root .nuget folder which contains the following files needed to make package restore work: NuGet.exe, NuGet.config, NuGet.targets.
But I can't make nuget(as Nuget Visual Studio add-in and \.nuget\NuGet.exe as well) read setting from .\nuget\NuGet.config file - settings are still read from default %appdata%\NuGet\NuGet.config.
What have I tried.
I've tried to look where the path to NuGet.config is specified and haven't found anything like that, and nuget.exe install command that runs during build doesn't have any parameter saying like "take this nuget.config file".
Also I've removed \.nuget\NuGet.config and everything works - packages are restored during Visual Studio build and CI one.
Question.
I've got an impression that \.nuget\NuGet.config isn't used at all.
So essentially the question is: How to make .nuget\NuGet.Config file to be not ignored?
What am I doing wrong and how to do it write?
Thanks and have a nice %time_of_day% :)
Disclaimer
Everything that I've mentioned above is not a problem/issue - current nuget behavior is completely acceptable for me - I'm asking just because I'm curious and confused at the same time
I haven't tried this personally, but here is what the official Nuget 2.1 release notes say:
NuGet.config files are searched for in the following order:
.nuget\nuget.config
Recursive walk from project folder to root
Global nuget.config (%appdata%\NuGet\nuget.config)
The configurations are than applied in the reverse order, meaning that
based on the above ordering, the global nuget.config would be applied
first, followed by the discovered nuget.config files from root to
project folder, followed by .nuget
If this doesn't help I'd suggest you write more specifically what you're trying to achieve and which config settings you're changing - knowing more details about the problem may clarify the situation.
Did you point the config file that you want to use as ?
In nuget page example;
nuget config -set repositoryPath=c:\packages -configfile c:\my.config
nuget config -set repositoryPath=c:\packages -configfile .\myApp\NuGet.Config
nuget config -set repositoryPath=c:\packages -configfile %ProgramData%\NuGet\Config\VisualStudio\14.0\NuGet.Config
nuget config -set repositoryPath=c:\packages -configfile %ProgramData%\NuGet\NuGetDefaults.Config
Related
I have a .NET Core 2 application and I'm trying to reference a NuGet package which contains static files and have them copied to my application similarly to how the "content" directory worked in the past.
According to the following https://blog.nuget.org/20160126/nuget-contentFiles-demystified.html this looks to be supported under a "contentFiles" directory.
I've found the following package which looks to support the new schema:
https://www.nuget.org/packages/ContentFilesExample/
And added a reference to it by adding the following to my .csproj file:
<PackageReference Include="ContentFilesExample" Version="1.0.2" />
Now when I run dotnet restore it doesn't copy anything to my application. I've been searching through the GitHub issues but it's hard to follow what is outdated and what is supported.
I'd appreciate it if someone could let me know if this is supported and what I could possibly be doing wrong. If it's not supported please could you point me in the direction of the correct GitHub issue to follow. Thanks
With PackageReference, the files are never copied over to the project. Rather the content files live in the global packages folder as immutable entities. You can still refer to these files as if these were expanded in your project.
If you use Visual Studio 2017, you can see these as refs as shown below. You can refer to .csproj.nuget.g.props file in the obj directory to find out the details of the files refs/links.
Have you looked at NuGet pkg Microsoft.AspNetCore.StaticFiles (2.0.0) ?
I have multiple .csproj files in my git source folder and its subfolders. I want to create NuGet packages for all of them. If I understand things correctly, I should add NuGet Packager build step and configure its Path to csproj or nuspec file(s) to pack to be
**\*.csproj
But no packages get created when I run my build.
By the way, if I manually select some 'csproj' file using "..." button and run build then package for it will be created.
Could anyone explain why I cannot use **\*.csproj matching pattern to create packages for all projects in my source directory and its subdirs? Is there any limit for nesting level or something? At least I have couple csproj files on maximum nested level 4-5 counting from the source folder...
p.s. I know there was a similar bug about Exclusion pattern not working for vsts build so I wonder if it's a related issue?
See my build configuration and log of my NuGet Packager and NuGet Publisher build steps where D:_work\3\s is the folder on a build server where it cannot find csproj files. Although I can see files there, for example the first is on D:_work\3\s\Source\Product\Components\Folder1\MyProj1.csproj, the second on D:_work\3\s\Source\Product\Components\Folder2\MyProj2.csproj, etc...
The level of nesting should not be an issue. I was able to setup a test project with 3 Projects at various levels and the single NuGet Task created a NuGet package for all of them.
Here is the configuration I used (It is the default configuration at this point in time). This was done using version 2.x of the task, so if you are using an earlier version you may want to upgrade.
You can also watch exactly what is happening during this step by setting system.debug = true when you queue the build. After you do this, you can look into the log for the Nuget Pack step and you should see it iterating through all of your directories and sub-directories and flagging those that match. Here you can see that it found and then continues to pack these 3 projects.
Post your detailed setup and log here if you still need additional assistance.
I had a similar issue. The NuGet Pack task finishes successfully, but didn't create a NuGet package.
In the task logging (when running with debug=true) I see the following:
...
##[debug]found 8037 paths
##[debug]applying include pattern
##[debug]0 matches
...
The NuGet Pack task doesn't create a package because it didn't find any .csproj or .nuspec file. In my case the reason it didn't find any .csproj or .nuspec file is because the work folder of my build agent is set to ".". I found this when analysing the pattern in the logs of the NuGet Pack task.
...
##[debug]pattern: 'D:\Agents\agent_1\.\123\s\*.nuspec'
...
The fix for this issue is changing the workFolder in the .agent file of the build agent. You can find this in the root folder of the build agent (e.g. D:\Agents\agent_1\.agent). Originally this was:
{
"agentId": 48,
"agentName": "agent_1",
"poolId": 3,
"serverUrl": "<TFS url>",
"workFolder": "."
}
And you have to change it to
{
"agentId": 48,
"agentName": "agent_1",
"poolId": 3,
"serverUrl": "<TFS url>",
"workFolder": "D:\\Agents\\agent_1"
}
Be sure to restart the build agent windows service after changing this file!
Hope this helps :-)
I've just started trying to configure a CI/CD process using Visual Studio Team Services, with a view to having a gated check-in process which then automatically packs and pushes the output to a private NuGet Feed. I'm successfully getting through the "Get Sources" task which exists natively in the build definition, however my package task is failing at this stage:
d:\a\_tool\NuGet\4.0.0\x64\nuget.exe pack
d:\a\1\s\Core\Core\Core.csproj -NonInteractive -
OutputDirectory d:\a\1\a -Properties Configuration=$Release;OutDir=$(OutDir)
-Symbols -version 1.0.0-CI-20170811-095629 -Verbosity Detailed
NuGet Version: 4.0.0.2283
Attempting to build package from 'Core.csproj'.
MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin\amd64'. Use option -MSBuildVersion to force nuget to use a specific version of MSBuild.
NuGet.CommandLine.CommandLineException: Unable to find 'd:\a\1\s\Core\Core\$(OutDir)\Core.dll'. Make sure the project has been built.
Essentially, the 2nd line of the log demonstrates that my project file is in d:\a\1\s, however the output is directed to d\a\1\a - not the same place. The instruction to NuGet to package my file then looks in the correct location (d:\a\1\s), but the file isn't here.
I understand that I can specify a Package Folder within the build definition, however I've not changed this from the default ($(Build.ArtifactStagingDirectory)) - I expect this to work natively, but for reasons I can't explain, it's not.
Is there a token or wildcard I can provide in an additional build property that will rectify this? I've taken the guidance of the first posted answer in here and changed $(Build.ArtifactStagingDirectory) to $(Build.Repository.LocalPath), which gets me much closer to the goal as the error now reads -OutputDirectory d:\a\1\s\... - I've tried manually putting a variety of sensible paths no the end of this, but the error persists.
Refer to this article. It has the build variables for the TFS/VSTS environment.
$(Build.ArtifactStagingDirectory) itself refers to the \1\a folder. You might want to try the $(Build.Repository.LocalPath) variable.
Not a 100% if it would work, but might as well try.
The issue is related to OutDir=$(OutDir) instead of OutputDirectory.
The OutputDirectory specifies the folder in which the created package is stored and the OutDir specifies the build output, but the project need to be built before NuGet pack task, so you need to add Visual Studio Build task or related to build project.
You can leave Additional build properties box blank to use default output per to configuration, because you just need to know the package stored path to push package to remote feed.
If you want to change build output, you can specify /p:OutDir msbuild argument to change build output location. For example:
Visual Studio Build task (MSBuild Arguments: /p:OutDir=$(Build.ArtifactStagingDirectory))
NuGet pack task (Additional build properties: OutDir=$(Build.ArtifactStagingDirectory))
BTW, to change package stored location, you need to specify OutputDirectory.
I had a package repository (cache) set to some place on disk, centrally, using the repositoryPath NuGet.config setting.
Then I changed my mind about using that, since the path gets added to the HintPath in the proj file uses a relative path that won't work on colleagues' machines.
Trouble is, now the HintPaths need fixing to ..\packages\etc so I thought I'd just run Update-Package Whatever -Reinstall with the package source in the Package Manage Console set to our TeamCity feed.
That reinstalls them all, sure, but the HintPaths didn't get updated!
Why not?
It did.
I just hadn't saved all! So the diff tool didn't see any changes.
I have found a dll that is provided via Google Code and I couldn't find it in NuGet. I want this package to be available via a NuGet install, because I want to reuse it in several packages and NuGet seems like the perfect way to do this.
https://code.google.com/p/protobuf-remote/downloads/list
Is it possible for me to generate a nupkg out of these dll's and publish it to NuGet.org? What are the legal limitations to this action?
There are a number of other users that have run into this issue. It seems like the common solution is to create an "Unofficial" package and reference that for the time being (until Google publishes their library as a NuGet). Just make sure to very clearly label the package as unofficial. See these examples.
As for the legal ramifications...
Please look through protobuf-remote license and review the distribution and derived works details. Currently the license is GNU Lesser GPL. Sorry, but you'll have to make your own call on if publishing the NuGet package would be permitted under this license. ;)
I would recommend you instead create a local NuGet package source by pointing to a file share. This can be local on your computer or on a network file share.
Also, if you don't want to update every workstation, you can update the NuGet.config file in your project to point to this source and commit that config file in your source control repository for all users to get automatically. Just note that any change to a NuGet.config file requires you to restart Visual Studio.
And FYI, take a look at how you can chain multiple NuGet.config files.