The recommendation is to use Microsoft.AspNetCore.All in .NET Core 2 as it simplifies dependencies and uses tree shaker magic to not bloat what you publish.
I encountered one issue of moving to it: When using a library that references StackExchange.Redis, I ended up with a conflict as something within Microsoft.AspNetCore.All references StackExchange.Redis.StrongName. See question VS.NET 2017 forces using StackExchange.Redis 1.2.4.0 in ASP.NET 2.0 Core app for further info. If I stick to referencing dependencies individually then I avoid this conflict and can compile.
Other than getting conflicts between things you don't use from Microsoft.AspNetCore.All, what are the other issues could you encounter because of this recommendation?
IMHO it is not a usual issue since there are not many libraries out there published twice with the same types, in two different packages: one strongly named and one not. Especially being referenced by the metapackage Microsoft.AspNetCore.All 2.0.0
You are definitely not the only one with this StackExchange.Redis issue (I stumbled across it twice already) but the maintainers are planning to drop the StrongName package on version 2.0.
You can try dealing with it with the extern alias approach discussed here.
A quick way around it is to target the same package AspNetCore targets (the StrongName one). In case it's just a project within a solution you work with, it's an easy hack.
Another is to target Microsoft.Extensions.Caching.Redis. That's what the metapackage depends on.
That's until SE.Redis releases version 2.0.0.
Related
I want to change one of my library to the latest version. where to find the version of the dependency in play.
In general, you can see a list of Play's direct dependencies by checking the project/Dependencies.scala file in the source code for that version of Play. For version 2.4.3, that file is here: https://github.com/playframework/playframework/blob/2.4.3/framework/project/Dependencies.scala
In the specific case of Jackson, the group ID and module structure changed between Jackson 1.x and 2.x. Play 2.4.3 is using Jackson 2.5.4. If your project depends on Jackson 1.8.5, this dependency isn't coming from Play, but from some other source.
You can use the sbt-dependency-graph plugin to view the full tree of transitive dependencies and see where it is introduced.
To update to a newer version, you can add a direct dependency to your build.sbt with the desired version:
libraryDependencies += "org.codehaus.jackson" % "jackson-mapper-asl" % "1.9.13"
This will override the version requested by other libraries; by default, sbt will use the greatest version requested.
However, there are a few things to keep in mind:
Jackson is composed of several sub-modules. If you are using several of these in the same project, including transitively, it's a good idea to use the same version of all of them. This might require adding additional dependencies to your project to keep them all in sync.
When upgrading dependencies in your application that are also used by other libraries it depends on, you'll need to consider backward compatibility. Jackson is not always fully backward compatible between minor versions, so if you update to a newer version of Jackson than what your libraries were designed to use, you might encounter problems at runtime.
Using both Jackson 1.x and 2.x in the same project is possible, since they have different group IDs and Java package names, but it may be confusing and error prone. If you can, it would be better to standardise on the Jackson version that is used by the Play Framework version you choose.
I'm building a project as part of a course, I didn't build it from scratch but I've got it at a stable level that compiles perfectly with no errors or warnings.
I need to add Entity Framework Core. The video shows the instructor installing 2.1.4 even though the latest is 3.1.4. What the heck, I install the older version. Everything's still peachy.
But I don't want 2.1.4, I want 3.1.4. I won't go into the reasons, but suffice to say that version supports EDMX. Please don't question me on that. Incidentally I have 3 projects in the solution and only one of them had the EF Core installed. Does that matter? Anyway, after installing 3.1.4 in that one project I get this.
Error NU1107 Version conflict detected for Microsoft.EntityFrameworkCore. Install/reference Microsoft.EntityFrameworkCore 3.1.4 directly to project OdeToFood to resolve this issue.
OdeToFood -> OdeToFood.Data -> Microsoft.EntityFrameworkCore (>= 3.1.4)
OdeToFood -> Microsoft.AspNetCore.App 2.1.1 -> Microsoft.EntityFrameworkCore (>= 2.1.1 && < 2.2.0). OdeToFood D:\Visual Studio Projects\OdeToFood\OdeToFood\OdeToFood.csproj 1
OdeToFOod is the project, OdeToFood.Data is the one of three projects I added EF Core to.
Dear Microsoft, is it asking too much for you to give your error messages in something resembling English? I'm at my wits end with this stupid project. The error message SEEMS to be saying to install 3.1.4 directly to that project. Isn't that what I just did?! Perhaps they mean right-click the project and say manage Nuget for that project instead of "Manage Packages for Solution"? Doesn't make sense to me, but I'll try it. So when I do that it (obviously) already shows 3.1.4 as installed, so that can't be it. So why don't we start nice and fresh, huh? Let's uninstall 3.1.4 from that project and re-install.
Nope. Same error message except this time it mentions a different project, one that never had EF Core installed in the first place. Okay fine Microsoft, I'll play your game. So even though I have no use for it in this second project, I'll install it anyway. Let's see what happens shall we?
OMG.... DISASTER!!!! It's now worse! I still have that error message, but now I have a "package out of dependency constraint" (English please??) and it references ANOTHER package that now has a version conflict, one that hasn't even been touched. What the hell is going on here? I'll bet at this point I can't even go back to Core 2.1.4 anymore. There's got to be some config file or .csproj or something that I can edit because this is unbelievable. I'm trying to follow the directions as best as I can understand them (which isn't much) and it keeps getting worse. And not only that but it appears that EF Core never DID install on this other project anyway so I think there's no fixing this problem at this point, I'm going to have to restore from backup and start over. Why does Microsoft have to make everything so freaking complicated?! Can they at least make this a little more forgiving and user friendly so it doesn't take a PhD to figure out these errors?
I'm just a beginner at this but how am I supposed to learn this if I can't even get a simple thing like this to compile? I try to follow the directions as best I can and that only makes things worse. I'm ready to declare this project FUBAR, throw my computer through a window, buy a sheep farm and never code again!
We love Scott Allen and his tutorials :)
Seems like scoot have updated entity framework with latest version. Link below
GitHub Repository
If you want to update by yourself i suggest to remove ef Core 2.1 packages from odeToFood & OdeToFood.Data project and install ef core 3.1 in both project accordingly. Hopefully this will resolve the issue. Happy learning.
I am in process of prepping my Windows Desktop app for upload to the MS Store. I have a (fully functional) MSI installer for my app and attempted to use the Desktop App Converter (DAC) but experienced an error and have not gotten past it yet. So I decided to give manual package (appx) creation a try and it went well since I was able to install my app using the package I created. But I have a question about how to handle my .NET Framework dependency in the package. My MSI Installer has the '.NET Framework version 4.7.1' as a prerequisite so that it gets downloaded and installed (from MS, if not already installed). My question is how to handle the prerequisite in my package. I'm assuming it would go in the AppxManifest.xml under Dependencies where I currently have (note I removed the brackets so my code would display here)...
Dependencies
TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.14316.0" MaxVersionTested="10.0.16299.309" /
/Dependencies
...but I am unsure of the syntax to add .NET Framework 4.7.1 so that it gets properly installed (if not already there) on target systems for my app.
Thanks!
If the app has 4.7.1 as a prerequisite, they will need to set their minversion to 16299 (Fall Creators Update).
In general, you cannot redist .NET with your app package, as it comes with the OS. But if you require a specific version, you need to make sure the minversion matches the update of Win10 that includes that specific version. You could use this table to look it up: .NET Framework Versions and Dependencies.
I've been working to get NuGet versioning squared away in my ASP Core project and have come across some odd behaviors and would like to ask why they decided to do it this way.
1) Choose the lowest version in a range.
ex: [1.0.0, 2.0.0) Does not mean choose the most recentversion in 1.X.X but choose the lowest version, basically always 1.0.0 and never update.
2) Setting the specific version chooses a different version
ex: "1.0.0" will really select "1.0.X".
This one really concerns me. I want to make sure that when I tag code, using a specific version, all future builds will always use the same version. With this implementation, builds are not guaranteed to be reproducible!
I'm coming from using Maven and NPM and am trying to keep an open mind to other ways of doing versioning, but these two baffle me.
Please help me understand why they would do this, basically backwards from other package manager solutions.
You can use a floating version if you want the most recent version, ex 1.0.*.
I think you're incorrect here. If 1.0.0 is requested, it'll install 1.0.0 if 1.0.0 is available on the NuGet server. If it's not found on the server, it'll install the next closest version found, 1.0.1.
This is pretty well documented at
http://docs.nuget.org/consume/ProjectJson-Dependency#dependency-resolution-in-nuget-v3-/-project.json
My custom class library (targeting .NET 4.5.1) references Newtonsoft.Json 8.0.2 (the latest version to date). I've added this class library as a reference to a new ASP.NET 5 Web API project.
From the Error List output:
Error NU1002 The dependency Newtonsoft.Json 1.0.0 in project MyProject does not support framework DNXCore,Version=v5.0.
That part seems somewhat self-explanatory, however, I couldn't understand why it was changing my referenced version to 1.0.0.
From the References --> DNX 4.5.1 --> MyClassLibrary Node:
NU1007 Dependency specified was Newtonsoft.Json >= 8.0.2 but ended up with Newtonsoft.Json 1.0.0.
I've tried removing/re-adding the references several times, all to no avail. I did notice that several of the ASP.NET libraries use Newtonsoft.Json 6.0.6 -- I'm not sure if this has anything to do with it.
If I navigate to the wrap folder --> Newtonsoft.Json --> json file, and replace "Newtonsoft.Json 1.0.0-*" with "Newtonsoft.Json 8.0.2-*", it fixes the references for the DNX 4.5.1 node.
However, errors still show afterwards saying that Newtonsoft.Json 8.0.2 referenced in my class library does not support DNXCore 50.
I'm at a loss as to what to do. Any help would be greatly appreciated.
Answer to my issue:
Thanks to Oleg's response I was able to make it work -- however there were two hurdles. One was the "wrap" folder that was created for Newtonsoft.Json. In the root of my solution was a "wrap" folder that contained a folder called Newtonsoft.Json. Apparently(?) that folder shouldn't have been created (how it was created I have no idea). Once removing that, I was able to add a reference to my custom class library without any errors referencing Newtonsoft.Json.
However when I began trying to use my custom assembly as in code, I would get an error about DNX50 not being supported -- which sort've makes sense because my custom referenced assembly was a .NET 4.5.1 class library.
This GitHub link has many people experiencing a similar issue
However, I managed to get everything to build and errors to go away by removing targeting for DNXCore50. This worked for me because I was just wanting to share some POCO data models between a Web API and WPF project. I'm not interested in targeting DNXCore at the moment.
I'm looking forward to the future of ASP.NET, but the newness is a bit challenging, at least for me.