Eternal restore loop when version is dynamically generated #1457
Comments
srivatsn
added
Blocking-Release
|
@abpiskunov I don't see this problem on d15rel.26202.1. Can you confirm it is fixed for you in that build? Closing for now. |
|
We've got another repro of this, more details forthcoming. |
|
It repros for me on One thing unusual about the repro project is |
|
|
|
Build error in VS: Output Window: |
Perhaps the root cause in my repro, is that the |
|
@natidea try to remove all obj/bin/.vs folders form teh solution form all projects, close VS and open solution again - that worked for me everytime to get that repro |
|
@natidea @abpiskunov: The solution from Anton does not repro on my install of |
|
@ericstj @weshaggard for the signing of the net standard package |
|
I was able to repro with @mikeharder 's project, but still can't repro with Anton's. Issue went away when I switched target framework to netcoreapp1.0 |
|
Stepping through @mikeharder 's project in a debugger, I see an infinite loop of subscription updates with the following sequence of changes to PackageReferences:
And so on. Each time this changes, we nominate NuGet to do a new restore. |
|
I'm no longer seeing this on my machine. I noticed that the NETStandard.Library package was updated to @weshaggard can you confirm the signing issue was fixed? |
|
Regardless of whether the signing issue was fixed, we should make it so that we never get into this state if there are bad packages. |
|
Yes the signing issue was fixed but I agree with @davkean we should guard against this as any nuget package could potentially get us into this state. |
|
/cc some NuGet folks for ideas on how a failures during restore could lead to project state changing in a way that produces this infinite loop. @emgarten @alpaix @rrelyea I'll note that the task that failed ( <HandlePackageFileConflictsAfter>ResolvePackageDependenciesForBuild</HandlePackageFileConflictsAfter>It seems likely that only packages with tasks that participate in this part of the build could put us in this broken state i.e. mostly our packages and partner teams. I'll drop the blocking release label. |
natidea
removed
the
Blocking-Release
|
I am experiencing an endless loop of restores in VS 2017 RC4+26206.0 when switching to a custom solution configuration. I have 3 solution configurations - Debug, Restore, Interop. Once I switch to the Interop configuration it would start doing restore in an endless loop. There are no errors just a repeating restore operation every second. I am having trouble isolating this. Is there some way to turn on diagnostics? I have changed the verbosity for Build and Run in Options to Diagnostic but this does not seem to affect the restore output. |
|
I have managed to get an isolated repro for my case. The repro solution: This is the project: <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<InteropVersion>$([System.DateTime]::Now.ToString(yyyyMMdd.HHmmss))</InteropVersion>
<PackageVersion Condition=" '$(Configuration)' == 'Interop' ">$(InteropVersion)</PackageVersion>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Interop|AnyCPU'" />
<PropertyGroup>
<TargetFramework>netstandard1.4</TargetFramework>
</PropertyGroup>
</Project>I would probably be able to workaround it by taking this into a post build action. It is strange that a change in the package version would trigger a restore as this is the version of the output package not the input dependencies. Also it seems that this is evaluated very often. |
|
PackageVersion gets written in the assets file, as that is where "dotnet pack" will get the appropriate version to reference as a package, for projectreferences. /cc: @alpaix @rohit21agrawal |
jmarolf
added
the
Triage-Investigate
|
Had this issue with VS 2019 16.5.5: details on Stack Overflow, someone also had this on MS Developer Community. |
|
This is still an issure in VS 2019 16.6. I had this in all of my csproj files which triggered the issue: <FileVersion>1.0.$([System.DateTime]::UtcNow.Date.Subtract($([System.DateTime]::Parse("2000-01-01"))).TotalDays).$([System.Math]::Floor($([MSBuild]::Divide($([System.DateTime]::UtcNow.TimeOfDay.TotalSeconds), 1.32))))</FileVersion>
<Version>1.0.$([System.DateTime]::UtcNow.Date.Subtract($([System.DateTime]::Parse("2000-01-01"))).TotalDays).$([System.Math]::Floor($([MSBuild]::Divide($([System.DateTime]::UtcNow.TimeOfDay.TotalSeconds), 1.32))))</Version>I was able to resolve it by backing off the <FileVersion>1.0.$([System.DateTime]::UtcNow.Date.Subtract($([System.DateTime]::Parse("2000-01-01"))).TotalDays).$([System.Math]::Floor($([MSBuild]::Divide($([System.DateTime]::UtcNow.TimeOfDay.TotalSeconds), 1.32))))</FileVersion>
<Version>1.0.$([System.DateTime]::UtcNow.Date.Subtract($([System.DateTime]::Parse("2000-01-01"))).TotalDays)</Version>but still keep it on the |
drewnoakes
changed the title
|
This is still an issue in 16.8.1 |
|
@RamjotSingh from Teams team has reported this issue through a VS feedback ticket. Any user action such as adding a class file, editing code in the IDE triggered a restore through project system nomination. The project had their patch version number set to @nkolev92 suggested a fix to this setting and there were no continuous restores after that. https://developercommunity2.visualstudio.com/t/Performance-issues-in-Visual-Studio-168/1280509 |
I tried using this as well. But my dynamic version does not get set at buildtime either. <PropertyGroup Condition="'$(DesignTimeBuild)' == 'false' OR '$(BuildingProject)' != 'true'">
<MajorVersion>0</MajorVersion>
<MinorVersion>0</MinorVersion>
<PatchVersion>$([System.DateTime]::Now.ToString("yyMMdd"))</PatchVersion>
<BuildVersion>$([System.DateTime]::Now.ToString("HHmmss"))</BuildVersion>
<PackageVersion>$(MajorVersion).$(MinorVersion).$(PatchVersion).$(BuildVersion)</PackageVersion>
</PropertyGroup>I noticed the note but with or without the false check it did not matter.
Neither did setting the Target. (After/Before Targets) <Target Name="AddAdditionalReferences" AfterTargets="ResolveAssemblyReferences">
...
</Target>Any help would be appreciated since this seems to be the best current solution for this problem. |
|
@visschersm The logic I created was this (the git stuff is from GitInfo) <Target Name="SetVersion" AfterTargets="_GitPopulateVersionInfo" BeforeTargets="CoreBuild">
<PropertyGroup Condition="'$(VersionSuffix)' == ''">
<VersionSuffix>0-alpha</VersionSuffix>
<VersionSuffix Condition="'$(DesignTimeBuild)' != 'true' OR '$(BuildingProject)' == 'true'">$(VersionSuffix)-$([System.DateTime]::UtcNow.ToString('yyyyMMddHHmmss'))</VersionSuffix>
</PropertyGroup>
<PropertyGroup>
<VersionSuffix Condition="'$(GitBranch)' != 'master' AND '$(GitBranch)' != '' AND '$(GitBranch.StartsWith(tags/release/))' == 'false'">$(VersionSuffix)-$(GitBranch.Replace("/", "-").Replace("_", "-").Split("^")[0])</VersionSuffix>
<Version>$(VersionPrefix)</Version>
<PackageVersion>$(VersionPrefix).$(VersionSuffix)</PackageVersion>
<AssemblyVersion>$(VersionPrefix)</AssemblyVersion>
</PropertyGroup>
<PropertyGroup Condition="$(VersionSuffix.Contains('-'))">
<FileVersion>$(AssemblyVersion).0</FileVersion>
</PropertyGroup>
<PropertyGroup Condition="!$(VersionSuffix.Contains('-'))">
<FileVersion>$(PackageVersion)</FileVersion>
</PropertyGroup>
</Target> |
|
@shmuelie Thanks for sharing! got it to work like this: <Target Name="SetVersion" BeforeTargets="Build">
<PropertyGroup>
<MajorVersion>0</MajorVersion>
<MinorVersion>0</MinorVersion>
<PatchVersion>$([System.DateTime]::Now.ToString("yyMMdd"))</PatchVersion>
<BuildVersion Condition="'$(DesignTimeBuild)' != 'true' OR '$(BuildingProject)' == 'true'">$([System.DateTime]::Now.ToString("HHmmss"))</BuildVersion>
<PackageVersion>$(MajorVersion).$(MinorVersion).$(PatchVersion).$(BuildVersion)</PackageVersion>
</PropertyGroup>
</Target> |
|
Im getting an infinite restore loop that does not have a project with a I write this incase someone else comes across it, even though i had automatic restores disabled, i had to also remove BOTH checkboxs on this options page to fix the issue.
|
|
For folks doing dynamic version numbers, I'd suggest you just use So, fixed version number for local builds FTW. My 2cents :) |
|
I have an issue/temp fix just like @captainjono . No dynamic version numbers over here. Project stuck in an infinite nuget restore loop. I unchecked the two things he unchecked but doesn't 100% resolve our issue. At least the infinite loop stops, but then we get sporadic build errors. Most common one is about Microsoft Store Engagement v10 missing - but its not, it's clearly installed, and the project has been compiling just fine for the last 3 years. A variety of other errors popup. To be able to compile again our current work around is:
Hope to see a fix soon! Will try to find time to build a small sample app, but probably wont have time for that in the near future. |
|
@melvyniandrag sounds like you are seeing a different issue. Could you please use the Report a Problem feature in VS and attach a recording of the problem happening? Without a repro, that's the most likely way of getting the issue understood and fixed. Alternatively, create a copy of your solution and start removing projects and source until you are left with a minimal repro. Restore happens at a project level, and I doubt your .cs files play a part. It's likely just a .csproj file that's needed here for a repro. |
|
@drewnoakes I am seeing the original feedback for this problem, but it's closed. Should I open a new issue if I am still seeing this issue? |
|
@seansparkman if you are using a dynamically generated version, then adding a feedback ticket would not be of much use. The problem is understood, and we don't consider it a supported scenario. Perhaps you could share the way you assign the version here, and we may be able to provide a workaround. If however you see a restore loop without having a dynamic version then yes, a feedback ticket with a recording of the problem occurring would be welcome. |
drewnoakes
added
Tenet-Performance
|
See also #9142, which is a dupe (but more focussed and with suggestions on how to address this.) |
and others
Open solution in this zip file:
\\vwdbuild01\Temp\antonpis\repro\RestoreLoopRepro.zip. It would start restore, restore fails and would start again - never stopping restore loop.I saw that on VS d15rel 26131.1.
The text was updated successfully, but these errors were encountered: