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

Notification

Icon
Error

2 Pages<12
Error occurred while analysing project
jonsequitur
#21 Posted : Sunday, May 21, 2017 10:00:04 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 5/18/2017(UTC)
Posts: 5
Location: United States of America

Thanks. I gave it a try but it hasn't resolved the issue.
Remco
#23 Posted : Sunday, May 21, 2017 11:17:12 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 655 times
Was thanked: 767 time(s) in 730 post(s)
Would you be able to submit a bug report after you've had this blow up? The log may yield information on which dependency is missing.
jonsequitur
#24 Posted : Sunday, May 21, 2017 11:24:43 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 5/18/2017(UTC)
Posts: 5
Location: United States of America

Done.
Remco
#25 Posted : Sunday, May 21, 2017 11:30:26 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 655 times
Was thanked: 767 time(s) in 730 post(s)
Thanks. Something seems different about your setup. I can see files resolving to [user]\.dotnet\NuGetFallbackFolder. Have you redirected your nuget packages directory somewhere else? If so, how has this been done?
jonsequitur
#26 Posted : Monday, May 22, 2017 1:05:16 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 5/18/2017(UTC)
Posts: 5
Location: United States of America

I have redirected it at various points in the past, as well as used pre-release builds of the dotnet CLI. (I've been a member of the team.) Currently though my package locations are default and I'm using release builds of dotnet and Visual Studio, and still seeing the problem. Does NCrunch cache these previous settings somewhere?
Remco
#27 Posted : Monday, May 22, 2017 2:50:43 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 655 times
Was thanked: 767 time(s) in 730 post(s)
NCrunch always considers the root of Nuget packages to be at [User]\.nuget\packages. In truth, I did not know it was possible to redirect this elsewhere. The log attached to the report you submitted indicates that MSBuild is resolving references to the [user]\.dotnet\NuGetFallbackFolder instead of [User]\.nuget\packages, so I presume there must be some additional package search logic on your machine allowing the MSBuild steps to find packages from outside their usual location.

Because NCrunch assumes that the Nuget packages will only be under the default location, some of the logic used to set up a runtime environment for you is malfunctioning. I'm not sure yet if this is the reason for the runtime environment exploding immediately on initialisation, but I'd say it's a strong candidate.

Is moving all packages to [User]\.nuget\packages and removing your fallback directory an option? I'd really like to see if this solves the problem.
jonsequitur
#28 Posted : Monday, May 22, 2017 3:07:04 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 5/18/2017(UTC)
Posts: 5
Location: United States of America

When you mentioned that package resolution is pointing to [user]\.dotnet\NuGetFallbackFolder, I tried copying files so that [user]\.dotnet\NuGetFallbackFolder and [user]\.nuget\packages had identical contents. It didn't resolve the issue.
Remco
#29 Posted : Monday, May 22, 2017 3:10:51 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 655 times
Was thanked: 767 time(s) in 730 post(s)
jonsequitur;10441 wrote:
When you mentioned that package resolution is pointing to [user]\.dotnet\NuGetFallbackFolder, I tried copying files so that [user]\.dotnet\NuGetFallbackFolder and [user]\.nuget\packages had identical contents. It didn't resolve the issue.


Can you try also removing the NuGetFallbackFolder, or placing it somewhere else on disk where you can be sure it won't be picked up by any implicit search logic?

It's important that NCrunch is able to recognise the dependencies as being Nuget packages, which can only happen if they are loaded from .nuget.



Edit: Something else worth doing is to make sure you clear out your project lock files (project.assets.json) and any of their associated generated files then get VS to rebuild them. There might still be bindings reaching from there to the fallback directory.
Users browsing this topic
Guest (3)
2 Pages<12
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.041 seconds.