Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Package downgrade for WindowsAzure.Storage 7.0.1-preview #16662

Closed
guardrex opened this issue Mar 10, 2016 · 15 comments
Closed

Package downgrade for WindowsAzure.Storage 7.0.1-preview #16662

guardrex opened this issue Mar 10, 2016 · 15 comments
Assignees
Milestone

Comments

@guardrex
Copy link

RE: WindowsAzure.Storage 6.2.2-preview

There is a package downgrade occurring (System.Xml.XmlSerializer) for dotnet cli projects on the CI feed going on over a month now ...

warn : Detected package downgrade: System.Xml.XmlSerializer from 4.0.10-beta-23109 to 
4.0.0-beta-23109 myapp (>= 1.0.0) -> WindowsAzure.Storage (>= 6.2.2-preview) -> 
System.Runtime.Serialization.Xml (>= 4.0.10-beta-23109) -> 
System.Private.DataContractSerialization (>= 4.0.0-beta-23109) -> 
System.Xml.XmlSerializer (>= 4.0.10-beta-23109)  myapp (>= 1.0.0) -> 
WindowsAzure.Storage (>= 6.2.2-preview) -> System.Xml.XmlSerializer (>= 4.0.0-beta-23109)

The Storage folks don't think they can do anything about this ...

Azure/azure-storage-net#230

... but they pinned to an old package ...

https://github.com/Azure/azure-storage-net/blob/master/Lib/AspNet/Microsoft.WindowsAzure.Storage/project.json#L52

@davidfowl suggested that I open this here and cc: @ericstj.

For reference: https://www.nuget.org/packages/System.Xml.XmlSerializer/

.NET Command Line Tools (1.0.0-beta-001653)

Product Information:
Version: 1.0.0-beta-001653
Commit Sha: 1fccdbd6ec

Runtime Environment:
OS Name: Windows
OS Version: 10.0.10240
OS Platform: Windows
Runtime Id: win10-x64

@ericstj
Copy link
Member

ericstj commented Mar 16, 2016

Azure storage should update to latest packages that support generations rather than hand-selecting old pre-release versions. They may be waiting for a public release of those packages on nuget, but if not they can do this today. Just point the project and dotnet-core myget feed and update all.

@guardrex
Copy link
Author

Short of pulling their source into my projects, there is nothing that can be done on our sides AFAICT, so I'll hope for a new preview package from their team.

As you can see, I tried to discuss this with them, and they didn't feel it was a priority. Actually, they wouldn't discuss it at all 😢.

@davidfowl told me what they are doing is "a problem" and to open this issue on it. However, should I close unless/until something actually breaks?

@ericstj
Copy link
Member

ericstj commented Mar 16, 2016

Downgrades are always breaking. It means things can be running under torn state. This could result in ref-def mismatch on load or worse, random different behavior.

I do think that the uber problem here is that they need to update dependencies to a consistent newer LKG. They may just be waiting for us to put that LKG on nuget.

If you reference a higher version won't it suppress nuget's warning?

@guardrex
Copy link
Author

@ericstj I'll definitely try that asap. I have an interview tomorrow with a company who thinks this homepage passes for good web dev ...

479 markup validation errors
323 markup warnings
112 accessibility validation errors
129 accessibility alerts
Google Mobile Speed: 36/100
Google Desktop Score: 44/100
12.3 MB payload, 92 requests, and 22 second load

You probably feel about the same way I do on that ... let me talk some sense to them (and about adopting .NET Core!!!) and I'll try your suggestion on the package downgrade and get back to you.

@guardrex
Copy link
Author

@ericstj Tried ...

"System.Xml.XmlSerializer": "4.0.10-beta-23109"

... resulted in ...

warn : Dependency specified was System.Xml.XmlSerializer (>= 4.0.10-beta-23109) but ended up 
with System.Xml.XmlSerializer 4.0.11-rc2-23826.

... so I tried ...

"System.Xml.XmlSerializer": "4.0.11-rc2-23826"

Licked it ... warnings gone and the library seems to function normally. I'll leave to you to close when appropriate. With the next Azure Storage preview/release, I'll check and ping back or re-open if the downgrade repros.

@guardrex
Copy link
Author

guardrex commented Apr 9, 2016

