Found a workaround, and it explains partly why the local nuget cache isn't working.
If you a local version of all the packages and edit the AuthServer.csproj
<ItemGroup> <PackageReference Include="Volo.Abp.AspNetCore.Mvc.UI.Theme.LeptonX" Version="1.0.0-rc.*" /> </ItemGroup>
if you change this to
<ItemGroup> <PackageReference Include="Volo.Abp.AspNetCore.Mvc.UI.Theme.LeptonX" Version="1.0.0" /> </ItemGroup>
this seems to make the nuget version match up locally and you can build
Its unacceptable for our development environment and production deployments to be dependent on such a flimsy service. Its even more unacceptable to have no response on such a critical issue or any escalation procedure.
In our experience we have regular blips in the abp nuget feed, we are going to have to look at alternatives for our development and deployment environment I think.
In ABP IO the uptime of the nuget server is critical. We regularly seem to have issues with downtime or blips with certain packages, this is a larger discussion that needs to be had. In the short term, it would be very useful to have a is it up page, with a history of down times, scheduled maintenance etc.
Similar to https://status.slack.com/ or many others
Hi,
Starting around 10:16 gmt, we started having multiple build failures across various branches of work including both locally and remote builds. The errors are all the same:
Exception message and stack trace*error NU1101: Unable to find package Volo.Abp.AspNetCore.Mvc.UI.Theme.LeptonX. No packages exist with this id in source(s): ABP Commercial NuGet Source, BlazoriseMyGet, nuget.org
We are unable to build previously successful branches and the distribution between branches point to this not being a code related failure. The impact of this is high as we are unable to perform development remotely and locally.
Thanks Tom
