I am trying to download a package that will allow me to encrypt and decrypt passwords. However, I can not find a package that is compatible with my project as I am working in .NETStandard.
Is there a way to make a package that is not fully compatible still work?
When I try to change my project to a .NETFramework I do not get the option of any .NETFrameworks...
Despite another project in the same solution being targeted to .NETFramework v4.6.1
Solutions:
Are there any .NETStandard password encryption packages?
Is there a way to search for .NETStandard compatiable packages?
Can I make my project target a .NETFramework even though it is not an option, but is downloaded?
The warning itself is just a warning but the library might still work fully well, especially when you are actually targeting .NET Framework 4.6.1 with your project.
Basically when you create a .NET Standard library, it targets a specific version of .NET Standard and you can imagine .NET Standard as a set of interfaces a platform that supports that version of .NET Standard must support. In this case, if you are targeting .NET Framework 4.6.1 with the app, the .NET Standard library will run on .NET Framework 4.6.1 anyway, so there shouldn't be any problem.
Problems could occur if you built another client targeting a different implementation of .NET like .NET Core or Mono, which wouldn't support some of the APIs that the library is using internally. In such case the application would crash once such API was accessed because the platform does not offer any implementation of it.
In case you don't require cross-platform support, you could just use classic .NET Framework library, instead of .NET Standard and the warning would disappear.
I'm personally using RSACryptoServiceProvider
from System.Security.Cryptography. This is available in .NET standard. Doesn't need any nuget packages either.
using System.Security.Cryptography;
Edit:
I should add to this that encrypting/decrypting password is never a good idea. Password should be stored as a hash width a strong one way hasing algorithm and should never be encrypted for decryption for later use.
Related
I have a net6.0 SDK-style project and I want to use a library which seems to be only released to .net framework. After I added the reference, I got a warning as below. And for sure I can't use any classes from the lib in my code.
Package 'xxx' 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 'net6.0'. This package may not be fully compatible with your project.
I'm new to C#. Does it mean that each lib only works for specific .net versions? Library developers declare and compile their code for the supported .net versions and publish to nuget. When we refer to a nuget lib, nuget will try to find the dll which matches our .net version and throw the above warning if not found.
That is to say, to be compat with the library, I have to downgrade my project to net472?
Yes, that is correct. Each library is typically compiled for specific versions of .NET.
If you want to use this library, you will need to downgrade your project to target one of the supported .NET Framework versions.
Does it mean that each lib only works for specific .net versions?
It is more nuanced than that; usually, libraries are perfectly happy with lower versions - meaning: if I target net5.0 from a library, and your application is net7.0: that's fine (with the caveat that even minor revisions can - but rarely - break something, if it was depending on functionality that has changed, perhaps because it was a bug - or some other implementation detail).
However, there is a hard break between .NET Framework and .NET Core (now just .NET); a .NET Core / .NET application cannot reliably consume a library that only targets .NET Framework, as .NET Framework is a fundamentally different framework than .NET Core / .NET.
In this scenario, libraries can do a few things to help you:
they can target some variant of .NET Standard, which is the subset of APIs that should work correctly on both .NET Framework and .NET Core / .NET (and other platforms that implement .NET Standard, such as Unity, Mono, Xamarin, etc as)
they can multi-target, which is to say: in the nupkg they can include multiple assemblies, perhaps a net472 target, a net6.0 target, and maybe one or two others
(the second option is more common than the first; .NET Standard is fading into the background now)
If the library you're using only supports .NET Framework, then indeed that won't work from .NET Core / .NET; you have three options:
limit yourself to .NET Framework (I do not recommend this option)
see if the library can be updated to use .NET Core / .NET (by contacting the maintainers, and possibly even proposing the changes yourself)
use a different library
I'm having a .Net 4.7.2 application, in which I want to reference the package OpcFoundation.NetStandard.Opc.Ua. This project as a list of dependencies for .Net 4.6 that is quite small.
But when I install it, I get like 50+ additional packages to install. Is there a way to reduce this? I feel that a lot of thoses classes are already existing in the full .Net project(System.Threading.Tasks/Timer/...).
Thank you
If you look at many of these types (which are supplied by .NET Standard packages, not .NET Core), you'll find that the specific version that's used against .NET 4.7.2 will be an empty assembly just containing lots of TypeForwardedTo attributes pointing right back at the full-flavour .NET Framework.
So you still end up using the exact types you always would have done. There's just extra indirections which allows .NET Standard to work with both .NET Framework, .NET Core and other .NET Standard implementations.
We have a legacy VB.NET application. The frontend is being redesigned in MVC 5, and I was assigned to abstract the business logic to an API.
I created a library with some code to make calls to the API (so the developer building the MVC 5 app can easily install/update the package and use it).
But I would like to help the developer responsible to redesign the VB.NET project to consume the API with the same NuGet package.
Is it possible to create one NuGet package compatible with both, or do I really need to make two packages?
I read something about .NET Standard, but I couldn't find anything about VB.NET, it looks they work for C# only (I'm not sure).
If it's possible, should the VB.NET project use the same .net framework version as the package in order to work?
A compiled .Net DLL is language agnostic: you can use a DLL written in any .Net language from any .Net language.
Note that in general you can only reference .Net DLL (.Net assembly) that is compiled for that or lower version of .Net compared to one you set target .Net version of code you compile. Ideally both DLL (on in NuGet and VB.Net) target the same .Net version, otherwise read MSDN: Version Compatibility in the .NET Framework.
The language does not matter for .Net Nuget packages because they all compile to the framework(s) they target. This means C# assemblies compiled from C# code can be decompiled into C# or VB .Net regardless of the original language they were created in.
A little more detail:
Nuget packages are limited by the framework version they target, so your legacy app should preferably target the latest version of the .Net framework (4.7.1 as of this post) if you want to maximally utilise third party libraries and target the latest .net standard (2.0 as of writing).
.Net Standard is a compatibility standard, which means that if a language runtime version supports that version of the standard, it is guaranteed to have certain APIs available.
https://learn.microsoft.com/en-us/dotnet/standard/net-standard
Based on the table in that documentation, if your legacy application is targeting .net framework 4.5, you can only build libraries that target .net standard 1.1. Any higher version for your nuget package will prevent you from using it in your legacy app.
I have a Xamarin Forms project and the majority of times that I want to install a nuget package I have an error saying that:
Install-Package : Could not install package 'Microcharts 0.7.1-pre'. You are trying to install this package into a project that targets
'.NETPortable,Version=v4.5,Profile=Profile259', but the package does not contain any assembly references or content files that are compatible with that framework.
I Assume I can work this out by changing the project .net framework target. But when I go and change it, I get an error saying that it cannot change the target because that implies upgrading nuget to 3.0 and It can´t do that.
So my question is: Which is the best way(and simplest) to change the target framework so I have less problems like above with nuget packages.
This library was built to target .NETStandard v1.4. You are trying to use it in a PCL project, that is not possible. PCL is on the way out as the previous not-so-good way to build cross-platform libraries, .NETStandard is the new way.
There is no older version available of this library, rebuilding it from source is a possible option. But realistically it is time to move on to avoid hitting this wall over and over again, you need to update your tooling so you can consume these kind of libraries. The VS2017 Community edition is freeware.
It is time to go from your
.NET PCL Library to an appropriate .NET Standard Library.
Here are some links concerning the migration to .NET Standard.
Upgrade PCL to .NET Standard Class Library
.NET Standard 2.0 Support in Xamarin.Forms
Converting PCL (Portable Class Libraries) to .NET Standard Class Libraries
.NET Standard - PCL Compatibility
.NET Standard Implementation Support
My Suggestion concerning the version of the .NET Standard to use.
If you don't care about backwards compatibility (You want to use the latest OS and SDKs) go all the way to .NET Standard 2.
If you want to have a good backward compatibility you should go on .NET Standard 1.1 - 1.5.
On most projects i use 1.4 - 1.5.
I just can't understand why I can't use an old library in a .net Core app targeting Windows and the full .net framework (I don't care about multi-platform).
Just trying to understand the limits here. I don't want to hit a wall after investing too much into it.
Steps followed:
Create a new .Net core web Application
Added PetaPoco from NuGet (just an example)
Can't use the library
From a comment from you on a deleted answer to this question
It's not about this particular reference. I just want to understand why I can't use an arbitrary Windows DLL. (I don't care about multi-platform) – Eduardo Molteni
It appears you are not too concerned why this specific project is not working (the deleted answer you commented on covered that quite well and if it was not deleted I would have up-voted it) but why in general you can't use a .NET Framework DLL in a .NET Core project.
Here is a diagram showing the layout of the ".NET ecosystem"
Things built for .NET Framework can't use DLLs built specifically for .NET Core, and things built for .NET Core can't use DLLs built specifically for .NET Framework because they are two "siblings" in the hierarchy.
Both .NET Framework and .NET Core can use .NET Standard libraries in their projects because .NET Standard is the "parent" of both the framework and core. Many newer NuGet packages now release versions that target .NET Standard so the library can be used with both versions. See the below chart to see what version of the .NET Standard library is compatible with various platforms. netstandard libraries are forward compatible so something that is compatible with 1.5 (like .NET 4.6.2) is also compatible with versions 1.0-1.4