Stop support of any standard NuGet clients

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: https://github.com/3F/DllExport/issues/36#issuecomment-305979911

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.

Problems

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 ?

[ArgusMagnus]

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.

[dagostinelli]

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