I found what appears to be a breaking change in the AWS SDK between .NET v4.8 and .NET v5.0 / .NETCore v3.1. Following the tutorial in an official blog, I found I could not compile/run the examples in .NET v5.0 or .NETCore v3.1 using the synchronous method SelectObjectContent. The AWS SDK API was clear this was a callable method, but my Visual Studio/Rider saw it was implemented as an internal method, so I couldn't cleanly access it. In fact, I couldn't even compile.
However, after exhaustive attempts, I realized moving back to .NET Framework v4.8 it worked as advertised, even using the same AWS SDK nuget (v3.7.0.21).
Is there a preferred way to access that function, or was a breaking change introduced accidentally that's not documented? I'm not sure how to differentiate whether this is a problem with .NET Framework or AWS SDK, so I'm unsure where to report it. The code is from AWS, but this is dependent on .NET Framework version.
The synchronous method is gone because it is intended to be this way for .NET/.NET Core projects and the respective SDK.
GitHub user normj who works for AWS stated in a thread:
The reason the .NET Core version only has async is because the underlying http client available in .NET Core only supports async operations. We debated about keeping the sync methods in the .NET Core version and have them just call the async versions and then block. The problem with that is the SDK would not be following best practice for the platform and more importantly it could mask a potential performance problem.
Thus the guide you followed isn't necessarily wrong but it could be a bit misleading - you just have to use whichever is available to you.
Also, despite using the same version of the AWSSDK, depending on what framework your project is targeting, it will reference a different DLL found in the lib folder of the package, which explains why for .NET Framework projects the method is available, but for .NET Core/.NET, it is not. The properties for the DLL in Solution Explorer in Visual Studio will also indicate this (note the Path property).
Related
I've seen a few conflicting answers about this topic so I'm hoping someone can lead to the right one. I'm building an API that uses devdept Eyeshot library. This library requires .net framework 4.8. I would like to use .NET 6 for my API because from what i can tell, Framework does not have great tools when it come to web development.
I've tried two different set-up's for my solution:
.NET 6 API with a .NET 6 class library where i tried to reference the relevant framework library.
.NET 6 API with framework 4.8 class library.
When I call the class i get the error -"Could not load type 'System.Runtime.Remoting.RemotingServices' from assembly 'mscorlib, Version=4.0.0.0'". But when i run it from a framework 4.8 API it works.
So is there and why at all to get this working with a .NET 6 API, no matter how complicated or does the API have to target the same framework?
You are out of luck unless there is an updated version. The remoting services it depend upon has been removed in the .Net core & .Net 5+. So the library will fail to load, at least if the jitter ever reaches any method that uses one of the removed APIs.
If this is a first party or open source library you might consider updating to .Net 5+, and replace the remoting service with some newer IPC technology. If it is third party commercial library you might politely ask them to update their library, it should be in their own interest since most libraries already have transitioned to .net 5+.
If that is not an option, a possible workaround is to run the library in a separate process, and use your favorite IPC/RPC method to communicate with this processes.
In addition to the other answer (I was just going to post something similar), do note that when you reference a .NET Framework library from a .NET 6.0 app, the entire code will run in the .NET 6.0 runtime. There's no second execution environment created, therefore the .NET Framework library actually executes against the .NET 6.0 runtime library and fails if it requires features that no longer exists there. Many older libraries work fine that way, since the runtime is mostly backwards compatible, with some notable exceptions. 'System.Runtime.Remoting.RemotingServices is one of them.
I am tasked with upgrading a somewhat complex C# project from .NET 4.8 to .NET 5. The Windows upgrade assistant went more or less smoothly, and with some cleanup, it looks good, Except for one dependency, which is sadly absolutely not replaceable (within the scope of the job).
So my solution to this would be: Move all the code that interfaces with this dependency to a sub-project which builds for .NET 5 as well as .NET 4.8 (at least in the csproj file), and use that as depencency. Does this actually work?
Visual Studio says that's ok, but I have found absolutely nothing on the topic (and while I believe it could work, it's probably just me wanting that it does).
[Regarding the problem that the result will be an absolute mess: the functionality of this dependency will be obsolete within a year, at which point the sub-project will be removed anyway, sadly the ugrade cannot just wait until then]
can I build a project in .net4.8 and include it in a project building for net5
Maybe? The basic rule is that .Net 5 cannot use .Net 4.x libraries. There may be some exceptions to this rule, but I cannot find a reference to confirm this. And I'm fairly sure it can result in runtime failures if the library tries to use methods not available in .Net 5.
The recommended way would be to port the library to .Net standard 2.0, that way you can use it in both .Net 4.8 and .Net 5 projects without issue. This should be fairly straight forward to port unless you are using UI or other libraries not available in .net standard.
It might be possible to use multi-targeting, i.e. write in your project file that the project should be compiled for both .Net 5 and .Net 4.8. You could use pragmas, (i.e. #if NET48) to include or exclude code sections from either framework. I have not used this feature so I cannot provide much details.
Whenever I'm creating a new solution with VS2017 I'm usually choosing one of the newer Frameworks as a target (most often currently 4.6.1).
Now though when I create a .dll Subproject within the solution it sets the target Framework for that subproject to .NET Standard 2.0. With that being the most "modern" target Framework that can be set.
This though has the Problem that I can't use some things I'm used to like "Resources.MyResource" (which works fine with Framework 4.6.1).
Now I'm wondering is there any way to rectify this Problem? Either by increasing the .NET Standard, or by enabling one to choose the .NET Framework also for These .dll Projects (aside from creating the .DLL Project outside the solution and then importing it into the solution)?
.Net Standard is a specification of the .NET API's that are available on all implementations of .NET.
What does this mean? - Calling an API in .Net Standard will run on all .Net versions that have implemented that version of the Standard.
SO what does that mean? - .Net Core introduces cross platform development. The need to now possibly share code between a Windows machine and a Linux box require a "standard" that can be implemented across all equally.
Think of it as a contract. If a version of .Net implements .Net Standard 2.0, it is saying that it will have a version of the API's in that standard available for use on all platforms.
So, back to your original question. .Net Standard 2.0 is not a "new" version of the framework. It is the contract that your subproject, assuming it's a class library is going to abide by. If an API appears to be missing it is because it doesn't have it as part of it's contract (maybe). I say maybe because it's not the easiest to find.
**** Start Revised ****
Here is a table of the versions of .Net that support the versions of .Net Standard.
In your case 4.6.1 doesn't even support 2.0. The last version of the Standard that 4.6.1 supported is 1.4.
I thought 4.6.1 supported .Net standard 2.0 after I wrote the above and upon further reading found a more up to date chart along with this post stating it is supported in 4.6.1. sigh
**** End Revised ****
This SO answer seems to indicate that 1.4 does have Resources in it but it was preview versions and things change. I don't see it in the APIs supported list but I could have missed it. The SO answer seems to indicate it was a tooling issue and could be worked around. That could be fixed by now....
Here's where you can look to see what each Standard supports for APIs.
HOWEVER, I don't think this is actually what you want.
I think what you really want is to simply change your sub project's target to 4.6.1 as is your main app since I highly suspect you have no need/desire to run cross platform.
Additionally, prior to .Net Standard 2.0, thousands of API's were not in the Standard. IMO, prior to 2.0, the Standard is a hard sell especially for users on the .Net Full Framework.
From what I can tell the Project Template to use is under "Windows Classic Desktop > Class Library (.Net Framework)"
EDIT
That said, you can add a .resx file to a .Net Standard project and use it in exactly the same way.
Last few months I create console applications with .NET framework and C#.
Now I want to create ASP.NET Core MVC projects, but I cannot choose any .NET Core template.
If I click "Console App (.NET Core)" or "ASP.NET Core Web Application" or any other .NET Core template, I can see this error message:
So, the problem occurs if I choose "Core", other templates work fine.
I have already tried to find a solution on Google.
What could be the problem? I reinstalled VS few times but did not help.
.NET Core does not support COM. COM is a Windows-only thing, and everything in Core is cross-platform. You must run on the full framework if you need to utilize a COM library.
That said, Microsoft has recently release a preview NuGet with some Windows compatibility APIs. This may allow you to utilize COM; I haven't tried it. However, the stated purpose of the NuGet is to make it easier to migrate existing .NET Framework applications to .NET Standard/.NET Core, so it's not considered something you would continue to utilize long-term. Rather, the idea is that you would actively work to migrate code that is not compatible to equivalent .NET Standard/.NET Core APIs, and then eventually remove the package entirely. As a result, it's probably not a good idea to go this route, even if it does enable you to use the COM library, simply because you're not likely to be able to stop at some point in the future.
Long and short, just run on the full framework.
If the C# frontend team on my project makes a standalone program that only does .NET 2.0 API calls, but install on to a computer with .NET 4.0, will it work by default or must they do something to the setup or to the setup-building process (like check off certain checkboxes) to make it work?
See, I'm assuming that if I make .NET 2.0 API calls only, that it should just "work" on .NET 4.0.
Part 2 on this is -- user has .NET 4.0 and .NET 1.1, but not .NET 2.0. I assume .NET 2.0 should work, then, because it has .NET 4.0. Right?
Background -- I'm a Linux/PHP dev and haven't touched C# since 2001. My skills are stale. The client's C# frontend team on my project need some assistance on understanding compatibilities, I guess, and so I've been asked by my client to ask this question.
.NET 2.0 should work if you have .NET 4.0 installed on your computer. I got this from this link: Version Compatibility in the .NET Framework. Keep in mind though, that some objects have changed from 2.0 and 4.0. They might not have all the same properties and methods. It is always a good thing to refer to the MSDN documentation.
Edit new link: Another good reference about the element in the web.config/app.config file of your project: supportedRuntime