@ericstj Update: The Azure Storage team just released WindowsAzure.Storage 7.0.1-preview, and they're still downgrading System.Xml.XmlSerializer, which in turn is downgrading System.Runtime.Serialization.Primitives. I can silence the downgrades as before by providing deps for ...

"System.Xml.XmlSerializer": "4.0.11-*",
"System.Runtime.Serialization.Primitives": "4.0.11-beta-23409"

My apps work, so I'm ok right now. This is just an update here.

@guardrex
Copy link
Author

guardrex commented Apr 9, 2016

@ericstj... and one new package downgrade has cropped up with the new Azure Storage library ...

capture

... so I went looking for System.Threading.Tasks 4.0.10, but it doesn't appear in the main app. I checked one of the NuGet packages that I consume, and I did find it. It appears as a dep of these packages in the package's project.lock.json file ...

System.Collections.Concurrent/4.0.11-beta-23225
System.ComponentModel.EventBasedAsync/4.0.10
System.Net.Http/4.0.1-beta-23225
System.Private.Networking/4.0.1-beta-23225

... and the project.json of that NuGet package has ...

"dependencies": {
    "System.Console": "4.0.0-*",
    "WindowsAzure.Storage": "7.0.1-preview",
    "System.Xml.XmlSerializer": "4.0.11-*",
    "System.Runtime.Serialization.Primitives": "4.0.11-beta-23409"
},
"description": "GuardRex Corporation AppExceptions NuGet package.",
"frameworks": {
    "netstandard1.5": {
        "imports": [ "dnxcore50", "portable-net451+win8" ]
    }
},
"runtimes": {
    "win81-x64": {}
},

I don't think this is breaking me right now, so this is just an FYI.

@ericstj
Copy link
Member

ericstj commented Apr 11, 2016

