I have 2 simple projects one is in DotNet Core(lets say CoreProject) and the other one is in .net 4.5.2 (let's say OldCode). I was able to reference the projects but when I call the OldCode from the CoreProject I encounter the following error:
System.IO.FileNotFoundException occurred
HResult=0x80070002
Message=Could not load file or assembly 'System.Configuration, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
The system cannot find the file specified.
I have tried to add System.Configuration to the project but I don't know exactly to which file I should add it. I do not have project.json. Only config files that I have are: launchSettings.json and appsettings.json. I add System.Configuration with nuGet because it's an older version.
Where I should put the reference so when I run the command dotnet restore to add the dependency to System.Configuration?
At the moment, the .NET family looks something like this:
(Image is from .NET Core, .NET Framework, Xamarin – The “WHAT and WHEN to use it”)
When you create a project targeting one of the frameworks at the top (e.g. .NET Core), you can't use that project against other frameworks (e.g. .NET Framework). System.Configuration is an asset that specifically targets .NET Framework, and it doesn't exist in .NET Core.
On the other hand, you can write code that is compatible with all the frameworks (within limits - see compatibility chart to see how the versions map) by targeting .NET Standard, if your dependencies in turn target .NET Standard. This doesn't apply to System.Configuration, because that's .NET Framework-specific and does not target .NET Standard.
As an alternative, you can use the .NET Core Configuration Model (which, despite the name I'm using, actually targets .NET Standard and thus can be used in any framework). Or else you can use my very own .NET Settings Framework which is an abstraction that works with both the mature System.Configurationmodel (.NET Framework only) and the .NET Core configuration model (.NET Standard).
Related
Assuming that you are using <Project Sdk="Microsoft.NET.Sdk">in your .csproj file, the documentation says that you should reference the ASP.NET Core framework through a shared framework reference like so:
<FrameworkReference Include="Microsoft.AspNetCore.App" />
The.csproj file will also contain a target framework reference. For example, netcoreapp3.1 is specified using the following target framework moniker:
<TargetFramework>netcoreapp3.1</TargetFramework>
What isn't clear to me is how the specific version of ASP.NET Core is selected. I understand that the .NET runtime version selection process is documented here but I don't understand how the ASP.NET Core web framework version is selected. For example, what if I wanted to experiment with different features between two versions of ASP.NET Core that targeted the same version of .NET Core or .NET? How would that be distinguished?
When you target netcoreapp3.1 and you have multiple 3.1.x installed (e.g., you have 3.1.15, 3.1.20 and 3.1.28 installed), the latest version 3.1.28 will be used. Currently no known way to tell the .csproj to pick up a specific version (correct me if any).
For your question
what if I wanted to experiment with different features between two
versions of ASP.NET Core that targeted the same version of .NET Core
or .NET?
the only way I can think of is that you need to have couple build boxes installed with different point releases so that you can try for example 3.1.20 and 3.1.28.
I'm in the process of converting an Asp.Net Core 2.2 Website that targeted the Full Framework to an Asp.Net Core 3.1 App that targets .Net Core 3.1. I'm a bit unclear about dependencies related to System.Drawing and how to fulfill them.
My project uses System.Drawing and when compiling under Asp.Net Core 3.1 I get this error that suggests that I add a reference to System.Drawing.Common.dll :
Error CS1069: The type name 'Image' could not be found in the namespace 'System.Drawing'. This type has been forwarded to assembly 'System.Drawing.Common, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' Consider adding a reference to that assembly. 1-wwwGiftOasis3 C:\Users\Ron\source\repos\wwwGiftOasis3\wwwGiftOasis3\site\seller\profile\about\s-photos.cs
In Visual Studio I don't see a way to add a reference directly to the bare System.Drawing.Common.dll so I assume that I should add the reference via NuGet.
In NuGet I see a System.Drawing.Common package which looks like what I want but it's unclear to me whether my project fulfills the dependencies:
My Project shows these dependencies:
So I have a couple questions related to all this:
1) Does the fact my the project depends on Framework Microsoft.NETCore.App fulfill the NuGet package's Microsoft.NETCore.Platforms dependency?
2) Does the fact that I intend to only run this Asp.Net Core 3.1 website on windows fulfill the NuGet package's Microsoft.Win32.SystemEvents dependency?
System.Drawing utilizes Windows-specific APIs, and as such, is incompatible with .NET Core, which is cross-platform. Microsoft created System.Drawing.Common as an in-place replacement for System.Drawing for .NET Core. It is an exact API replacement, but performs the image operations in a cross-platform, rather than Windows-specific, way.
Long and short, yes, you just drop the NuGet into your project and go to town. There's nothing else you need to worry about.
I'm building a Web API in .NET Core 2. I'm using some custom nuget packages to leverage their built in functionality. These custom packages were built against an older .NET version (4.6.1). The problem is some of these packages have references to the old System.Web dll. I'm getting this warning on some of the custom packages in the solution
package was restored using '.net framework version=v4.6.1 instead of using the proj target framework.
The app is also throwing this exception below when I call code in one of the custom packages
System.IO.FileNotFoundException: Could not load file or assembly System.Web.ApplicationServices, Version=4.0.0.0, Culture=neutral,The system cannot find the file specified
Is there any way around this other than re-writing the code in my web Api?
No. System.Web is completely incompatible with Core. While Microsoft opened up NuGet packages that target .NET Framework to be utilized in with .NET Core, it did so based only on .NET Standard 2.0 compatibility, and makes no assurances that the packages will function in part or whole. You'll actually get a warning during compile telling you as much. Also, while you can actually have something like an ASP.NET Core app actually target .NET Framework, again, compatibility of third-party components is not guaranteed, simply because they target the same framework.
Long and short, if there's any dependency on System.Web at all, you can't use it.
I have a .NET Framework Console app (.Net Framework 4.7) which references a .NET Core dll (.Net Standard 2.0). The .Net core dll uses nothing outside NETStandard.Library.
I noticed some unexpected files in the /bin/Debug directory. After some investigation I have determined that these are not coming from any of the referenced packages, but are being copied from
C:\Program Files (x86)\Microsoft Visual Studio\Preview\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\\net461\ref
The contents of this directory differ across the machines we are using, causing different DLLs to end up in the output directory. This was making the debugging process inconsistent.
Now that I have worked out what was causing the problem, I was wondering what the explanation of this is, and whether there is a way to prevent it from happening, ie to have only the packages referenced in the project be copied to /bin/Debug
These files are expected and even required to allow .NET Standard libraries to work on .NET Framework. They contain the necessary type forwarding definitions so that at runtime, every assembly can be loaded correctly - for example, libraries can reference System.Object from netstandard.dll (.NET Standard >= 2.0) or System.Runtime.dll (.NET Standard < 2.0). The additional assemblies in your output file will redirect the type to .NET Framework's mscorlib.dll.
There is this GitHub issue answering a similar question.
Note that the upcoming .NET Framework 4.7.1 will have the all the required type definitions and forwards out of the box so once a project targets 4.7.1, no additional assemblies will be added to your project's output folder.
I wanted to create a new ASP.NET Core app targeting the new .NET Core 1.0.
First, in Visual Studio 2015 Update 3, I don't see .NET Core listed
And this is what I'm seeing in project.json file. Looks like I'm targeing dotnet5.6
Is it safe to assume this is all correct?
And if this is correct, could it possibly be more confusing?
The pulldown has no meaning for .NET Core projects as it doesn't use it. Only what's in project.json matters for .NET Core / .xproj projects.
netcoreapp1.0 target framework moniker (short TFM) is .NET Core project for executables (ASP.NET Web Application or .NET Core Console Application). netstandard1.x (see this matrix for api surface of netstandard TFM) is for class libraries.
The import section just tells nuget to also restore packages which target dotnet5.6 (old TFM for .NET Core Library, which is now replaced with netstandard1.x) and portable-net45-win8, which are also compatible with .NET Core. These allow you to install packages which are compatible but are not yet repackaged for netstandard1.x.