Requiring Microsoft.ServiceFabric.Actors 2.4.164 raises warnings for later SF library versions

[Mardoxx]

My Project description is:

  <ItemGroup>
    <PackageReference Include="Autofac" Version="4.6.1" />
    <PackageReference Include="Autofac.Extensions.DependencyInjection" Version="4.2.0" />
    <PackageReference Include="Autofac.ServiceFabric" Version="1.0.0" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.ServiceFabric" Version="6.0.*" />
    <PackageReference Include="Microsoft.ServiceFabric.Data" Version="2.8.*" />
    <PackageReference Include="Microsoft.ServiceFabric.Services" Version="2.8.*" />
    <PackageReference Include="Microsoft.ServiceFabric.Services.Remoting" Version="2.8.*" />
  </ItemGroup>

I get the following warnings on compilation

warning NU1608: Detected package version outside of dependency constraint: Microsoft.ServiceFabric.Actors 2.4.164 requires Microsoft.ServiceFabric (= 5.4.164) but version Microsoft.ServiceFabric 6.0.211 was resolved.
warning NU1608: Detected package version outside of dependency constraint: Microsoft.ServiceFabric.Actors 2.4.164 requires Microsoft.ServiceFabric.Data (= 2.4.164) but version Microsoft.ServiceFabric.Data 2.8.211 was resolved.
warning NU1608: Detected package version outside of dependency constraint: Microsoft.ServiceFabric.Actors 2.4.164 requires Microsoft.ServiceFabric.Services (= 2.4.164) but version Microsoft.ServiceFabric.Services 2.8.211 was resolved.

I would guess this is because I am not explicitly referencing a later version of Microsoft.ServiceFabric.Actors? Not really sure.

Not really sure if this is an issue, but I like not having warnings when I build!

P.S. Been using Autofac.ServiceFabric for nearly 6 months now and it's been working flawlessly! Thanks! 😄

[janeski-zz]

I would like to create a PR with updated NuGet packages, since the current release is not compatible with SF 6.0 @alexmg, what do you think?

[alexmg]

@janeski I just upgraded the example project to SF 6.0 and did not come across any issues.

https://github.com/autofac/Examples/commit/d8fac6fb22132532ddaeafe72899f931bfa5737a

Are you seeing a particular incompatibility that may not be covered by the example project?

[janeski-zz]

@alexmg I will create test project with the concrete issue.

[alexmg]

Thanks @janeski.

[janeski-zz]

Hi @alexmg, I get the following error when I try to install the NuGet Package:

Detected package version outside of dependency constraint: Microsoft.ServiceFabric.Actors 2.4.164 requires Microsoft.ServiceFabric.Data (= 2.4.164) but version Microsoft.ServiceFabric.Data 2.8.232 was resolved. Detected package version outside of dependency constraint: Microsoft.ServiceFabric.Actors 2.4.164 requires Microsoft.ServiceFabric.Services (= 2.4.164) but version Microsoft.ServiceFabric.Services 2.8.232 was resolved. Version conflict detected for Microsoft.ServiceFabric. Reference the package directly from the project to resolve this issue. TestProject -> Microsoft.ServiceFabric.Services 2.8.232 -> Microsoft.ServiceFabric.Diagnostics.Internal 2.8.232 -> Microsoft.ServiceFabric (= 6.0.232) TestProject-> Autofac.ServiceFabric 1.0.0 -> Microsoft.ServiceFabric.Actors 2.4.164 -> Microsoft.ServiceFabric (= 5.4.164).

I still don't have the test project, but more or less this is the issue that I get.

[alexmg]

The dependency on Microsoft.ServiceFabric.Actors is not pinned to 2.4.164 and should be fine with anything under 3.0.0.

<dependency id="Microsoft.ServiceFabric.Actors" version="[2.4.164,3.0.0)" />

It sounds like NuGet warning NU1608 but I don't think that should apply in this case.

A resolve package is higher than a dependency constraint allows. In some cases this is intentional and the warning can be suppressed.

This is a bit strange because the Autofac.ServiceFabric package is not constrained to a specific version.

[newmancodes]

I've raised a PR which I hope addresses this problem.

[Lemraj]

I am experiencing the same problem with the latest update of service fabric.

warning nu1608: detected package version outside of dependency constraint: microsoft.servicefabric.services 2.8.232 requires microsoft.servicefabric.data (= 2.8.232) but version microsoft.servicefabric.data 3.0.456 was resolved.

To reproduce this, just create a new service fabric application, add a stateless asp.net core Web API and try to update the service fabric packages.

Any help? thanks.

---

Update: I solved this problem by uninstalling all the packages first and reinstalled them again. Still not clear why updating this packages is not enough!

[luntino]

Having the same issue just with the latest version of Microsoft.ServiceFabric packages on dotnet core. v6.1.480

