It looks like only a part of BCL is supported for KRuntime. Is there a list of the assemblies in BCL that will be supported? ASP.NET vNext repositories don't include any of the System.* libraries. It would be useful to check if a library can be ported.
I also found useful this myget gallery for asp.net vnext dev branch or master branch
ASP.NET vNext has a package feed on MyGet. It looks like we can query it with NuGet.exe.
NuGet.exe list -Source "https://www.myget.org/F/aspnetvnext/api/v2"
Update:
Checking the feed with NuGet Package Explorer is a better alternative. You can easily open up package contents and see if KRuntime is supported. As far as I can see, not all of the packages listed there are supported on KRuntime.
Related
I am trying to install nuget package of log4net on a project with dual frameworks (.Net Framework and .Net Core) and it gives me an error of NU 1605 Downgrade Package Detected.
I have seen solutions telling me to clear the field of "Treat warnings as errors" but currently I am looking at a different solution, if possible.
Thank you in advance
Have you seen the official docs for NU1605?
It suggests adding a direct reference to the package in your project. This ensures NuGet's nearest-wins rule always selects the version you have as a direct dependency.
If the package with the downgrade warning is only being restored in .NET Core, you can use MSBuild condition statements to use the package only in one target framework, although there's no way to do this using NuGet's Package Manager UI or Package Manager Console. You'll need to hand edit your project file to use this.
I'm trying to use the following classes CredentialRequestInfo and Credential.
And as mentioned in ArcGIS Developers, in order to use the classes we need to install Esri.ArcGISRuntime nuget package.
But when installing the package, I get the following error:
The 'Esri.ArcGISRuntime' nuget package is not supported for the Target Framework 'netcoreapp2.2'
Is there a work-around we can do in order to use this nuget package? Or is there any updates or what?
After searching and talking with developers in esri. Found out that to use this nuget package I have to use .net core 3.1.
Esri.ArcGISRuntime will not work with .net core 2.2.
I am working with .Net Core 1.0 (running under the .Net Framework 4.6.1, non-portable).
I need to include some DLLs that are from a locally-built GitHub project. When I build those projects, and then attempt to "Add Reference" to the resulting DLLs, I get a message saying I can't add them to a Core project directly.
After more research, I found a lot of information regarding "private" NuGet packages. However, those seem overly complex / overly engineered.
Is there any way I can do the following:
Without having to go through the headache of creating a private NuGet repository, can I just "add reference" to the built assemblies that are sitting in the bin folder of the NuGet projects I pulled?
I really don't want to have to build a local-only NuGet package. Mostly because I've already wasted too much time on this issue, and because I read this entire concept is about to be scrapped and turned into something else (sounds familiar by now)... such as the Roslyn-based build system on GitHub.
My current state:
Visual Studio Professional 2015
.Net Core 1.0.1
.Net Core 1.0.1 Tooling Preview 2
No, as for now you have to create a nuget package before and restore it via Nuget. You can use a simple folder as NuGet source, so if you put your compiled NuGet package in C:\packages, you can add this as a source to NuGet (while in the NuGet UI, click the settings Icon and add the folder as new source).
This may change with the next release of ASP.NET Core (1.1), as the .NET/ASP.NET Core team is working to move from *.xproj to *.csproj files.
One of the reasons why you need to use nuget is because it can contain multiple targets and project.json allows you to target multiple platforms (i.e. net452 and netcoreapp1.0).
I started programming with .NET Core and ASP.NET Core and after reading many Docs/Tutorials i still am not sure of how to realize if a Nuget-(Meta-)Package is comptabile/usable within my .NET-Core-App.
How to check if a NuGet-Package is compatible with .NET Core.
E.g. the often recited Newtonsoft JSON. Is it compatible/usable - and how to see this?
Is there a list of all the available .NET Core packages?
(Like here it lists a few
key NuGet packages for .NET Core
). But since they say those are "key" packages i would assume there are more. But which?
The best way to understand compatibility is table here
In this table you can check what API version support NuGet package. If it is standard 1.0+ - it works with .Net Core
For checking (supported API version) dependencies on your package, you can check page of package on nuget.org or in your package manager
Here is an example for Rider
maybe that will be helpful - lots of popular packages https://github.com/thangchung/awesome-dotnet-core
I also don't see nuget.org mentioned anywhere so:
https://nuget.org
General rule of thumb for me is:
if package has a dependency on net standard or .net core, it will run with .net core(mind the versions also)
https://packagesearch.azurewebsites.net
Go to site and search for package to find its compatibility
Well, in fact you don't have to worry, the NET core application will indicate you if the package is compatible or not when you will run a dotnet restore command in your project.
Let say that you have the famous CSVHelper package registered in your csproj file :
<PackageReference Include="CsvHelper" Version="0.12.0"/>
Then, when you'll run any dotnet command such as build or run, you'll have the following input in the console in case of, here, cross-compatibility:
YourProjet/aspnetapp.csproj : warning NU1701: Package 'CsvHelper 0.12.0' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8' instead of the project target framework '.NETCoreApp,Version=v2.2'. This package may not be fully compatible with your project.
Basically, it mean that NET Core application can use ASP.NET NuGet package, and so far, I've never cross on a non-compatible package. Even if version is incorrect, the build will get the most recent matching version of the NuGet package.
Hoped it answer your question.
When I looked at the tutorials of MVC6, I get confused the usage of project.json. By my understanding this file is used to specify the project dependencies.
Prior to ASP.NET 5, we use nuget to manage the dependencies. But from some limited MVC6 samples I have seen I don't see people mention package.config any more.
Please help me to understand:
Do we still use nuget to upgrade all depending components?
Or we have to modify the project.json manually?
By my understanding [project.json] is used to specify the project dependencies.
Yes. One of the main functions of project.json is to manage server-side dependencies. (It also specifies other project specific settings.) See the project.json file for more info.
Prior to ASP.NET 5, we use nuget to manage the dependencies.
Yes again. And, ASP.NET 5 still uses NuGet to manage dependencies. The configuration differs though. Instead of using packages.config we use project.json > dependencies to list our project's NuGet packages (and other local dependencies.)
...from some limited MVC6 samples I have seen I don't see people mention package.config any more.
Yes again. Instead of package.config, ASP.NET 5 lists all dependencies, including NuGet packages, within project.json > dependencies. These dependencies can be NuGet packages, local assemblies, or local projects.
To expand on this, in Visual Studio, the References folder is a reflection of our project.json > dependencies section. What we add to the one will appear in the other. See server-side dependency management.
In some ways, you can think of the References folder as a GUI view of project.json > dependencies. For instance, here is a dependencies section from one of my projects alongside the References folder.
Note the one-to-one correspondence between what is listed in project.json and in the References folder (ignore the fx/ stuff that isn't in dependencies).
Note the the icons beside the items that References lists. These indicate whether the reference is a project, NuGet package (blue), or assembly.
Do we still use nuget to upgrade all depending components?
Yes. We just use it differently. If we add a NuGet package to our project.json - either manually or via the GUI's package manager - then we will restore/update those using the NuGet feed.
Or [do] we have to modify the project.json manually?
No. You can modify project.json manually but there are two mains ways to add NuGet packages. Which you use is personal preference.
Edit the project.json file manually.
Use the Visual Studio GUI.
Use the Visual Studio Code GUI.
Importantly, what you do to via the GUI will be reflected in the project.json file, and what you do to project.json > dependencies will be reflected in the GUI.
Do we still use nuget to upgrade all depending components?
The short answer is yes.
We have to modify the project.json manually?
You could also do that.
You can really do anything you want:
You could use the nuget package manager UI.
You could use nuget CLI through the Package Manager Console.
Or, you could even add, remove, change dependencies by modifying the project.json which has a really nice auto-complete like in the Package Manager Console.
The only difference now is that there isn't any mention of the installed packages in the project file (previously *.csproj), so yo don't have to add the references manually like when we had the packages.config.
Do we still use nuget to upgrade all depending components
No, you can just add them by your hand with the versions. Most of the IDEs and code editors has support for nuget dependency auto-complete inside project.json file.
More info on project.json file: https://github.com/aspnet/Home/wiki/Project.json-file (could be a little outdated).
More info on DNX dependencies: http://docs.asp.net/en/latest/dnx/overview.html?highlight=project#dependencies