I have a project that consumes a NuGet package from a private NuGet feed. I also have a source code of that package in a separate project/solution. When I work on the project I want to be able to, temporarily add the mentioned source code of the package to the solution, so i can work on changes in both the project and nuget package simultaneously.
In Visual Studio 2015, with dotnet core and project.json/global.json I could add the NuGet package to the project and then modify the global.json to include the source from the disk.
global.json:
{
"projects" : [ "src", "../<path_to_external_source>/src" ]
}
That would, temporarily, change the reference to the project on disk. Before pushing to the build server, I'd just remove one line from global.json and remove projects from solution.
In Visual Studio 2017 and csproj based dotnet core I cant't seem to get that functionality. I have to remove the nuget package, add source code manually through "add/existing project" to solution, then manually add reference instead removed NuGet references. Then reverse all that before pushing to build server.
It's especially problematic when solution has several projects consuming the NuGet package, and I need to go thorugh that process with every one of them.
Is there a way to reproduce the functionality of global.json in VS17?
Related
I have a library of nuget packages we use throughout our solutions, hosted in Azure Artifacts. These nuget packages are built with debug enabled so symbols are created and included in nuget packages.
Our projects in Visual Studio (mainly Net Core 3.1) reference these nuget packages in the normal way using Nuget Package Manager.
Each solution has SourceLink enabled so if I have any debugging requirements which require stepping into code within the referenced nuget package, I can set a breakpoint and do so quite nicely as Visual Studio downloads the sourcecode directly from Azure Artifacts.
That all works perfectly.
The issue is a productivity one. If code within the nuget package needs to be changed, I have to open the solution for the nuget package, change it, push it and wait for Azure to build. When built, I go to Nuget Package Manager, update the package, restart the app and 'hopefully' have resolved the issue. For something tricky, I can loop this process a few times which is a productivity killer.
Is there any way to debug directly in the solution for the nuget package from the solution referencing it? Or does anybody have a better process they use which is more productive?
You may try to use floating version that can resolve to the latest version in nuget. In this way, when there is updated package, your solution will load the latest version of the package during build.
<ItemGroup>
<PackageReference Include="NuGet.Packaging" Version="*" />
</ItemGroup>
Is there any way to debug directly in the solution for the nuget package from the solution referencing it?
Using project reference instead of the nuget package when you need to frequently modify and debug the source code in the nuget package.
When you consider production efficiency, please consider using project reference, when you consider portability, please try to use nuget. You could check my previous thread for detailed explanation.
For your situation, you could add the project for the nuget package to your referencing solution by the option Existing project：
Then select the project file .csproj for the nuget package.
After adding that project into your solution, you could add that project as project reference for your referencing project. Now, you could directly modify and debug the project for the nuget package.
When you finish this stage of work, you can return to the solution where the project for the nuget package is located, pack the new version of the nuget package and publish it.
We have moved a legacy web site to git in TFS, and anytime the project is cloned nugget restores the packages per the package.config, and adds them to the packages folder. The subsequent build fails due to not being able to find the assemblies added through the nuget restore.
If you do a update-package -reinstall and the project builds successfully. Is this expected behavior or do I have a setup issue? The previous repo had the packages being checked in to eliminate this issue but I'd like to avoid that.
Is this expected behavior or do I have a setup issue?
Yes, this is expected behavior for NuGet, so do not worry that it is a setup problem.
NuGet Restore only restores files in the packages directory (\packages folder ), but does not restore files inside your project or otherwise modify your project. For example, if a package has added some reference DLLs or other files in your project, if you delete any of these files, they will not be re-added when restoring this package. This may cause the your project to not be able to find the missing dependencies when building.
Besides, the expected result is that the references should be used normally without broken after restore packages. In this case, we will not need to spend extra time using update-package -reinstall command line to uninstall and reinstall packages.
So use the "Update-Package -reinstall" command to force reinstall the package references and content files into project in order to resolve those references that were broken after packages restore.
I have a pretty simple application with some NuGet references and it works fine locally. I have not committed the packages folder of course, just the config. When I have TeamCity build the solution, I originally got the error that I needed to enable Nuget Package Restore so I did.
Now when I build I get the message
The build restored NuGet packages. Build the project again to include these packages in the build. For more information, see http://go.microsoft.com/fwlink/?LinkID=317568.
Makes sense, but I get this error no matter how many times I build it. It continually fails. Am I missing something here?
Run the NuGet package restore before you build the solution.
Team City should have a NuGet Installer step which will restore the NuGet packages. Add this to your build steps before the compilation of the solution.
You an also do this yourself with a build step which runs:
NuGet.exe restore YourSolution.sln
However Team City's built in NuGet build step allows you to configure other things, such as private NuGet repository urls, easier than creating your own build step from scratch.
For a github hosted open sourced C# project which is also available via NuGet, how should one organize the source? Specifically:
should the .nuspec file be in the github repository?
should the .nuspec file be in the same folder as the .csproj file?
how about the NuGet package tree (the /lib, /content stuff), since is generated, should it be in git?
My thinking is that the NuGet part is separate from the github hosting, as in the project source are available but the .nuspec is not, since the publishing in NuGet is not an open source operation per-se. None wants that every fork to build and publish a new NuGet package, so that the open source Foo package ends up in the gallery as 'Rick's Foo' vs. 'John's Foo' vs. 'Alice's Foo' etc.
But on the other hand I do want the github source depot to act as a one-stop repository for the project, if I open my other laptop and enlist from there, I should be able to build/package/push w/o recreating the whole NuGet infrastructure from scratch (ie. only enter my API key, nothing more).
These two requirements are contradicting each other, Did I miss something obvious?
I would do the following:
Commit the .nuspec file next to the .csproj file
Add a nuget.config file which moves the packages folder a level up.
Enable package restore in the solution and do NOT commit the content of the NuGet package repository
Create an msbuild file (or whatever build vehicle you like) which has:
a "build" target which builds the source and creates the nuget package
a "publish" target which pushes the NuGet package to nuget.org and takes your API key as a parameter.
I personally maintain the version number of the nuget package in the .nuspec file and manually update it when I do a "release". This way I can tag the exact release I pushed to the NuGet feed.
With this setup a build in Visual Studio does not produce a NuGet package but all tools are available in the repository to do so.
The Folder Structure looks like this:
.\Docs\ ==> not in source repo
.\Packages\ ==> not under source control
.\Src\ ==> git repo here
.\Src\MySolution.sln
.\Src\.gitignore
.\Src\MuRules.ruleset
.\Src\build.proj ==> msbuild file to build everything.
.\Src\MyProject\MyProject.csproj
.\Src\MyProject\MyProject.nuspec
.\Src\MyProject\nuget.config
.\Build\ ==> not under source control
.\Build\Debug\
.\Build\Release\
.\Build\Publish\
Be aware of this bug in the Package Restore feature, it will ignore the packages location you configured. http://nuget.codeplex.com/workitem/1990 ==> This is fixed in Nuget 2.7
On nuget v2.8, I just need to modify .gitignore and add:
packages/
This will exclude the nuget packages folder from committing. When you build the new checked-out source code, the packages would be downloaded and restored. Make sure package restore setting has been enabled but I think it's been enabled by default on v2.8.
For some reason Nuget ignores the default project I select from the drop down and always installs packages into my startup web project. I have a utility project, specifically for things like library dependencies and want Nuget to install packages there, but it always goes for the web project.
EDIT:
I eventually figured this out. It turns out that the solution file was under one particular projects directory. This was not how I normally create a solution, but I didn't create this originally so it didn't occur to me that this was the cause.
Try using command with project name
PM> Install-Package EntityFramework -ProjectName DataProvider
or Just right click on the Solution and select Manage NuGet Packages.
when you install it allows selecting the set of projects to install the package into.