I have two computers.
I was working with computer one to make a prototype of a project. I have created a .NET Standard 2.0 class library and added a .NET Framework 4.6.1 class library. I have referenced .NET Standard to .NET Framework and everything was working.
Now I've switched to computer two and done the same. There was no problem with referencing but I cannot use classes from .NET Standard project. The code is red and Resharper keep telling me
"Reference XX ( .NET Standard ) and use XX "
This gives me no result and, when I add 'using' statement with the .NET Standard namespace the code is still red.
Do I need to download something?
Related
I need to reference a proprietary-client library that only works with .NET 4.8, there is no other option, this is a very narrow vendor library and we have to use it with .NET 48.
The new app that is being developed is a service application and will need to be maintained in the long term. And it's ok for this app to be installed on windows only. But we would like the application to benefit from .NET 6, while being able to use the .NET 4.8 client library.
So my question is : what would/could be a good solution that:
respects that I need some code in 4.8 to work with that library.
leverages .NET 6 and future enhancements
Thanks for your help!
Yes you can reference .NET 4.8 assembly from .NET 6. However, there are no guarantees it will work as expected. It will work only if it does not use any APIs which are not present in .NET 6 (or rather .NET Standard version supported by .NET 4.8), and if APIs it uses did not have breaking (for that application logic) changes.
You can easily test it by creating .NET 4.8 library with something like this:
public class Test
{
public static void OldNet()
{
Console.WriteLine("Hello from old .NET");
}
}
Then reference it from .NET 6 and call:
OldNet4.Test.OldNet();
Run and it will print "Hello from old .NET" no problem.
However if you for example use Thread.Abort in that old .NET 4.8 library - when running on .NET 6 it will not abort the target thread but instead will throw PlatformNotSupportedException, which is an example of breaking change. If it calls missing api, then it will throw TypeNotFound or similar exceptions.
So the end result depends on the library being referenced.
Yes, it is possible to have a client written in .NET Framework 4.8 and a server in .NET Core 6. It's possible to have a client and a server written in different programming languages as well, so there's no reason that your use case wouldn't be possible. However, it's not possible to reference a .NET Core assembly from a .NET Framework assembly.
Compiling a .NET Standard project gives me a dll. .NET Standard projects can also have dependencies, so the code is being compiled into something. How is this different than what is compiled when a .NET Framework or .NET Core project.
Am I just "extending" the implementation of .NET Standard when I create a class library?
Everything I've read compares .NET Standard to an interface and .NET Core/.NET Framework to implementations of some version of those interfaces.
My question is, if that is true, how can I create an actual .NET Standard library. and why can't I reference a .NET Standard library that is using any version of .NET Standard (ex: .NET Framework 4.5 should be able to use a .NET Standard 2.0 class library since it is clearly already being compiled)?
As far as I understood it, when you compile against .NET Standard, you are effectively compiling against mockups, i.e. assemblies that contain the public interface that is defined by .NET Standard but no implementation. At runtime, these mockups are replaced by assemblies that contain type forwards to the actual implementation. The replacement works because the mockups and these type forwarding assemblies have the same signature. However, these type forwarding assemblies do not exist for every version of the .NET Framework, actually only for the very recent versions.
According to Microsoft`s definition:
.NET Standard is a set of APIs that all .NET platforms have to
implement.
Note that, the .NET Standard is frozen. New APIs becomes available first in .NET Core or .NET Framework, and then after being review by a committee, the may be added in .NET Standard as well.
Personally according to the above definition if I wanna develop a general library that I will use it during a product development lifecycle then I would prefer to make it more framework independent by using .NET Standard.
More you can find here.
I'm working on migrating a large code base of libraries in a direction to eventually support .NET Core. Currently, everything is based on .NET Framework. I have a set of library projects which are consumed by several web applications.
The plan is to convert the library projects over to .NET Standard 2.0 so that they can be consumed by both .NET Framework (version 4.7.1) based websites and by new .NET Core (version 2.0) websites. I've done some test solutions which proved that this can be done.
To convert the first library over to .NET Standard I had to leverage the Windows Compatibility Pack for some of the features that are not part of .NET Standard. Some features such as SqlClient and some System.Drawing tools had to be imported into the library. All of this worked but an issue turned up when trying to bring my library into code which was still targeting .NET Framework.
Even though the namespaces were the same, the consuming code could not see the objects (such as Image or SqlConnection) unless I added the same Windows Compatibility Pack libraries into the consuming project. If anything, I would have expected this to cause issues as I now have two identical classes (same namespace and object name) in different assemblies. Fortunately, it is working. At least the unit tests are still passing.
Is this the way the Windows Compatibility Pack libraries are supposed to work? I had hoped that they would provide the functionality in the .NET Standard or .NET Core code but allow the .NET Framework to still use its own implementation.
The compatibility package references a few of the assemblies that were brought back to increase the compatibility of .NET Core with .NET Framework.
The way the package works is that there is a meta-package (the one that you reference) and it has references to individual packages that actually contain the implementation. Those individual packages have different assets depending on the target framework.
Take for example System.IO.Ports. That package contains the following assets (and a few more things that are not directly relevant to this):
net461
netstandard2.0
The netstandard2.0 asset contains the code that implements the System.IO.Ports functionality. You will use this if you are building a .NET Core application.
The net461 asset type-forwards the types exposed by the System.IO.Ports namespace to the assemblies you will find in the .NET Framework installation. You will use these if you are building a .NET Framework application (like a console application of web site).
This means that when you are consuming your library on .NET Core, you are using the implementation that was ported and made to work on .NET Core.
When you are using your library on .NET Framework you will use the implementation that is part of .NET Framework.
the referenced class in the object browser is shown as follows:
without the use of using RegexParse4Lib
visual studio 2012 intellesense suggested using
RegexParse4Lib.regexParse.RegexReplace(...
however, when completed it flagged RegexReplace as not exists. on the other hand
Regex.Replace(...
is accepted
Even more puzzling is that I can not add using RegexParse4Lib; despite intellisense allow me to put it in a class's beginning
This can happen if the project which is referencing the library is a Client Profile (this is a subset of .NET full version) and the library is a regular version (Not client profile).
This can also happen if the Target Framework of the project you are referencing is higher. If the library you are trying to reference has a lower framework version, then it should be fine because .NET Framework versions are backward compatible. However, if you are trying to reference a library which has a higher framework version then it will not work: It is possible the library has code taking advantage of new .net features which are not available in the older framework.
Change the project to have an equal or higher framework version than the library.
I've found a partial answer to my question in this thread:
Here on stackoverflow cannot change target framework...
In my case, the framework has successfully been converted to 4.5.2, and putting a method with async and await, that I'm sure are part of framework 4.5, the method is successfully run by an exe referencing the library. So I can presume that the library is really compiled using framework 4.5.2.
However, when referenced in any other project the library shows in its properties that it is compiled under framework 4.0. and when the debugger loads the assembly it prints out that it is compiled under framework 4.0...
So who is right? my code executing methods of framework 4.5 or the strings telling the library is on framework 4.0?
I've checked for what possible in my abilities if there are any .targets files in my installation, and yes there are two, under the msbuild-targets temporary folder, Microsoft.Common.targets and Microsoft.Csharp.targets, but I'm not able to understand if these files force the compiler to use framework 4.0.
Mainly because on this machine I compile directly in visual studio.
I have several solutions using component libraries compiled 4.5.2 that work correctly. So I don't really know how to be sure that my library is compiled under the right framework and that the library shows the right framework in its properties and when loaded.
If anyone has a clue on how to achieve this,
thank you in advance.
If your project properties say you're targeting .NET 4.5.2, then it's being built to work with .NET 4.5.2 and above versions.
Maybe you've a confusion with CLR and Framework versions. .NET 4.x (any) work with CLR (i.e. Common Language Runtime) 4.0.
Check .NET Framework Versions and Dependencies to get further details about this topic.