Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Stop support of any standard NuGet clients

See original GitHub issue

Since we have a lot of problems/inconvenience with new nuget features like a global caching, new PackageReference format, removed install/uninstall ps-scripts, and the overall focus on libraries only, I’ll consider new destribution via our compact GetNuTool client (or something else, not important). That is, this package still will be placed via any nuget server, but without any guarantee for support of any standard client.

Because I’m tired from nuget project -_- in recent years it’s very inconvenient for any tools, because of main focus to libraries (that’s soundly not for all cases).

GetNuTool (batch file about 10kb) has been created primarily to provide tools and service of user projects, libraries, the build processes, etc. It especially used by vsSolutionBuildEvent projects (CIM library for support CI features) because of removed solution-level in 2015

Thus, probably we need to reconsider new way for distribution our tool for best support.

Related issue:

How it can be (draft)

gnt.core can be wrapped to 1 batch file (text-based file, who don’t know) that will:

  • Receive our tool, then interact (if new installation) with user for complete installation for selected project (as for today).

Requirements: no any, GetNuTool works via msbuild like your common build. And logic will be placed in 1 batch file, that you can store with your code as simple build-script.


But GetNuTool is oriented for solution-level only, therefore we need also provide support to add our settings & required targets for user project-files.

For this I can encapsulate logic of this inside our package from vsSolutionBuildEvent project (I think part of this I can open by new MIT license), and main scheme should be like:

batch -> package -> {installation} -> {logic from vsSolutionBuildEvent} -> {imported targets and configuration} -> done

so I think it should be fine.

Pros / cons


  • Best support of our package as we need in any time.
  • 1 batch files that may aggregate any configuration and easily stored with other your source code, or directly in any other scripts and so on…
  • Probably it takes as much work for implementation as for all support of all this zoo. So it’s not important (for me at least) this or full review of current obsolete variants. Well I think <_<


  • Misunderstanding for new users via current NuGet server - why install command not works properly. (partially resolved)
  • … please comment about possible problems for you.

So what anyone think about this ? Your suggestions ?

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Comments:23 (15 by maintainers)

github_iconTop GitHub Comments

ArgusMagnuscommented, Nov 21, 2017

Im sorry to say this, but this is a terrible choice from a user perspective. Suddenly I am prompted to download some .bat files from the internet with no clear and easy instructions to use them. I will have to find out how exactly I need to use every time I use it (since I have to install it rarely into new projects).

If I run DllExport_Configure.bat, the cmd window flashes up, Im guessing it crashes, because nothing happens. I guess at this point, Im faster at writing a C++/CLI layer than investigating this further.

Please consider minimal NuGet support again, no need for the configuration GUI, just deliver a default configuration (e.g. x86 + x64, etc…) via NuGet please.

dagostinellicommented, Mar 7, 2018

I edited my “3 times” comment above for clarity. It’s irrelevant anyway…

Read more comments on GitHub >

github_iconTop Results From Across the Web

Stop support of a NuGet package
How to gracefully stop support of NuGet package in repository? Actually I moved the package to another NuGet channel (e.g. moved https ......
Read more >
Please stop lying about .NET Standard 2.0 support!
In this post I have a bit of a rant about Microsoft's NuGet packages lying about supporting .NET Standard 2.0 when they kinda...
Read more >
The future of .NET Standard - .NET Blog
Since the browser sandbox is fairly restrictive, not all class libraries and NuGet packages should be expected to work in Blazor WebAssembly.
Read more >
NuGet 6.0 Release Notes
Release notes for NuGet 6.0 including new features, bug fixes, and DCRs. ... NuGet Client Remote Code Execution Vulnerability - #12653.
Read more >
Nuget Error While Referencing .NET Standard Library ...
I have finally installed Visual Studio 2017.2 and am trying to get my first project working, but am running into some trouble that...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found