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

Notification

Icon
Error
"Auto-Detect NuGet Build Dependencies" fails when repositoryPath is overridden in nuget.config
Options
Previous Topic Next Topic
LucasT
#1 Posted : Sunday, May 5, 2019 2:56:47 PM(UTC)
Rank: Member

Groups: Registered
Joined: 6/25/2015(UTC)
Posts: 11
Location: France

Was thanked: 1 time(s) in 1 post(s)
The Auto-Detect NuGet Build Dependencies feature seems to work fine only for the default package repository path in the old-style project format.

But if you set a custom repositoryPath value in a nuget.config file, NCrunch won't copy the full package contents to its workspace anymore, and the build will (most likely) fail.

Here's an example nuget.config file which will cause the issue to happen:

Code:
<configuration>
  <config>
    <add key="repositoryPath" value="packages_repo" />
  </config>
</configuration>


Just place this file anywhere in a parent directory of your solution (not necessarily the immediate parent), and install a package that contains props/targets files in an old-style project.

As an example, without this file, NuGet will add the following include if you install Fody v5.0.5:

Code:
<Import Project="..\packages\Fody.5.0.5\build\Fody.targets" Condition="Exists('..\packages\Fody.5.0.5\build\Fody.targets')" />


However, with the nuget.config file in a parent directory, you'll get something like this (depending on the level at which you place the file):

Code:
<Import Project="..\..\..\packages_repo\Fody.5.0.5\build\Fody.targets" Condition="Exists('..\..\..\packages_repo\Fody.5.0.5\build\Fody.targets')" />


And you'll get the following build failure in NCrunch:

Code:
..\..\..\packages_repo\Fody.5.0.5\build\Fody.targets (35, 5): The "Fody.WeavingTask" task could not be loaded from the assembly
Back to top
Remco
#2 Posted : Sunday, May 5, 2019 10:43:05 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Thanks for sharing this problem.

We have a bad pattern of running up against platform limitations when working in this particular area, so it's hard to say for certain right now whether it's possible for us to come up with a feasible fix for this. I've noted this down to be looked at in more detail. For now, if you're running this kind of setup, I recommend using the 'Additional files to include' setting to include referenced packages in NCrunch's workspace.
Back to top
LucasT
#3 Posted : Sunday, May 5, 2019 11:14:19 PM(UTC)
Rank: Member

Groups: Registered
Joined: 6/25/2015(UTC)
Posts: 11
Location: France

Was thanked: 1 time(s) in 1 post(s)
Ok, thanks. I've used the "Additional files to include" setting but it's not very convenient for some packages.

FYI this came up after some confusion following the removal of a NCrunch-specific workaround in Fody, which was thought to no longer be necessary (see here for details). If you think this will be hard to solve in NCrunch please keep me posted and I'll restore the fix in Fody. I don't think a lot of people are impacted, but at least my team is. :)

On a related note, I also added a similar fix to ANTLR, but in addition to the problem of copying the whole package, it also required copying of additional files from the project, that have a specific item type in the MSBuild sense (basically ANTLR assigns the 'Antlr4' item type to .g4 files and removes the associated 'None' items - the fix just restores the 'None' items back when under NCrunch). I don't know how difficult it would be to implement, but if you'd like similar scenarios to work in NCrunch without such fixes in the packages I think a good heuristic would be: if a file shows up in the solution explorer then copy it to the NCrunch workspace. Currently, a file of a custom item type seems to show up in the solution explorer when the item type has an associated PropertyPageSchema, but maybe the AvailableItemName item could be good enough.
Back to top
Remco
#4 Posted : Sunday, May 5, 2019 11:24:52 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
LucasT;13472 wrote:
Ok, thanks. I've used the "Additional files to include" setting but it's not very convenient for some packages.


Understood. Adding packages using this method used to be the primary (and only) way for NCrunch to work with them. It was like this for several years before the auto support was added to streamline things a bit more. Given that your case hasn't been flagged in here before, I think your situation is quite niche. We try to handle these sorts of situations but generally don't want to make big sacrifices for them (i.e. if we cut load time performance by 15% just to fix this issue, it just isn't worth it).

LucasT;13472 wrote:

On a related note, I also added a similar fix to ANTLR, but in addition to the problem of copying the whole package, it also required copying of additional files from the project, that have a specific item type in the MSBuild sense (basically ANTLR assigns the 'Antlr4' item type to .g4 files and removes the associated 'None' items - the fix just restores the 'None' items back when under NCrunch). I don't know how difficult it would be to implement, but if you'd like similar scenarios to work in NCrunch without such fixes in the packages I think a good heuristic would be: if a file shows up in the solution explorer then copy it to the NCrunch workspace. Currently, a file of a custom item type seems to show up in the solution explorer when the item type has an associated PropertyPageSchema, but maybe the AvailableItemName item could be good enough.


I've added the Antlr4 item type to NCrunch's auto inclusion list. So this will be automatically handled from the next release.

Greedily adding all files in a project's directory is something we've tried before and found it caused more problems than it solved. So we take a conservative approach here. Where NCrunch gets it wrong, you always have the power to choose what you want to include.
Back to top
LucasT
#5 Posted : Monday, May 6, 2019 8:27:14 AM(UTC)
Rank: Member

Groups: Registered
Joined: 6/25/2015(UTC)
Posts: 11
Location: France

Was thanked: 1 time(s) in 1 post(s)
Remco;13473 wrote:
We try to handle these sorts of situations but generally don't want to make big sacrifices for them (i.e. if we cut load time performance by 15% just to fix this issue, it just isn't worth it).

Sure, I understand that. I hope you'll manage to fix it without sacrificing performance.

BTW we use the "repositoryPath" setting in NuGet because it's the only viable way to work with projects (in the old format) that are referenced from multiple solutions in different directories. If you don't define a single packages directory, you'll have issues when installing packages from different solutions - it's not handled very well by VS as I suppose it has a similar issue in identifying package imports. I'd say I'm surprised no one reported this issue before, but I've been using the "Additional files to include" feature for a long time without noticing the "Auto-Detect NuGet Build Dependencies" feature even existed.

Remco;13473 wrote:
I've added the Antlr4 item type to NCrunch's auto inclusion list. So this will be automatically handled from the next release.

Thanks! But it's still a special-case solution for a single package, and you'd need to also include "Antlr4Tokens" and "Antlr4AbstractGrammar" to fully support this single package. It's a popular package but I suppose you don't want to do such special cases for everything. Do you think you could feed NCrunch's auto inclusion list from "AvailableItemName" MSBuild items instead? That would solve the issue in the general case.

See here for the ANTLR example - I suppose the condition on BuildingInsideVisualStudio could be removed if needed - I'm not sure why it's here in the first place.

Remco;13473 wrote:
Greedily adding all files in a project's directory is something we've tried before and found it caused more problems than it solved. So we take a conservative approach here.

I see, but I'd be more interested in that "AvailableItemName" thing than greedily bringing all the files.

The new project format already brings most of the files anyway, but the issue arises because you need to remove the file from "None" items in order for VS to play nice with your custom item type.
Back to top
Users browsing this topic
Guest
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.048 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download