Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error
2 Pages12>
Grid Node Server vs. NuGet Restore
Options
Previous Topic Next Topic
GlobalConcepts
#1 Posted : Tuesday, April 30, 2024 8:43:35 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 2/7/2013(UTC)
Posts: 44
Location: Germany

Thanks: 3 times
Was thanked: 3 time(s) in 3 post(s)
It seems like sometimes NCrunch Grid Node v5.x has problems restoring referenced nuget packages.
This can occur in differend situations.

Situation 1:
- Package.A is directly referenced
- Package.A has a references Package.B
- Both Packages are available in the same Package source

Situation 2:
- Package.B is directly referenced
- Package.B is available on a customer Package source that is also accesible by the Grid Node Server

Building the project locally everthing works fine and NCrunch is able to build the project.
Grid Node Server failes with "Package Package.B, version 2.0.22 was not found. It might have been deleted since NuGet restore. Otherwise, NuGet restore might have only partially completed, which might have been due to maximum path length restrictions.

Known Workarounds:
It seems like NCrunch indeed tries to restore the nuget package to "<<Snapshotpath>>\.nuget" because there is a Directory "Package.B" including the correct version but containing the documentation file only. Nur "lib" folder and so on.
In some cases it helps copying the content from the local ".nuget" directory to that directory on the Grid Node Server. In some cases it also works to copy that content into the ".nuget" folder of any user known to that server even if the ncrunch service in running under "Local System" account.

What else to mention:
The problem occurs with ASP.net Core projects and Azure Function apps both compiled with .net 8.0 both using Central Package Management with nuget.config but had worked with NCrunch v4.x before.
Back to top
 |  Edit by user
Remco
#2 Posted : Tuesday, April 30, 2024 1:03:23 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,001

Thanks: 932 times
Was thanked: 1259 time(s) in 1172 post(s)
Hi, thanks for sharing this issue.

NCrunch actually doesn't restore Nuget packages on grid nodes. Instead, it copies them over from connected clients. This allows grid nodes to function without an open internet connection (necessary in some secure environments).

From what you've described, it seems to me that the client is providing the node with the wrong package data. I'm not an expert on central package management, but my understanding is that this is focused more on controlling the feeds with which packages get restored from .. in which case this shouldn't have much bearing on the manner in which NCrunch transfers Nuget packages from the client over to grid nodes.

If something has gone wrong on a grid node that has resulted in a Nuget package having a corrupt state (for example, missing files), then NCrunch won't have a way to correct this. It will simply see the package on the node, and it won't attempt to transfer it again. If you see this, simply deleting the package from the node and restarting it should result in a resync.

