Recently I started learning how to create Dynamic Link Libraries in Visual Studio with C#.
I followed online instructions on how to create DLLs:
https://learn.microsoft.com/en-us/dotnet/core/tutorials/library-with-visual-studio
http://www.c-sharpcorner.com/UploadFile/1e050f/creating-and-using-dll-class-library-in-C-Sharp/
https://blogs.msdn.microsoft.com/benjaminperkins/2017/04/13/how-to-make-a-simple-dll-as-an-assembly-reference-just-for-fun/
After completing these steps, I tried to add my .dll file to my projects.
On execution I receive this message:
System.IO.FileNotFoundException: 'Could not load file or assembly
'MySql.Connect, Version=1.0.0.2, Culture=neutral, PublicKeyToken=null'. The
system cannot find the file specified.'
I selected .NET Framework 4.6.1 when I started my project. The target framework in the Properties file under the Application tab is selected as .NET Framework 2.0.
The project that should reference to the file is targeting the .Net Core 2 Framework.
I've been at this problem for nearly a week and searched for online solutions.
Any help will be greatly appreciated.
You need to put the DLL somewhere that the runtime can find it. The easiest thing to do would be to put it in the same directory as the .exe, but you have other options as well (see How the Runtime Locates Assemblies).
It is important to carefully decide what platform you intend to use your DLL with.
I selected.NET Framework 4.6.1 when I started my project.
If you mean when you started your DLL project, then you have limited the types of applications that can consume this DLL to .NET Framework 4.6.1+.
Properties file under the Application tab is selected as .Net Framework 2.0.
If I understand correctly, you changed the DLL target from .NET Framework 4.6.1 to .NET Framework 2.0. This widens the compatibility so that the consuming library can be .NET Framework 2.0+. However, this is at the expense of all of the newer features of the .NET Framework.
Do note that official support (i.e. patches) for .NET Framework 2.0 has been gone for several years, and newer machines aren't likely to have it installed.
The project that should reference to the file is targeting the .Net Core 2 Framework.
Here's the crux of your issue. .NET Core ain't .NET Framework. It is a completely different platform.
That said, .NET Core has some limited support for referencing .NET Framework assemblies, but is it sure not to work with .NET Framework 2.0 (which again, hasn't been supported in years). Also, this "compatibility mode" probably means you lose cross-OS support, which is one of the main benefits of .NET Core.
Option 1
So, the knee jerk answer is to make your DLL target .NET Core if you want to use it with .NET Core applications.
Option 2
However, there is also an option to make a portable DLL that works with .NET Framework 4.5+ and .NET Core - make your DLL target .NET Standard.
See How to port from .net framework to .net standard for instructions on changing your DLL to target .NET Standard.
Related
The question is stupid enough, but it didn’t work with NuGet before. After installing the NuGet package through the console, to connect to PostgreSQL, files appeared that NetFramework should contain. Without copying these files, the project does not start. What to do to get rid of them and not copy them to the directory with the program. In my understanding, these files should be taken from the framework.
See screenshots:
All need files in project C#
My guess is that you have .Net Standard 2.0 libraries/dependencies in your project.
.NET 4.6.1 might add additional runtime dependencies in your output folder:
.NET 4.6.1, 4.6.2, .NET 4.7 and 4.7.1 all have partial .NET Standard
2.0 support in the natively shipped runtimes, but they still are .NET Standard 2.0 compliant by adding additional runtime dependencies into
your output folder to provide the missing functionality. NuGet along
with the runtime targeting handles automatically adding those
dependencies to your projects to provide the needed runtime support
for those extra features. A lot of those assemblies override behavior
from the base framework and .NET uses runtime redirects to route api
calls to the appropriate assemblies rather than than mscorlib.dll or
other system assemblies.
.NET 4.7.2 is the first version of the full .NET Framework that is
fully .NET Standard 2.0 compliant without any additional dependencies.
See: https://weblog.west-wind.com/posts/2019/Feb/19/Using-NET-Standard-with-Full-Framework-NET
In other words, targeting .NET 4.7.2 should get rid of the additional files.
We have some legacy projects, written with .Net Framework which should be used by an API project which is written by ASP.NET Core3.1.
The problem is that these legacy projects are using 'System.Web.HttpContext' that you know does not exist in .net core anymore.
Now we are receiving this error:
'Could not load type 'System.Web.HttpContext' from assembly 'System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.'
Have you faced this problem before? Can anyone help please?
.NET Framework libraries are not technically compatible with .NET Core. .NET Standard libraries are, and since both .NET Framework and .NET Core implement .NET Standard, Microsoft made a special exemption in the compiler to allow .NET Framework libraries to be referenced by projects that target .NET Core, with the caveat that they may not actually work. You get a warning to this effect when you reference a .NET Framework library from a .NET Core project.
The .NET Framework library will work as long as it only uses APIs compatible with .NET Standard 2.0. System.Web.HttpContext is not one such API, so it will not work in a .NET Core project. Period. Nothing you can do about that.
You can attempt to multi-target your libraries and sub-in .NET Core compatible APIs using compiler directives. That'll work, but gets messy quick. Otherwise, you'll just have to write new versions of the libraries for ASP.NET Core, since presumably you're trying to maintain support in the current libraries for ASP.NET.
im building an app using c# (not my first. other projects i dont have this problem). this one i included nuget package json
the problem that VS generates too many .dll files in my bin/debug folder (with exe). i don't want these dll files but it seems like the exe doesn't run without them (i coppied the exe to another path and run it)
when i search on the internet all the details about merging using some merge tool but my problem is related VisualStudio in the setting i believe?
This happens when you include a library which targets .NET Standard 1.5 or higher, from a project which targets .NET Framework 4.7.1 or lower.
The .NET Platform Standard table hints at this: it claims that .NET Framework 4.6.1 supports .NET Standard 1.5 or higher, but there's a footnote:
The versions listed here represent the rules that NuGet uses to determine whether a given .NET Standard library is applicable. While NuGet considers .NET Framework 4.6.1 as supporting .NET Standard 1.5 through 2.0, there are several issues with consuming .NET Standard libraries that were built for those versions from .NET Framework 4.6.1 projects. For .NET Framework projects that need to use such libraries, we recommend that you upgrade the project to target .NET Framework 4.7.2 or higher.
One of these issues is that you'll get a lot of extra DLLs, apparently because .NET Framework 4.6.1 only has partial support for .NET Standard 1.5.
The solution is for your project to target .NET Framework 4.7.2, or .NET Core.
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.
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