I'm on a project where we using a custom CLI command for dotnet and we want always have the latest version in our production projects.
So we decided to use * as Version identifier.
<DotNetCliToolReference Include="CustomPackageName" Version="*" />
This works on VS17. Executing nCrunch fails because of the following stack Trace:
System.IO.IOException: The path 'C:\Users\user\.nuget\packages\CustomPackageName\*' could not be processed because it is not of legal form
at nCrunch.Common.IO.DiskPath..ctor(String absolutePath, Boolean pathIsChecked)
at nCrunch.Common.IO.DirectoryPath..ctor(String , Boolean )
at nCrunch.Common.IO.DirectoryPath.GetDirectory(String directoryPathRelativeToDirectory)
at nCrunch.Compiler.UserNugetPackageDependency.GetFromCache(String packageName, String packageVersion, DirectoryPath& installPath)
at nCrunch.Client.ComponentLoader.SnapshotComponentLoader..(DotNetCliToolReference )
at System.Linq.Enumerable.WhereSelectArrayIterator`2.MoveNext()
at System.Collections.Generic.List`1.InsertRange(Int32 index, IEnumerable`1 collection)
at nCrunch.Common.Containers.ListExtensions.AddRange[T](IList`1 list, IEnumerable`1 range)
at nCrunch.Client.ComponentLoader.SnapshotComponentLoader.(ProcessorArchitecture , String )
at nCrunch.Client.ComponentLoader.SnapshotComponentLoader.CreateComponentFromXml(FilePath projectFilePath, ParsedBuildXml projectXml, FilePath solutionFilePath, String[] additionalFilesToIncludeAtSolutionLevel, Boolean isLoadedFromFile, VisualStudioVersion vsVersion, ComponentUniqueName componentName, TaskSettings componentTaskSettings, Exception parseException, String targetFramework)
It seems that nCrunch doe not follow the SemanticVersioning like VS17 do.
Using the Version 3.12.0.15 of nCrunch
thx
Build/Test Issues
.NET Core 2.x fails on DotNetCliToolReference with * as Version number
Started by JJauss on 3,459 views
Remco NCrunch Developer
#11566
28 Nov 2017 08:55 UTC
Hi, thanks for sharing this problem.
Yes, this makes sense. The DotNetCliToolReferences aren't represented in project.assets.json, so NCrunch has to do special parallel logic to identify this dependency. I wasn't aware that the '*' option existed, so naturally NCrunch can't handle it.
I'll see what we can do about getting this fixed in the next release. For the time being, I recommend specifying a version number as a workaround.
Yes, this makes sense. The DotNetCliToolReferences aren't represented in project.assets.json, so NCrunch has to do special parallel logic to identify this dependency. I wasn't aware that the '*' option existed, so naturally NCrunch can't handle it.
I'll see what we can do about getting this fixed in the next release. For the time being, I recommend specifying a version number as a workaround.
Hi, thanks for the fast reply.
For short the workaround will help, but we have to adjust VersionNumber each time we made a update to our CLI-Tool.
kind regards
For short the workaround will help, but we have to adjust VersionNumber each time we made a update to our CLI-Tool.
kind regards
Post a reply
Log in to reply.