If you're regularly seeing packages on the node in a corrupt state, it's worth checking to see what is connecting to the node. The node will replicate packages stored on clients connecting to it, so if a package is in an incomplete state on a client, it will transfer that state to the node (if the package doesn't exist there yet).

v5 did include a change here that may have impacted you. Previously, we would perform hash checks between the package files on the node vs the connecting client. If the hash checks failed, the package would be automatically re-sent to the node. We removed these hash checks because they were kicking up packages with binary differences between client and node that were actually irrelevant to the function of the package. For example, two clients might have packages that were restored by different versions of Nuget and therefore have different metadata files. This would cause clients to fight with each other over the packages stored on the node, causing resource conflicts and instability. Now, we just transfer the packages that are deemed missing simply by checking the directory structure.

A simple way to avoid any issues is to just copy the packages over manually, then restart the node.
Back to top
 |  Edit by user
GlobalConcepts
#3 Posted : Tuesday, April 30, 2024 2:12:45 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 2/7/2013(UTC)
Posts: 44
Location: Germany

Thanks: 3 times
Was thanked: 3 time(s) in 3 post(s)
Thx for your response.

I've just deleted the folder containing the latest version => did not help
I've than tried the same deleting the whole "Package.B" directory => did not help

Is it possible to reactivate that hash validation again by registry hack or so?
Back to top
Remco
#4 Posted : Wednesday, May 1, 2024 12:23:09 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,001

Thanks: 932 times
Was thanked: 1259 time(s) in 1172 post(s)
Just to confirm my understanding, you've removed the package directory entirely from the grid node and restarted it, then connected the client, and the files that were re-copied to the node were incorrect?

If so, then we need to find out why. Can you search the connected client for installed instances of the package? Does it have multiple package roots?
Back to top
GlobalConcepts
#5 Posted : Wednesday, May 1, 2024 6:58:25 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 2/7/2013(UTC)
Posts: 44
Location: Germany

Thanks: 3 times
Was thanked: 3 time(s) in 3 post(s)
Basically yes. The only thing we could talk about is that "restart grid node" thing. I've done that by hitting "restart" inside the "NCrunch Distributed Processing" window.
If that's not enough and you wanted me to restart the whole OS I'll try that also.

As I mentioned before we are using Central Package Management that recommends a nuget.config having more that one package source to steer that restore process correctly.
That nuget.config indeed should avoid having problems with multiple package roots.

Quote:

<?xml version="1.0" encoding="utf-8"?>

<configuration>
<packageRestore>
<add key="enabled" value="True" />
<add key="automatic" value="True" />
</packageRestore>

<packageSources>
<clear />
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
<add key="Custom" value="..." />
</packageSources>

<!-- Define mappings by adding package patterns beneath the target source. -->
<packageSourceMapping>
<!-- key value for <packageSource> should match key values from <packageSources> element -->
<packageSource key="nuget.org">
<package pattern="*" />
</packageSource>
<packageSource key="Custom">
<package pattern="Package.*" />
</packageSource>
</packageSourceMapping>

</configuration>


For example we have defined a PackageSource for pattern "Package.*" to get all packages starting with "Package" to be resolved from our custom NugetFeed hosted on a privatly accessible Azure DevOps Artifact Feed.
For all other packages we have defined the pattern "*" to get those packages from nuget.org.

But again. Talking about the clients those things are working. So each package that has to be copied to the ".nuget" folder of the grid node should be existing inside my local ".nuget" folder unser "C:\Users\<<User>>"
Back to top
Remco
#6 Posted : Wednesday, May 1, 2024 7:42:16 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,001

Thanks: 932 times
Was thanked: 1259 time(s) in 1172 post(s)
The package files stored on the grid nodes are basically just xcopied over from the client. Here's what happens:

1. When the grid node service starts, it scans the contents of the Nuget package directory on the grid node and stores a representation of this in memory (which is why it's important to restart the node if the packages are changed manually)
2. When a client connects to the node, it sends a metadata structure containing the solution itself, including all projects and which Nuget packages are used by each one (specifically, the package name and version number)
3. The server reconciles the list of packages from the client with the packages it knows to have installed. Where packages do not exist on the server, it sends a list of missing packages to the client instructing it to send these over
4. The client then takes this list, finds the package in a local directory, then sends each file in the package to the server

There are a couple of things that can cause this to fail. The first is if file locks are held in such a way that prevent the client from reading its package files in order to send them to the grid node.

The second is if the package files that are found on the client are not actually what is expected. For example, the client may have a package directory containing an incomplete package or something that makes a representation of that package but does not contain all of the necessary files for it to work on the server.

My current suspicion is that the first client connecting to your grid node might have a secondary package directory that doesn't actually contain the correct package files (for example, it may be some weird abstract representation of the package, or it may be corrupt). The NCrunch client is then copying these packages to the grid node and considering everything to be fine, when actually it's not.

The actual end source of the package (i.e. whether its from nuget.org or somewhere else) shouldn't matter for this process. What matters is where the packages are stored on the client and whether they are intact or not. If you can identify a package that continues to be transferred to the node every time a specific client connects to it, the first thing I would do is to scan the whole HDD on the client to see where this package is stored. Maybe it's sitting somewhere twice, and one of these is incomplete somehow.
Back to top
GlobalConcepts
#7 Posted : Thursday, May 2, 2024 9:29:25 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 2/7/2013(UTC)
Posts: 44
Location: Germany

Thanks: 3 times
Was thanked: 3 time(s) in 3 post(s)
As mentioned in https://learn.microsoft.com/en-us/nuget/consume-packages/managing-the-global-packages-and-cache-folders projects using the PackageReference format - as we do - always use packages directly from that global-packages folder.
There indeed exists the possibility to override those locations viag nuget.config but this is not used.

Also the commands "nuget locals all -list" and "dotnet nuget locals all --list" give me exactly the same result executed inside the projects directory or somethere else.

Quote:

http-cache: C:\Users\<<User>>\AppData\Local\NuGet\v3-cache
global-packages: C:\Users\<<User>>\.nuget\packages\
temp: C:\Users\<<User>>\AppData\Local\Temp\NuGetScratch
plugins-cache: C:\Users\<<User>>\AppData\Local\NuGet\plugins-cache


Talking about "locks" is another interesting topic. Maybe Windows Defender locks those files.

I'll watch those topics and try some things out.
For the moment we have a helpful workaround.

Maybe I'll come up to that later
Thx for your time
Back to top
GlobalConcepts
#8 Posted : Thursday, May 2, 2024 11:17:38 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 2/7/2013(UTC)
Posts: 44
Location: Germany

Thanks: 3 times
Was thanked: 3 time(s) in 3 post(s)
OK. Another "funny" thing

- Package / Library exists on Client, exists on Grid Node (Both, Snapshot and User Directory)
- Grid Node Failes because of missing reference
- Setting "Build SDK" to the current version "8.0.204" => Test goes green
- Removing Value from "Build SDK" failes again ?? what ??
- Setting "Build SDK" to the current version "8.0.204" => Test keeps failing
Back to top
Remco
#9 Posted : Thursday, May 2, 2024 11:29:32 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,001

Thanks: 932 times
Was thanked: 1259 time(s) in 1172 post(s)
Can you identify a package that is being copied incorrectly and cross check this package with the files that are stored on the client? We need to know where the package is being copied from and why it is missing files.
Back to top
GlobalConcepts
#10 Posted : Thursday, May 2, 2024 12:17:54 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 2/7/2013(UTC)
Posts: 44
Location: Germany

Thanks: 3 times
Was thanked: 3 time(s) in 3 post(s)
OK

Latest package "Microsft.CrmSdk.CoreAssemblies", version 9.0.2.52
Target Framework of the current Project: 4.6.2
Build System: dotnet with sdk 8.0.204

Quote:
..\..\..\..\Program Files\dotnet\sdk\8.0.204\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets (266, 5): Package Microsoft.CrmSdk.CoreAssemblies, version 9.0.2.52 was not found. It might have been deleted since NuGet restore. Otherwise, NuGet restore might have only partially completed, which might have been due to maximum path length restrictions.


- "C:\Users\<<User>>\.nuget\packages\microsoft.crmsdk.coreassemblies\9.0.2.52" existing
- "G:\NGN\Snap\.nuget\microsoft.crmsdk.coreassemblies\9.0.2.52" on Grid Node existing
- Both containing the "lib" directory
- Both "lib" directories contain a "net462" directory
- Both "net462" directories contain the expected 4 files with correct sizes

The other project with same references but built directly with net 4.6.2 does not have that problem.
This project also does not use ProjectReferences but that local package folder + package.config

So it might be a problem with dotnet and / or ProjectReferences

What else may I check for you?

Edit:

Just for testing purpose I took that working project that was project.config based and converted its references to ProjectReferences ... NCrunch now again chooses a random package that cannot be resolved
Package content in Grid Node looks correct
Back to top
 |  Edit by user
Remco
#11 Posted : Thursday, May 2, 2024 1:00:07 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,001

Thanks: 932 times
Was thanked: 1259 time(s) in 1172 post(s)
Can you confirm whether G:\NGN\Snap is the correct user profile directory on the grid node?

If it is, this would suggest a problem where the build system on the node is not using the correct path when trying to resolve packages.

If not, this would suggest the problem may be that the files are not being transferred to the node as they should be.
Back to top
GlobalConcepts
#12 Posted : Thursday, May 2, 2024 1:38:03 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 2/7/2013(UTC)
Posts: 44
Location: Germany

Thanks: 3 times
Was thanked: 3 time(s) in 3 post(s)
G:\NGN\Snap is what we've defined as a "Snapshot storage directory".
"Workspace base path" points to "G:\NGN" + we have a Networkshare on that NGN path that is used in "Workspace base path over network share" but I'm not 100% shure if each user may access this share - my user does.
Back to top
Remco
#13 Posted : Thursday, May 2, 2024 11:34:25 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,001

Thanks: 932 times
Was thanked: 1259 time(s) in 1172 post(s)
Can you do the following for me?

- Open up NCrunch on your local machine, open your solution
- Disconnect from all grid nodes using the Distributed Processing Window
- Wait for your projects to build locally
- Right click on one of these projects (ideally one of the ones that fails on the node), then go to advanced->Browse to workspace
- Find the .nuget.g.props file (usually under the obj directory)
- Open this file in a text editor. Copy/paste the NuGetPackageFolders and NuGetPackageRoot properties here into the forum (if they don't contain sensitive information)

When we build the projects on the node, we do a find and replace on this file to swap the Nuget Package Folders with the appropriate path on the grid node. I suspect this may not be happening correctly. It's possible that on the client side, the build system is loading package files from a path that isn't what NCrunch thinks it is. This would result in the path not being updated on the grid node, thus failing the build (you can probably check this on the node too, by searching for the equivalent file there, though it may be a little harder to find).
Back to top
GlobalConcepts
#14 Posted : Friday, May 3, 2024 12:33:55 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 2/7/2013(UTC)
Posts: 44
Location: Germany

Thanks: 3 times
Was thanked: 3 time(s) in 3 post(s)
I've pasted the whole - but anonymized - content in case you need more information later on.

NuGetFallbackFolder are
- C:\Users\anonymized\.nuget\packages\
- C:\Program Files (x86)\Microsoft Visual Studio\Shared\NuGetPackages
- C:\Program Files\dotnet\sdk\NuGetFallbackFolder

NuGetFallbackFolder is nearly on Client, but has a lot of packages on the node.

NuGetPackageRoot is $(UserProfile)\.nuget\packages\


"Old" Project Style; net4.6.2, ProjectReferences:

Project
Quote:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup Condition=" '$(ExcludeRestorePackageImports)' != 'true' ">
<RestoreSuccess Condition=" '$(RestoreSuccess)' == '' ">True</RestoreSuccess>
<RestoreTool Condition=" '$(RestoreTool)' == '' ">NuGet</RestoreTool>
<ProjectAssetsFile Condition=" '$(ProjectAssetsFile)' == '' ">$(MSBuildThisFileDirectory)project.assets.json</ProjectAssetsFile>
<NuGetPackageRoot Condition=" '$(NuGetPackageRoot)' == '' ">$(UserProfile)\.nuget\packages\</NuGetPackageRoot>
<NuGetPackageFolders Condition=" '$(NuGetPackageFolders)' == '' ">C:\Users\anonymized\.nuget\packages\;C:\Program Files (x86)\Microsoft Visual Studio\Shared\NuGetPackages</NuGetPackageFolders>
<NuGetProjectStyle Condition=" '$(NuGetProjectStyle)' == '' ">PackageReference</NuGetProjectStyle>
<NuGetToolVersion Condition=" '$(NuGetToolVersion)' == '' ">6.9.2</NuGetToolVersion>
</PropertyGroup>
<ItemGroup Condition=" '$(ExcludeRestorePackageImports)' != 'true' ">
<SourceRoot Include="C:\Users\anonymized\.nuget\packages\" />
<SourceRoot Include="C:\Program Files (x86)\Microsoft Visual Studio\Shared\NuGetPackages\" />
</ItemGroup>
<ImportGroup Condition=" '$(ExcludeRestorePackageImports)' != 'true' ">
<Import Project="$(NuGetPackageRoot)ilmerge\3.0.41\build\ILMerge.props" Condition="Exists('$(NuGetPackageRoot)ilmerge\3.0.41\build\ILMerge.props')" />
</ImportGroup>
<PropertyGroup Condition=" '$(ExcludeRestorePackageImports)' != 'true' ">
<PkgILMerge Condition=" '$(PkgILMerge)' == '' ">C:\Users\anonymized\.nuget\packages\ilmerge\3.0.41</PkgILMerge>
</PropertyGroup>
</Project>


Project.Tests
Quote:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup Condition=" '$(ExcludeRestorePackageImports)' != 'true' ">
<RestoreSuccess Condition=" '$(RestoreSuccess)' == '' ">True</RestoreSuccess>
<RestoreTool Condition=" '$(RestoreTool)' == '' ">NuGet</RestoreTool>
<ProjectAssetsFile Condition=" '$(ProjectAssetsFile)' == '' ">$(MSBuildThisFileDirectory)project.assets.json</ProjectAssetsFile>
<NuGetPackageRoot Condition=" '$(NuGetPackageRoot)' == '' ">$(UserProfile)\.nuget\packages\</NuGetPackageRoot>
<NuGetPackageFolders Condition=" '$(NuGetPackageFolders)' == '' ">C:\Users\anonymized\.nuget\packages\;C:\Program Files (x86)\Microsoft Visual Studio\Shared\NuGetPackages</NuGetPackageFolders>
<NuGetProjectStyle Condition=" '$(NuGetProjectStyle)' == '' ">PackageReference</NuGetProjectStyle>
<NuGetToolVersion Condition=" '$(NuGetToolVersion)' == '' ">6.9.2</NuGetToolVersion>
</PropertyGroup>
<ItemGroup Condition=" '$(ExcludeRestorePackageImports)' != 'true' ">
<SourceRoot Include="C:\Users\anonymized\.nuget\packages\" />
<SourceRoot Include="C:\Program Files (x86)\Microsoft Visual Studio\Shared\NuGetPackages\" />
</ItemGroup>
<ImportGroup Condition=" '$(ExcludeRestorePackageImports)' != 'true' ">
<Import Project="$(NuGetPackageRoot)xunit.runner.visualstudio\2.8.0\build\net462\xunit.runner.visualstudio.props" Condition="Exists('$(NuGetPackageRoot)xunit.runner.visualstudio\2.8.0\build\net462\xunit.runner.visualstudio.props')" />
<Import Project="$(NuGetPackageRoot)microsoft.codecoverage\17.9.0\build\netstandard2.0\Microsoft.CodeCoverage.props" Condition="Exists('$(NuGetPackageRoot)microsoft.codecoverage\17.9.0\build\netstandard2.0\Microsoft.CodeCoverage.props')" />
<Import Project="$(NuGetPackageRoot)microsoft.net.test.sdk\17.9.0\build\net462\Microsoft.NET.Test.Sdk.props" Condition="Exists('$(NuGetPackageRoot)microsoft.net.test.sdk\17.9.0\build\net462\Microsoft.NET.Test.Sdk.props')" />
</ImportGroup>
<PropertyGroup Condition=" '$(ExcludeRestorePackageImports)' != 'true' ">
<Pkgxunit_analyzers Condition=" '$(Pkgxunit_analyzers)' == '' ">C:\Users\anonymized\.nuget\packages\xunit.analyzers\1.13.0</Pkgxunit_analyzers>
<PkgNSubstitute_Analyzers_CSharp Condition=" '$(PkgNSubstitute_Analyzers_CSharp)' == '' ">C:\Users\anonymized\.nuget\packages\nsubstitute.analyzers.csharp\1.0.17</PkgNSubstitute_Analyzers_CSharp>
<PkgILMerge Condition=" '$(PkgILMerge)' == '' ">C:\Users\anonymized\.nuget\packages\ilmerge\3.0.41</PkgILMerge>
<PkgFluentAssertions_Analyzers Condition=" '$(PkgFluentAssertions_Analyzers)' == '' ">C:\Users\anonymized\.nuget\packages\fluentassertions.analyzers\0.31.0</PkgFluentAssertions_Analyzers>
</PropertyGroup>
</Project>


SDK Project Style, net8.0:

Project
Quote:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup Condition=" '$(ExcludeRestorePackageImports)' != 'true' ">
<RestoreSuccess Condition=" '$(RestoreSuccess)' == '' ">True</RestoreSuccess>
<RestoreTool Condition=" '$(RestoreTool)' == '' ">NuGet</RestoreTool>
<ProjectAssetsFile Condition=" '$(ProjectAssetsFile)' == '' ">$(MSBuildThisFileDirectory)project.assets.json</ProjectAssetsFile>
<NuGetPackageRoot Condition=" '$(NuGetPackageRoot)' == '' ">$(UserProfile)\.nuget\packages\</NuGetPackageRoot>
<NuGetPackageFolders Condition=" '$(NuGetPackageFolders)' == '' ">C:\Users\anonymized\.nuget\packages\;C:\Program Files (x86)\Microsoft Visual Studio\Shared\NuGetPackages;C:\Program Files\dotnet\sdk\NuGetFallbackFolder</NuGetPackageFolders>
<NuGetProjectStyle Condition=" '$(NuGetProjectStyle)' == '' ">PackageReference</NuGetProjectStyle>
<NuGetToolVersion Condition=" '$(NuGetToolVersion)' == '' ">6.9.2</NuGetToolVersion>
</PropertyGroup>
<ItemGroup Condition=" '$(ExcludeRestorePackageImports)' != 'true' ">
<SourceRoot Include="C:\Users\anonymized\.nuget\packages\" />
<SourceRoot Include="C:\Program Files (x86)\Microsoft Visual Studio\Shared\NuGetPackages\" />
<SourceRoot Include="C:\Program Files\dotnet\sdk\NuGetFallbackFolder\" />
</ItemGroup>
<ImportGroup Condition=" '$(ExcludeRestorePackageImports)' != 'true' ">
<Import Project="$(NuGetPackageRoot)microsoft.entityframeworkcore\8.0.4\buildTransitive\net8.0\Microsoft.EntityFrameworkCore.props" Condition="Exists('$(NuGetPackageRoot)microsoft.entityframeworkcore\8.0.4\buildTransitive\net8.0\Microsoft.EntityFrameworkCore.props')" />
<Import Project="$(NuGetPackageRoot)microsoft.azure.functions.worker.sdk\1.17.2\build\Microsoft.Azure.Functions.Worker.Sdk.props" Condition="Exists('$(NuGetPackageRoot)microsoft.azure.functions.worker.sdk\1.17.2\build\Microsoft.Azure.Functions.Worker.Sdk.props')" />
</ImportGroup>
<PropertyGroup Condition=" '$(ExcludeRestorePackageImports)' != 'true' ">
<PkgMicrosoft_Azure_Functions_Worker_Sdk_Analyzers Condition=" '$(PkgMicrosoft_Azure_Functions_Worker_Sdk_Analyzers)' == '' ">C:\Users\anonymized\.nuget\packages\microsoft.azure.functions.worker.sdk.analyzers\1.2.1</PkgMicrosoft_Azure_Functions_Worker_Sdk_Analyzers>
<PkgMicrosoft_Azure_Functions_Worker_Sdk Condition=" '$(PkgMicrosoft_Azure_Functions_Worker_Sdk)' == '' ">C:\Users\anonymized\.nuget\packages\microsoft.azure.functions.worker.sdk\1.17.2</PkgMicrosoft_Azure_Functions_Worker_Sdk>
</PropertyGroup>
</Project>


Project.Tests
Quote:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup Condition=" '$(ExcludeRestorePackageImports)' != 'true' ">
<RestoreSuccess Condition=" '$(RestoreSuccess)' == '' ">True</RestoreSuccess>
<RestoreTool Condition=" '$(RestoreTool)' == '' ">NuGet</RestoreTool>
<ProjectAssetsFile Condition=" '$(ProjectAssetsFile)' == '' ">$(MSBuildThisFileDirectory)project.assets.json</ProjectAssetsFile>
<NuGetPackageRoot Condition=" '$(NuGetPackageRoot)' == '' ">$(UserProfile)\.nuget\packages\</NuGetPackageRoot>
<NuGetPackageFolders Condition=" '$(NuGetPackageFolders)' == '' ">C:\Users\anonymized\.nuget\packages\;C:\Program Files (x86)\Microsoft Visual Studio\Shared\NuGetPackages;C:\Program Files\dotnet\sdk\NuGetFallbackFolder</NuGetPackageFolders>
<NuGetProjectStyle Condition=" '$(NuGetProjectStyle)' == '' ">PackageReference</NuGetProjectStyle>
<NuGetToolVersion Condition=" '$(NuGetToolVersion)' == '' ">6.9.2</NuGetToolVersion>
</PropertyGroup>
<ItemGroup Condition=" '$(ExcludeRestorePackageImports)' != 'true' ">
<SourceRoot Include="C:\Users\anonymized\.nuget\packages\" />
<SourceRoot Include="C:\Program Files (x86)\Microsoft Visual Studio\Shared\NuGetPackages\" />
<SourceRoot Include="C:\Program Files\dotnet\sdk\NuGetFallbackFolder\" />
</ItemGroup>
<ImportGroup Condition=" '$(ExcludeRestorePackageImports)' != 'true' ">
<Import Project="$(NuGetPackageRoot)xunit.runner.visualstudio\2.8.0\build\net6.0\xunit.runner.visualstudio.props" Condition="Exists('$(NuGetPackageRoot)xunit.runner.visualstudio\2.8.0\build\net6.0\xunit.runner.visualstudio.props')" />
<Import Project="$(NuGetPackageRoot)microsoft.testplatform.testhost\17.9.0\build\netcoreapp3.1\Microsoft.TestPlatform.TestHost.props" Condition="Exists('$(NuGetPackageRoot)microsoft.testplatform.testhost\17.9.0\build\netcoreapp3.1\Microsoft.TestPlatform.TestHost.props')" />
<Import Project="$(NuGetPackageRoot)microsoft.codecoverage\17.9.0\build\netstandard2.0\Microsoft.CodeCoverage.props" Condition="Exists('$(NuGetPackageRoot)microsoft.codecoverage\17.9.0\build\netstandard2.0\Microsoft.CodeCoverage.props')" />
<Import Project="$(NuGetPackageRoot)microsoft.net.test.sdk\17.9.0\build\netcoreapp3.1\Microsoft.NET.Test.Sdk.props" Condition="Exists('$(NuGetPackageRoot)microsoft.net.test.sdk\17.9.0\build\netcoreapp3.1\Microsoft.NET.Test.Sdk.props')" />
<Import Project="$(NuGetPackageRoot)microsoft.entityframeworkcore\8.0.4\buildTransitive\net8.0\Microsoft.EntityFrameworkCore.props" Condition="Exists('$(NuGetPackageRoot)microsoft.entityframeworkcore\8.0.4\buildTransitive\net8.0\Microsoft.EntityFrameworkCore.props')" />
</ImportGroup>
<PropertyGroup Condition=" '$(ExcludeRestorePackageImports)' != 'true' ">
<Pkgxunit_analyzers Condition=" '$(Pkgxunit_analyzers)' == '' ">C:\Users\anonymized\.nuget\packages\xunit.analyzers\1.13.0</Pkgxunit_analyzers>
<PkgNSubstitute_Analyzers_CSharp Condition=" '$(PkgNSubstitute_Analyzers_CSharp)' == '' ">C:\Users\anonymized\.nuget\packages\nsubstitute.analyzers.csharp\1.0.17</PkgNSubstitute_Analyzers_CSharp>
<PkgMicrosoft_Azure_Functions_Worker_Sdk_Analyzers Condition=" '$(PkgMicrosoft_Azure_Functions_Worker_Sdk_Analyzers)' == '' ">C:\Users\anonymized\.nuget\packages\microsoft.azure.functions.worker.sdk.analyzers\1.2.1</PkgMicrosoft_Azure_Functions_Worker_Sdk_Analyzers>
<PkgMicrosoft_Azure_Functions_Worker_Sdk Condition=" '$(PkgMicrosoft_Azure_Functions_Worker_Sdk)' == '' ">C:\Users\anonymized\.nuget\packages\microsoft.azure.functions.worker.sdk\1.17.2</PkgMicrosoft_Azure_Functions_Worker_Sdk>
<PkgJustMock_Commercial Condition=" '$(PkgJustMock_Commercial)' == '' ">C:\Users\anonymized\.nuget\packages\justmock.commercial\2024.1.124.247</PkgJustMock_Commercial>
<PkgFluentAssertions_Analyzers Condition=" '$(PkgFluentAssertions_Analyzers)' == '' ">C:\Users\anonymized\.nuget\packages\fluentassertions.analyzers\0.31.0</PkgFluentAssertions_Analyzers>
</PropertyGroup>
</Project>
Back to top
Remco
#15 Posted : Friday, May 3, 2024 12:51:02 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,001

Thanks: 932 times
Was thanked: 1259 time(s) in 1172 post(s)
This is brilliant. Thanks for providing this!

I think the problem is being caused by the SourceRoots being specified in your project files.

Can you make these conditional on NCrunch not being present? Like so:

<ItemGroup Condition=" '$(ExcludeRestorePackageImports)' != 'true' and '$(NCrunch)' != '1' ">
<SourceRoot Include="C:\Users\anonymized\.nuget\packages\" />
<SourceRoot Include="C:\Program Files (x86)\Microsoft Visual Studio\Shared\NuGetPackages\" />
<SourceRoot Include="C:\Program Files\dotnet\sdk\NuGetFallbackFolder\" />
</ItemGroup>

On the grid node, NCrunch adjusts the package directory in the nuget props file, but not in the project XML. If something in the build system uses the project XML as precedence, this will definitely cause package resolution issues on the node.
Back to top
GlobalConcepts
#16 Posted : Friday, May 3, 2024 1:02:55 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 2/7/2013(UTC)
Posts: 44
Location: Germany

Thanks: 3 times
Was thanked: 3 time(s) in 3 post(s)
How would I do so? Aren't those files getting generated on each project change?
Back to top
Remco
#17 Posted : Friday, May 3, 2024 1:52:35 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,001

Thanks: 932 times
Was thanked: 1259 time(s) in 1172 post(s)
GlobalConcepts;17306 wrote:
How would I do so? Aren't those files getting generated on each project change?


Sorry, perhaps I misunderstood. The last batch of XML looked like it was from a raw .csproj file ... did it come from somewhere else?

Edit: It would be great if you could qualify which files (extension alone is enough) these extracts were from, as there's a few involved. Maybe there's a new include we're not catching here.
Back to top
 |  Edit by user
GlobalConcepts
#18 Posted : Friday, May 3, 2024 2:02:55 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 2/7/2013(UTC)
Posts: 44
Location: Germany

Thanks: 3 times
Was thanked: 3 time(s) in 3 post(s)
They're all *.csproj.nuget.g.props files, as you requested.

First and third file are the complete content generated by the project itself, second and fourth file are from the respectively unittest projects
Back to top
Remco
#19 Posted : Friday, May 3, 2024 11:49:57 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,001

Thanks: 932 times
Was thanked: 1259 time(s) in 1172 post(s)
Thanks. Ok, the next step then will be examining the files on the grid node to see what's happening there.

Opening up the workspaces on the grid node is a little bit trickier than on the client. It's possible to do it over a network share with the correct configuration, but if you're able to produce the problem consistently enough, you can probably find it manually by looking through the workspace paths on the grid node (or using a file search).

The NCrunch workspaces on the grid node will be stored under the configured workspace base path on the node. If you're able to make sure your solution is the only one being processed by the node at the time you're looking, this should reduce the noise and make the projects easier to find.

The key thing you need to check is the contents of those same .props files as they're being used by the node (in the workspaces). I'm very interested to know whether these files have the Nuget paths correctly rewritten on the node so that they point to the right place.
Back to top
GlobalConcepts
#20 Posted : Monday, May 6, 2024 7:33:17 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 2/7/2013(UTC)
Posts: 44
Location: Germany

Thanks: 3 times
Was thanked: 3 time(s) in 3 post(s)
OK, now things are getting kind of funny / strange / how ever.

As a first step I removed all other Snapshots to be sure to hit into the correct one.
I than switched to my Grid Node via RDM directly and navigated to the Snapshot directory I've configured.
The Folder Structure of that directory looks nearly identic to the one of the Client.

...with one difference: I do not have a "*.nuget.g.props" or *.nuget.g.targets" file there. I only have the ".nuget.dgspec.json"
Same on another Grid Node and with another Project

Looking into that file I recognized the value "C:\Users\myDomainUser\.nuget\packages" there which is not existing on my Grid Node since it is not joined any domain.

But even having the same global Packages Folder on each machine configured makes no difference.
Back to top
 |  Edit by user
Users browsing this topic
Guest
2 Pages12>
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.252 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download