Path to nuget cache?

I'm building a project that needs to include additional files. Prior to Nuget v3, I could point it to ../packages/refit/2.4.1/tools/*.*, but now the Nuget packages are stored in c:\users\moswald\.nuget\packages. I've tried changing the "additional files" path to %USERPROFILE%/.nuget/... but that doesn't work.

Hi, thanks for sharing this.

It looks like we'll need to add support for environment variables in the 'Additional Files To Include' for this to work. I'll see if I can get this introduced. Thanks for making me aware of it.

An ugly work around would be to hard-code the path into the 'Additional files to include' setting. If you're sharing settings with other NCrunch users, you can create a new line in the setting for each user. If NCrunch detects the directory as missing, it simply won't try to include from it.

Whoops, your reply got sent to my spam folder.

Thanks for the tip about nCrunch ignoring missing folders. At least that way we get those tests back for now.

I've just revisited our solution to this issue, and realised that our solution doesn't really make sense in this context.

The Additional Files To Include is designed to allow you to include files in the workspace that a relatively referenced from your code or build logic.

But the Nuget package path above is referenced using an absolute path.

So an environment variable here won't help. NCrunch won't be able to do anything with the include because there is no relative structure that can fit this reference outside of the disk path it's already in.

I would expect that if you remove any attempt to include this nuget package using Additional Files To Include, NCrunch should still be able to build the project without issue. This is because any paths in the build logic pointing at the package will be pointing to an absolute path, and they will work regardless of whether the project is in a workspace or otherwise.

Is it possible that you encountered this issue by attempting to create an Additional Files To Include entry for the referenced package simply out of habit?

I note that storing packages in a global space (which Nuget v3 does) is likely to create problems when executing builds/tests on remote grid nodes that don't have the package installed. I'm currently investigating this issue.

In this case, the nuget package comes with a tools subfolder with an executable inside that gets run as a pre-build step. Pre-nuget
3.0, the only way to get it working was to use the IncludeAdditionalFiles property.

moswald wrote:In this case, the nuget package comes with a tools subfolder with an executable inside that gets run as a pre-build step. Pre-nuget
3.0, the only way to get it working was to use the IncludeAdditionalFiles property.

Understood. Is the Additional Files To Include setting needed now that you are running Nuget v3?

I think so? It's definitely broken right now. :)

If you want, tomorrow I can put together a sample test suite and put it on GitHub for you to take a look at.

moswald wrote:I think so? It's definitely broken right now. :)

If you want, tomorrow I can put together a sample test suite and put it on GitHub for you to take a look at.

It would be really great if you could do that. Sorry, I'm having a hard time understanding this one.

Ok, I posted a really simple set of projects to github.

Thanks! The error message I receive from this code when testing it under the latest dev version of NCrunch is as follows:

System.InvalidOperationException: IExampleApi doesn't look like a Refit interface. Make sure it has at least one method with a Refit HTTP method attribute and Refit is installed in the project.
at Refit.RestService.For[T](HttpClient client, RefitSettings settings) in y:\code\paulcbetts\refit\Refit\RestService.cs:line 31
at Client.ApiFactory.CreateClient() in C:\Temp\nCrunchRefitAndNuget3-master\Client\IExampleApi.cs:line 31
at Client.Tests.SomeTests.ThisIsATest() in C:\Temp\nCrunchRefitAndNuget3-master\Client.Tests\SomeTests.cs:line 10

Is this the expected result of the code in its current state? It looks to be related to the endpoint/test. Is this the same problem you're experiencing, and can you confirm which version of NCrunch you're using?

I note that these projects are using project.json to reference their Nuget packages, so unless you're running an early build of 2.20, NCrunch will likely bomb out with a DNX error.

Aha, I have it figured out. You were right, it didn't have anything to do with the nuget package itself. The build process knows about the nuget cache, and so nCrunch shouldn't need to do anything special.

However, nCrunch doesn't automatically copy the generated .nuget.targets file, and so the build process doesn't know about the "extra" steps.

To fix this particular case, add Client.nuget.targets to the "Additional Files to Include" list, and everything starts building properly. I'm around 95% sure that this is correct in all cases, too.

moswald wrote:Aha, I have it figured out. You were right, it didn't have anything to do with the nuget package itself. The build process knows about the nuget cache, and so nCrunch shouldn't need to do anything special.

However, nCrunch doesn't automatically copy the generated .nuget.targets file, and so the build process doesn't know about the "extra" steps.

To fix this particular case, add Client.nuget.targets to the "Additional Files to Include" list, and everything starts building properly. I'm around 95% sure that this is correct in all cases, too.

Gotcha! It looks like this file is referenced implicitly somehow - I can't find anything in the project XML that points directly to it .. so NCrunch just won't know about it. This should be easy to fix. Thanks for the nice analysis.