Use NuKeeper CLI in shell instead of VS Developer Command Prompt

[CrispyDrone]

💬 Questions and Help

When I use bash to run the repo nukeeper command, I receive exceptions related to NuGet.exe not being able to restore packages: Cannot determine the packages folder to restore NuGet packages. Please specify either -PackagesDirectory or -SolutionDirectory.

When I execute the exact same command in VS's Developer Command Prompt it works.

How can I get NuKeeper CLI to work properly in bash or other shells?

Also as a side remark, the nuget restore on all projects takes around 15 minutes for a single solution, any idea why this is so slow?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[CrispyDrone]

I don't like creating useless bump posts, but I guess stale bot leaves me no choice.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[CrispyDrone]

Bump. Nukeeper still doesn't work outside of vs developer command prompt. However, it doesn't throw exceptions, it just hangs on the nuget restore command.

The performance of nuget restore seems to have improved.

[CrispyDrone]

I have finally taken a closer look at the environment settings that VsDevCommand.bat creates. It seems it was as simple as the location of MsBuild.

This message gets printed when I'm using bash:

MSBuild auto-detection: using msbuild version '4.8.4084.0 built by: NET48REL1' from 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319'.

When I prefix the invocation of the nukeeper command as follows;

PATH="/c/Program Files (x86)/Microsoft Visual Studio/2019/Community/MSBuild/Current/Bin:$PATH" <nukeeper command>

It correctly finds the up-to-date MsBuild version!

I'm keeping this issue open for now, since I don't know whether this is linked to NuGet, or NuKeeper per se, and if the former whether NuKeeper can set up the environment correctly such that NuGet will find the correct version of MsBuild.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[slang25]

Ignore the close, I slipped. Just removing the wontfix label

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[davidreis97]

I still have an issue related with this. I have a custom project import that looks like this:

<Import Project="$(SolutionDir)\MyProject" />

But I can't set the SolutionDir variable so it doesn't work. Is there a way to customize the parameters that get passed to msbuild?

EDIT - We were able to implement a workaround by using the MSBuildProjectDirectory variable instead of SolutionDir

[slang25]

Glad you found a workaround. Back in the olden days (like before 2010 when NuGet was better integrated with MSBuild) NuGet would reference packages based on the SolutionDir property, but would always default the SolutionDir property to the relate solution folder if it wasn't set, that way projects are still buildable on their own. I think having projects that can only be built when they are being built by the solution they belong to might be something to avoid in general.

That said, I think we might need a way of passing msbuild properties in general via NuKeeper. As problems like this could be solved.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.