I would like to provide a Visual Studio extension (.VSIX) which adds a local NuGet server to the list of NuGet servers. Is this possible? Is there a generic way to change Visual Studio options by a .VSIX??
Do you really need VSIX? List of NuGet servers (or more precisely, package sources) is kept in plain XML file at this path: %APPDATA%\NuGet\NuGet.Config
(Package source does not have to be a server, it could be a folder or network share as well.)
Related
I've added Autofac library using NuGet and I see it in my references as shown below.
But when I check the properties [F4] of Autofac by clicking on it, it shows empty property box in Visual Studio.
Also, I don't see Autofac folder under packages folder.
I see only Package reference in .csproj file. Then how does it locates the DLL? Where is the actual DLL? I see it's automatically coming inside BIN. How does it come?
Main Issue: Locally I'm able to build the solution but same solution fails on TFS build agents. It's unable to find the NuGet reference. So where can I find DLL references? or how to push it to TFS?
As #magicandre1981 already explained, with PackageReference style package referencing (as apposed to package.config-style, also see this for more background on the differences, in case you didn't know), the packages are not located in a per-solution packages-folder, but in a central one (by default %USERPROFILE%\.nuget\packages). Albeit you can easily change the location using the NUGET_PACKAGES environment variable (which also works as a TFS Build variable, because they are provided as environment variables to build steps).
Furthermore, inside Visual Studio you see no path, because the actual path to the DLL is determined at build time. You can see part of that path in your <project-dir>\obj\project.assets.json file (which is generated during the restore target/operation), but the full path you will only see in the MSBuild logs (for example when actually calling the csc.exe executable/C# compiler or during ResolveAssembyReferences-task).
Note that for .NET Core, i.e. "SDK style" projects, the path is actually shown in properties (as are the actual DLLs in a node underneath the "package" node.
One can only assume that the integration of PackageReference in "old" projects is not fully done yet (if ever).
For comparison a PackageReference in an "old" / non-SDK-style project:
You use the new Package Reference where the NuGet files get get stored into a cache:
Solution-local packages folders are no longer used – Packages are now
resolved against the user’s cache at %userdata%\.nuget, rather than
a solution specific packages folder. This makes PackageReference
perform faster and consume less disk space by using a shared folder of
packages on your workstation.
Assume you are using TFS 2015, the NuGet Restore task name should be NuGet Installer which under Package when you add tasks.
So, if you have installed Nuget in the build machine, then you can use the task directly.
You can also custom nuget.exe for TFS 2015 build -- Just specify the Path to NuGet.exe
You can refer to Mummy's blog- Custom nuget.exe for TFS 2015 build for details.
Add a NuGet Restore task to your build so that the packages are restored.
I am running NuGet.Server v2.8.60717.93, hosted on Azure. The server is running correctly, and I am able to see all the packages if I go to the following url:
https://***.azurewebsites.net/nuget/Packages
I am also able to publish new packages to the server using Nuget Package Explorer.
I added https://***.azurewebsites.net/nuget as a Package Source in Visual Studio. However it can't find any packages, it just says No items found.
To my understanding, Nuget will set /Packages as default package folder unless otherwise is specified. I even tried to set packagesPath to ~/Packages, still no luck.
What am I missing?
Also have this problem the RSS feed of package is showing in the browser if I navigate to https://***.azurewebsites.net/nuget/Packages but no items found in visual studio.
I have my own TFS (visual studio online) and work TFS. In my TFS located my own projects and, in particular, the project with useful utilities. I want to connect it to the work TFS solution, but keep getting an error, which essentially boils down to the fact that you can not connect a project in more than one TFS. Can I achieve the desired result?
No you cannot use multiple Team Foundation Server instances at one time. When you switch a project, you switch to the TFS server that it's stored in.
The recommended way to share utility code like you're talking about is by sharing only the binaries. This can be done using NuGet. You can setup your own NuGet repository and then let your utility project publish to your NuGet server. Other projects can include your NuGet packages just as you use external packages.
You can find a great overview of what NuGet can do here.
I've published some private/internal libraries as NuGet packages, using the symbols option. The packages and symbols are hosted on an internal network share. How can I step into these packages when debugging?
When I step to code from these packages, Visual Studio displays a "No Source Available" / "No Symbols Found" page. Clicking the "Load Symbols" only allows pdb files, not symbol packages.
These packages are not suitable for publishing on NuGet Gallery/SymbolSource.
What is the command that you used to generate the packages with the symbols? I tried to do the same exact thing nuget.exe pack -Prop Configuration=Release Framework.csproj -Symbols This creates two files: Framework.nupkg and Framework.symbols.nupkg. I put these files on a network share, used them from another project and debugging worked fine.
Have you tried putting the *.nupkg and *.symbols.nupkg files on a local disk instead of a network share?
There are a couple options; one is to set-up & configure your own symbol server.
You could also download Inedo's ProGet, enable symbol serving on the target feed, and then publish your packages to ProGet. All of this can be done with the free edition of ProGet.
disclaimer -- my day job is at Inedo
There is also now a tool called GitLink (https://github.com/GitTools/GitLink) which can insert into the symbol file links to versioned GIT files of your source.
You can set up your own symbolsource server internally using those network shares.
You can find a step-by-step tutorial on my blog.
It basically comes down to create an empty MVC application and run
Install-Package SymbolSource.Server.Basic
From there on you need to set up the hosting infrastructure and configure Visual Studio and build agents.
The way we do it (and works):
Generate "*.symbols.nupkg"
Deploy symbol package to SymbolSource server (private)
Configure IDE
Add required Library to project using NuGet (from our SymbolSource server)
Debug!
Links that can be useful:
SymbolSource server installation
Important: "Debugging Tools for Windows" won't install if it detects newer Visual C++ Redist version in the system than it needs/expects
Vs configuration to debug using SymbolSource
The URL to add is like http://your.symbolsource-server.com:[port]/[appContext]/WinDbg/pdb
I found that it doesn't work at all. NuGet package references are closed and cannot be used in the debugger. What I did instead was deleting the assembly reference from the project and instead added a reference to a Debug build of the DLL directly by path.
Then to make the debugger halt somewhere in that code, I inserted the call System.Diagnostics.Debugger.Break(); in that code. When running, the debugger will halt at that line, which is basically a code-defined breakpoint. This will open the correct source file and jump to that line automatically.
Open the library project in a second VS instance and move around the Break calls as necessary and rebuild the library. When done, remove those calls from the library code and restore the original reference (may need to reinstall the NuGet package).
I've added some libraries to a VS 2010 solution using Nuget (RestSharp, Twilio, etc.). When I pull the same solution down to a new PC from TFS and try to build it, all the references to those assemblies are broken (error "namespace cannot be found..."). Is it necessary for each developer who works on this VS solution for the first time to independently install the same Nuget packages on their PCs?
Thanks,
Jim
As Andrew already have said it's all about the packages' location.
Either you have to check in the entire packages folder with all the packages, or each developer have to install the packages after first checking out. But there is a better way to do this, namely to use NuGet Package Restore - which will automatically install all missing packages when the project is built.
If you use package restore, you only need to check in the repositories.config into your VCS. With TFS you can cloak the entire packages folder except for the repositories.config, so that TFS doesn't annoy with pending checkins for new packages.
Also see this answer for guidance on how to use TFS + NuGet.
No, but you need to be sure the assemblies are all included in the same relative path so Visual Studio can find them. You can include the solution's nuget packages directories, which is where I think it stores a copy of the libraries to be referenced by the project(s).
Incidentally, including said diretories may be effectively the same as "installing the packages". If you include all the files that NuGet uses in its management of packages, NuGet will behave the same as if you had installed them. But you don't need to do the actual package install via NuGet for it to work... or even have NuGet installed in Visual Studio in the first place. It's just a matter of the proper files being where the Visual Studio project files expect them to be.