This is just a symptom of `Microsoft.WindowsAzure.Storage needing to rebuild against the latest CoreFx packages. We make this work correctly at runtime because we're still shipping the incremented versions in the implementation assembly, but for compatibility with desktop we had to move the reference assembly back to 4.0.10.0.

@guardrex guardrex changed the title Package downgrade for WindowsAzure.Storage 6.2.2-preview Package downgrade for WindowsAzure.Storage 7.0.1-preview Apr 17, 2016
@guardrex
Copy link
Author

@ericstj ... and the hits just keep on com'in with WindowsAzure.Storage ...

To deal with WindowsAzure.Storage/7.0.1-preview and its deps ...

Errors in c:\_APPLICATIONS\www_xxxxxx_com\project.json
    Package WindowsAzure.Storage 7.0.1-preview is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0). Package WindowsAzure.Storage 7.0.1-preview supports:
      - dotnet5.4 (.NETPlatform,Version=v5.4)
      - net40 (.NETFramework,Version=v4.0)
      - portable-net45+win8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile111)
      - win8 (Windows,Version=v8.0)
      - wp8 (WindowsPhone,Version=v8.0)
      - wpa (WindowsPhoneApp,Version=v0.0)
    Package Newtonsoft.Json 8.0.3 is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0). Package Newtonsoft.Json 8.0.3 supports:
      - net20 (.NETFramework,Version=v2.0)
      - net35 (.NETFramework,Version=v3.5)
      - net40 (.NETFramework,Version=v4.0)
      - net45 (.NETFramework,Version=v4.5)
      - portable-dnxcore50+net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=net45+wp80+win8+wpa81+dnxcore50)
      - portable-net40+sl5+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile328)
    One or more packages are incompatible with .NETCoreApp,Version=v1.0.

... an imports with dotnet5.4 begins to silence these, then I get ...

Package Microsoft.Data.OData 5.6.4 is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0) / win81-x64. Package Microsoft.Data.OData 5.6.4 supports:
      - net40 (.NETFramework,Version=v4.0)
      - portable-net40+sl5+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile328)
      - portable-net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile259)
      - sl4 (Silverlight,Version=v4.0)
    Package Microsoft.Data.Services.Client 5.6.4 is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0) / win81-x64. Package Microsoft.Data.Services.Client 5.6.4 supports:
      - net40 (.NETFramework,Version=v4.0)
      - portable-net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile259)
      - sl4 (Silverlight,Version=v4.0)
    Package System.Spatial 5.6.4 is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0) / win81-x64. Package System.Spatial 5.6.4 supports:
      - net40 (.NETFramework,Version=v4.0)
      - portable-net40+sl5+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile328)
      - portable-net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile259)
      - sl4 (Silverlight,Version=v4.0)
    Package Newtonsoft.Json 8.0.3 is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0) / win81-x64. Package Newtonsoft.Json 8.0.3 supports:
      - net20 (.NETFramework,Version=v2.0)
      - net35 (.NETFramework,Version=v3.5)
      - net40 (.NETFramework,Version=v4.0)
      - net45 (.NETFramework,Version=v4.5)
      - portable-dnxcore50+net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=net45+wp80+win8+wpa81+dnxcore50)
      - portable-net40+sl5+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile328)
    Package Microsoft.Data.Edm 5.6.4 is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0) / win81-x64. Package Microsoft.Data.Edm 5.6.4 supports:
      - net40 (.NETFramework,Version=v4.0)
      - portable-net40+sl5+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile328)
      - portable-net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile259)
      - sl4 (Silverlight,Version=v4.0)

... so went to ...

"frameworks": {
    "netcoreapp1.0": {
        "imports": [ 
            "dotnet5.4", 
            "portable-net40+sl5+win8+wp8+wpa81", 
            "portable-net45+win8+wp8+wpa81" ]
    }
},

... to silence everything, I still can't get a restore ...

    System.Diagnostics.TraceSource 4.0.0-beta-23225 provides a compile-time reference assembly for System.Diagnostics.TraceSource on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with win81-x64.
    System.Runtime.Serialization.Xml 4.0.10-beta-23109 provides a compile-time reference assembly for System.Runtime.Serialization.Xml on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with win81-x64.
    System.Xml.XmlSerializer 4.0.0-beta-23109 provides a compile-time reference assembly for System.Xml.XmlSerializer on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with win81-x64.
    One or more packages are incompatible with .NETCoreApp,Version=v1.0 (win81-x64).

David says 'you have packages that bring in old versions of stuff.' Well, "they" would sound a little better, but I take the point. Next, I'm going to try to clone them and fix their packages, and I have very little confidence that I'll be able to do that. We'll see.

@ericstj
Copy link
Member

ericstj commented Apr 18, 2016

Imports isn't a good solution, that means you'll end up picking up a PCL group from the packages that doesn't list dependencies.

Instead just reference without imports and deal with the old references by referencing the latest from your project.

@guardrex
Copy link
Author

@ericstj Thanks, but I decided to punt on this. I'm in the process of implementing Azure Storage REST API.

Since there is nothing wrong other than that team not keeping their preview (or a preview) up with latest over here, I'm going to close this. I'll go back to their lib when they catch up, perhaps RTM-time. Thanks again for your help.

@guardrex
Copy link
Author

Note for temporary reference as we wait on an updated Azure Storage lib for RC2 release: I just found out from @Bartmax that

"frameworks": {
    "netcoreapp1.0": {
        "imports": [ "portable-net45+win8" ]
    }
},

... will get the whole package restored.

However, rc1-final DNX-era bits in a shiny new RC2 app!!?? I don't think so. I'll stick with Azure Storage REST API until we get a proper preview package from them.

@markrendle
Copy link

markrendle commented May 17, 2016

I suspect the Azure Storage SDK team are waiting for .NET Core packages from their upstream dependencies before starting their own work.

Azure-SDK-for-Net, which provides the Microsoft.Azure.KeyVault package, have this Core RC2 issue in their "Azure SDK Team May Sprint" milestone, so that's promising.

Then there's OData, which doesn't seem to be aware that the .NET world is changing around them, so I've opened an issue there.

This all needs to be much more joined up. Getting libraries and packages across the Microsoft ecosystem up and running on Core should be Priority 1 for SDK teams for the next six weeks.

@guardrex
Copy link
Author

@markrendle They're working on it now. Azure/azure-storage-net#274

@Bartmax
Copy link

Bartmax commented May 19, 2016

workaround: dotnet/aspnetcore#1469

@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the 1.0.0-rtm milestone Jan 31, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Jan 2, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants