The Stack Overflow podcast is back! Listen to an interview with our new CEO.

Hot answers tagged

24

One way I know to get such information is by using PowerShell in the Package Manager Console, from within Visual Studio. The Package Manager Console is a PowerShell console within Visual Studio used to interact with NuGet and automate Visual Studio. Basically you can use the Get-Package cmdlet to get a list of packages referenced in a specific project (...


6

Based on multiple sources, I've made a PowerShell script that reads all NuGet packages and fetches the license files and put that in a folder called "licenses". The script should be run on the root of the project (where the "packages" folder is located). # Run in Package Manager Console with `./download-packages-license.ps1`. # If access denied, execute `...


5

There is no versioning hell. This is specifically the goal of NuGet: the different versions of the same package can be installed side by side. The only limitation is that you can't reference different versions in the same project. But what versions of libraries are referenced by the packages I depend on are irrelevant for my project. In most cases, you can'...


4

If its a pure function then you want the code to execute on the same CPU as the app. a nuget package is a good way of getting that code into your project. If the function has side effects that you want to be global. ie every time this function runs we MUST generate an audit log. or, This function must only have a single instance running at a time and stop ...


3

That's simple to achieve: use a Directory.Build.props file in the solution folder and put those values in there. It takes the following format (just like the new .csproj files): <Project> <PropertyGroup> <Version>3.1.0</Version> <Company>Me</Company> <TreatWarningsAsErrors>True</...


3

You shouldnt bundle libraries together into packages at all. Put each library in its own package and use the nuspec dependencies to indicate if one relies on another


3

I would like to be able to have any changes pushed to C trigger a nuget update and build of B and then A. I wouldn't. When you change C, you shouldn't care about B or A, since those are not your dependencies. This way, you know for sure that no matter what changes you bring to C, every other project which relies on C will still continue to work. If, later,...


3

The issue you are encountering is weird. You may check twice the way NuGet dependencies are stored in source control. What may help is: To use one solution instead of several ones. Unless there are multiple teams in different departments of your company working on completely independent projects with a dependency on a common project, one solution may make ...


3

Packages can be submitted and accepted automatically, with no manual review or human oversight Yes. Packages can cause the package manager to execute arbitrary "setup" code on the client system at install-time. The "old" project model allows running PowerShell scripts, so yes I would say this is also an issue for NuGet. Even the new ones are vulnerable ...


2

When you are working with multiple teams on multiple projects, you always had and will have most (if not all) of your troubles relating to interfacing between these projects. You can call it project/library/microservice/etc. - it's always the same as you describe. One team makes breaking changes, the other team(s) suffer. As this problem is quite well-known,...


2

I suggest you don't for the following reasons: They can take up a lot of space in your version control system They are unnecessary because these should be fetched as part of your build process Usually you don't care about the history of these files Typically version control systems handle binary data badly The advantages storing them in source control are: ...


2

I'm using Azure DevOps (formerly VSTS), and while this question is old, it may have value for others. My understanding of best practice is: Use semantic versioning Separate package groups into distinct repositories where possible Don't update a package version if the package isn't changed This is tricky with version data coming from a CI build and n ...


2

VSTS can create Nuget Feeds. You can host your own feed and publish your packages there. You may want to have two feeds, one for release packages and one for your internal debugging needs. You can set permissions on the feeds, so that should be no problem. You can obviously make them available to just anybody (no login) but that is contradictory to your ...


2

Use NuGet when your project, library or framework needs to be publicly distributed to software developers outside of your organization. * Use a web API when you need the benefits that a web API provides. Generally, that means you have multiple software front-ends that need to communicate with server functionality of some sort. In all other cases, put ...


2

Package authors should be respecting compatibility with the proper use of the package version. What you're intending to do sounds like it would be a lot of work if at all possible. Your project using the NuGet packages shouldn't "assume" that the latest and greatest version of the packages is going to make your project that much better. Just seems lazy IMO (...


2

I am not an expert on NuGet and have only limited experience with "nuget.exe", but I am pretty sure I understood what your actual problem is, and I think the following may be a conceptual solution: On your build server, MySolution exists in two versions in parallel: the last commited version the "NuGet" version (which corresponds to the last time a feature ...


1

By far the easiest way to handle this is to use a local package source. If you make .net standard class libraries you can package them automatically after each build in VS. I guess you could automate further with a post build script. Most people find the whole rigmarole of pushing, waiting for the build, pulling down the new nuget etc to the second project ...


1

If I understand your problem correctly, you can solve it by using a single nuget feed and prerelease version numbers. Nuget supports Semver 2.0.0, this means you can publish your debug or development versions of the packages with an incrementing postfix, like: 1.0.1-debug1, 1.0.1-debug2, etc (or 1.0.1-debug001, 1.0.1-debug002, for better sorting). Then, ...


1

OK Here's my guess. You have a shared lib distributed by nuget and consumed by you application. When you get a feature request for the application you create a new feature branch on its repo, but find that it will require changes to the shared lib You create a feature branch on the library repo and publish a pre-release nuget You consume the prerelease ...


1

I think 'best practice' is to develop the nuget package by itself, with enough tests to ensure that you can consume it without having to debug. But I do know what you mean. I think the common work around is simply to reference the projects during development and switch to the package once you are stable. Remember you can publish and reference a.b.c.d-...


1

NuGet has the ability to point to any file system location. It will treat this directory as a local repository. Publish here during your dev cycle. The other thing you’ll want to do is automate the packaging process in your MSBuild file. You don’t want to have to manually fuss with the GUI every time you want to update the local repo so you can test your ...


1

If you're still working on 1.2.0, you could tag your release candidate builds something like 1.2.0-RC.123, '123' being a unique identifier (commit hash, build number, timestamp, etc) making it easy to reference. Once QA'd and approved and deployed, you could tag it with the 'official' version, 1.2.0, or 1.2.0-RELEASE. It's easy to clean up old tags if you ...


1

I am not an expert on NuGet or VSTS so can only offer general advice. As a general pattern, not just NuGet, for interlinked projects the pattern consists of: structuring your project to have common code clearly separated from application or project code. Minimising or removing all inter-dependencies between projects - ideally all of the projects should be ...


1

In Visual Studio 2015, only certain project types (one relating to Net Core) use project.json. The others continue to use packages.config. Net Core is a new effort to port .Net to other platforms, and also break the framework up to be consumed as individual packages, as opposed to installing the full .Net Framework on Windows before using .Net apps. The ...


1

I think the key part of the licence for TestApi is this: (E) The software is licensed "as-is." You bear the risk of using it. The contributors give no express warranties, guarantees or conditions. You may have additional consumer rights under your local laws which this license cannot change. To the extent permitted under your local laws, the ...


1

No. Don't store them beside your source code. Most VCS are built to handle text files, not binaries. However, you probably should set up your own local package server and have your build fetch your dependencies from there. It gives you the safety net to avoid problems like this. TL;DR: A guy unpublished 17 lines of code and broke the Internet. That wouldn'...


1

We're using GitVersion along with a GitVersion.yml file and GitFlow-based branches in Git to handle this. The GitVersion.yml file sets the base version of the item, e.g. 1.2.3 while GitVersion assigns the last part based upon the number of commits. This is highly customizable. We allow GitVersion to update the versions in our AssemblyInfo.cs files which ...


1

What should work is simply checking out the source code for the NuGet package and opening the solution in a separate instance of Visual Studio. Visual Studio has a neat trick of switching between code in open instances by working out what you have referenced. The first time this happened to me whilst I was debugging, was a revelation. The main problem you ...


1

A classic problem - the simplest resolution is to do what everyone does, treat your Core product as a separate product, similar to how you'd treat an open source project you were reusing in your product. For example, I use log4net in my product. I don't have a copy of their source, I only take the latest stable dll and use that directly, putting it in a '...


1

if you want to stick to just Team Foundation Server and Team Build, then NuGet is indeed the way to go. The ALM Rangers have written a guide explaining how to handle this scenario. Indeed adding a little powershell script or integrating the nuget generation as part of your MsBuild project structure to create a nuget package and then pushing that package to ...


Only top voted, non community-wiki answers of a minimum length are eligible