NU1608: Detected package version outside of dependency constraint: Microsoft.ServiceFabric.Services.Remoting 3.0.456 requires Microsoft.ServiceFabric.Services (= 3.0.456) but version Microsoft.ServiceFabric.Services 3.0.480 was resolved. NU1608: Detected package version outside of dependency constraint: Microsoft.ServiceFabric.FabricTransport.Internal 3.0.456 requires Microsoft.ServiceFabric (= 6.1.456) but version Microsoft.ServiceFabric 6.1.480 was resolved. NU1107: Version conflict detected for Microsoft.ServiceFabric.Diagnostics.Internal. Reference the package directly from the project to resolve this issue. Adviser.SFA -> Microsoft.ServiceFabric.Services 3.0.480 -> Microsoft.ServiceFabric.Diagnostics.Internal (= 3.0.480) Adviser.SFA -> Autofac.ServiceFabric 2.0.0 -> Microsoft.ServiceFabric.Actors 3.0.456 -> Microsoft.ServiceFabric.Diagnostics.Internal (= 3.0.456).

FYI - I've also tried Autofac.ServiceFabric-devlop00035 from your myget but same issue (actually think its the same as v2.0.0)

Any chance you can update the dependency constraints?

[acrombez]

I got a similar issue when trying to reference Autofac.ServiceFabric to a project using the latest ServiceFabric release:

NU1608: Detected package version outside of dependency constraint: Microsoft.ServiceFabric.Actors 3.0.456 requires Microsoft.ServiceFabric.Services.Remoting (= 3.0.456) but version Microsoft.ServiceFabric.Services.Remoting 3.0.480 was resolved. NU1107: Version conflict detected for Microsoft.ServiceFabric.Diagnostics.Internal. Reference the package directly from the project to resolve this issue. ServiceApi -> Microsoft.ServiceFabric.Services 3.0.480 -> Microsoft.ServiceFabric.Diagnostics.Internal (= 3.0.480) ServiceApi -> Autofac.ServiceFabric 2.0.0 -> Microsoft.ServiceFabric.Actors 3.0.456 -> Microsoft.ServiceFabric.Diagnostics.Internal (= 3.0.456).

[leandroshan]

Hi, I've got the same issue but with a higher version. Any idea how to fix this?

NU1608: Detected package version outside of dependency constraint: Microsoft.ServiceFabric.Actors 3.0.456 requires Microsoft.ServiceFabric.Services.Remoting (= 3.0.456) but version Microsoft.ServiceFabric.Services.Remoting 3.1.306 was resolved. NU1107: Version conflict detected for Microsoft.ServiceFabric.Diagnostics.Internal. Reference the package directly from the project to resolve this issue. Symphony.Core -> Microsoft.ServiceFabric.Services.Remoting 3.1.306 -> Microsoft.ServiceFabric.Diagnostics.Internal (= 3.1.306) Symphony.Core -> Autofac.ServiceFabric 2.0.0 -> Microsoft.ServiceFabric.Actors 3.0.456 -> Microsoft.ServiceFabric.Diagnostics.Internal (= 3.0.456).

[pshrosbree]

The issue is that you must reference all the Service Fabric packages from your, say, stateless Service Fabric project. It is clunky and painful. I understand why many want to split AutoFac.ServiceFabric into separate packages for stateless, stateful and actor services.

On Tue, 17 Jul 2018 at 07:18, Leandro notifications@github.com wrote:

Hi, I've got the same issue but with a higher version. Any idea how to fix this?

NU1608: Detected package version outside of dependency constraint: Microsoft.ServiceFabric.Actors 3.0.456 requires Microsoft.ServiceFabric.Services.Remoting (= 3.0.456) but version Microsoft.ServiceFabric.Services.Remoting 3.1.306 was resolved. NU1107: Version conflict detected for Microsoft.ServiceFabric.Diagnostics.Internal. Reference the package directly from the project to resolve this issue. Symphony.Core -> Microsoft.ServiceFabric.Services.Remoting 3.1.306 -> Microsoft.ServiceFabric.Diagnostics.Internal (= 3.1.306) Symphony.Core -> Autofac.ServiceFabric 2.0.0 -> Microsoft.ServiceFabric.Actors 3.0.456 -> Microsoft.ServiceFabric.Diagnostics.Internal (= 3.0.456).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/autofac/Autofac.ServiceFabric/issues/18#issuecomment-405598299, or mute the thread https://github.com/notifications/unsubscribe-auth/AA5KcDWkQ5N1QGWpZiM78xbqRXYlmcC-ks5uHfI3gaJpZM4P1UhW .

[alexmg]

@pshrosbree is correct. Adding a direct reference to the other Service Fabric packages fixes the issue. For example, in the case of a stateless service project you still need to add the Microsoft.ServiceFabric.Actors package.

I tried declaring the Service Fabric package reference in Autofac.ServiceFabric using a range like [3.1.274,4.0) but unfortunately it doesn't resolve the issue.

I really don't want to split the project up into smaller pieces. We already have so many packages to maintain (including build system) and there would be a need for a core project with the shared logic resulting in three rather small packages.

I'm going to see if there is anything that can be done. It doesn't feel right having to keep releasing new packages every time a new Service Fabric update is made available.

[alexmg]

It turns out the Service Fabric packages are using exact version match in their package references which is causing the problem. I've raised an issue on the Service Fabric repository (see above) to find out if they can remove the exact version match.

[tillig]

Two years on and it looks like this isn't getting fixed on the Microsoft side. I think the best we can offer on the Autofac side is documentation to explain the gotcha here. While Autofac might be able to rely on a dependency range to allow some flexibility at the client level, it'll end up being the client's responsibility to directly reference the appropriate packages and make sure they're are all upgraded in lockstep.