Dolittle - Development We had an incident with our new Azure Pipelines which we can’t quite explain. Our pipelines are doing a cascade build to projects that build on top of packages from other repositories. This seems to have a bug in it and it is not consistently pulling the correct code and ends up building things with wrong versions. This happened to the .NET SDK packages today and all of a sudden we were publishing 4.* code under the 3.* major version. We have as a consequence unlisted the wrongfully published packages and hopefully this didn’t cause trouble for you. We saw this on someones computer today and it got into a state that looks like some weird caching issue, we’re hoping it all goes away after NuGet has eventually become consistent . We’ve disabled cascading for now to avoid this problem, and the version numbers you don’t want to have are 3.1.8 and 3.1.9 of any Dolittle.SDK.* packages.
@einari What is the behaviour if this case strikes? We’re currently struggling to start an application with the following error message, and wonder if it is connected?
Application startup exception: Autofac.Core.DependencyResolutionException: An exception was thrown while activating ?:Microsoft.AspNetCore.Routing.EndpointDataSource -> Microsoft.AspNetCore.Mvc.Internal.MvcEndpointDataSource. ---> Autofac.Core.DependencyResolutionException: An exception was thrown while invoking the constructor 'Void .ctor(Microsoft.AspNetCore.Mvc.Infrastructure.IActionDescriptorCollectionProvider, Microsoft.AspNetCore.Mvc.Internal.MvcEndpointInvokerFactory, Microsoft.AspNetCore.Routing.ParameterPolicyFactory)' on type 'MvcEndpointDataSource'. ---> System.IO.FileLoadException: Could not load file or assembly 'Dolittle.SDK.Commands, Version=22.214.171.124, Culture=neutral, PublicKeyToken=null'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) at System.Signature.GetSignature(Void* pCorSig, Int32 cCorSig, RuntimeFieldHandleInternal fieldHandle, IRuntimeMethodInfo methodHandle, RuntimeType declaringType) at System.Reflection.RuntimeMethodInfo.FetchNonReturnParameters() at System.Reflection.RuntimeMethodInfo.GetParameters() at Microsoft.AspNetCore.Mvc.Internal.DefaultApplicationModelProvider.OnProvidersExecuting(ApplicationModelProviderContext context) at Microsoft.AspNetCore.Mvc.Internal.ControllerActionDescriptorProvider.BuildModel() at Microsoft.AspNetCore.Mvc.Internal.ControllerActionDescriptorProvider.GetDescriptors() at Microsoft.AspNetCore.Mvc.Internal.ControllerActionDescriptorProvider.OnProvidersExecuting(ActionDescriptorProviderContext context) at Microsoft.AspNetCore.Mvc.Infrastructure.DefaultActionDescriptorCollectionProvider.UpdateCollection() at Microsoft.AspNetCore.Mvc.Infrastructure.DefaultActionDescriptorCollectionProvider.Initialize() at Microsoft.AspNetCore.Mvc.Infrastructure.DefaultActionDescriptorCollectionProvider.GetChangeToken() at Microsoft.AspNetCore.Mvc.Internal.MvcEndpointDataSource.<>c__DisplayClass7_0.<.ctor>b__0() at Microsoft.Extensions.Primitives.ChangeToken.OnChange(Func`1 changeTokenProducer, Action changeTokenConsumer) at Microsoft.AspNetCore.Mvc.Internal.MvcEndpointDataSource..ctor(IActionDescriptorCollectionProvider actions, MvcEndpointInvokerFactory invokerFactory, ParameterPolicyFactory parameterPolicyFactory) at lambda_method(Closure , Object ) at Autofac.Core.Activators.Reflection.ConstructorParameterBinding.Instantiate() in C:\projects\autofac\src\Autofac\Core\Activators\Reflection\ConstructorParameterBinding.cs:line 127 --- End of inner exception stack trace --- at Autofac.Core.Activators.Reflection.ConstructorParameterBinding.Instantiate() in C:\projects\autofac\src\Autofac\Core\Activators\Reflection\ConstructorParameterBinding.cs:line 135 at Autofac.Core.Activators.Reflection.ReflectionActivator.ActivateInstance(IComponentContext context, IEnumerable`1 parameters) in C:\projects\autofac\src\Autofac\Core\Activators\Reflection\ReflectionActivator.cs:line 120
This is what happens and we have now figured out that NuGet has an unexpected (on our part) behavior. When using a wildcard reference it will get the latest version, even when that is marked as unlisted. That took us by surprise a bit. The remedy is to release a new version that has a higher number, and something we’re in the midst of doing - just doing it manually and very careful right now. Hopefully within an hour or two, we’ll have it rectified.
Sorry for the inconvenience this is causing to everyone running into this.
Mistakes happen, and I (and others) really appreciate the openness and willingness to get this into a working state.
Its all working again. A bit cleaner cut as well, gone through all layers and deployed with the correct references. This should make it more consistent, even more than before we had this incident.
It is safe to do a 3.* on version on everything Dolittle.
The affected repositories are:
These are now consistently on the latest version referencing the correct versions all the way through.
Confirmed! We’re up an running again!
As far as I can tell, unlisting a nuget package will mean that you cannot pull that package unless you explicitly request it except where that unlisted package is the latest version. I find this very counter-intuitive.
So if this happens, you need to pretty much publish another version to make sure that is latest.
You live and learn.