.NET Core compatibility change list #17307
Comments
|
And make it discoverable by posting it here:
|
|
You can also name it “.NET Core Master Change List (MCL)” or something similar so it's easy to remember and to emphasis that changes are happening in certain areas. |
|
@leecow will you be able to handle this issue soon? it is marked as v2.0 and we are getting closer to the deadline. please let's know when you are going to get this done. Thanks. |
|
We already have a file which lists all ApiCompat changes from netfx461 to netcoreapp. https://github.com/dotnet/corefx/blob/master/src/shims/ApiCompatBaseline.netcoreapp.netfx461.ignore.txt @karelz @danmosemsft How should we proceed with that issue? Should we create a doc which is a readable wrapper of the file i mentioned above? I could do that as I already have a draft: https://github.com/dotnet/corefx/issues/15255#issuecomment-291137517 |
|
On top of that we have high-level doc about by-design missing technologies in .NET Core: https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/porting.md We will also have tooling for platform-compat, so I guess we are overall good. Closing. |
Strongly disagree. Don't see how this can be useful to humans. Looks like a data dump of static code analysis error messages.
IMHO, this is a bad document for various reasons which I wont go into... There needs to be a simple representation of the differences in terms of namespaces / technology so developers can see up-front what's involved in porting to .NET Core, which feature areas are lacking what changed and what's new (including appropriate references to either doc's or github issues) - all in one document. |
|
@clrjunkie thanks for the feedback
Do you want give it a try submitting PR for a doc bases on the information in the link https://github.com/dotnet/corefx/blob/master/src/shims/ApiCompatBaseline.netcoreapp.netfx461.ignore.txt and be more user readable?
Your feedback can be valuable here if you send more details.
I don't think having everything in one doc will be good here. we can have one parent doc laying out the porting (as we already do but we are waiting your feedback) and we can have this doc have links to specific compat doc for specific versions. note that currently we are talking about 4.6.1 but I expect in the future we'll have docs for other versions as we go. does it make sense to you? @karelz I am re-opening this issue again and moving it to the future as we need to do more on that but we already have enough info so far for v2.0 release. let me know if you have different idea. CC @terrajobst @danmosemsft |
|
Note that the platform-compat tooling I mentioned above will contain superset of the detailed ApiCompat list. It will be stored in some kind csv database. It should be trivial to turn it into HTML as well for easier readability. The high-level changes should be described in porting doc. If something is missing, or incomplete, let's work on that. We will need more detailed feedback as @tarekgh said above. I strongly believe that these 2 approaches cover the most important needs. If not, we will need more details / ideas / example PR / etc. - let's stay constructive. |
|
Since you asked: https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/porting.md
Is it there or not?
Problematic architecture for who? What's the problem? If Invested man years in developing around this do I have problem? Do you have an RPC alternative? Are you suggesting RPC is dead when every other framework has one?
Comfortable?? If I'm on full .NET FW reading this document, do I need to feel uncomfortable also?
What does that mean? What does the object-oriented programing paradigm have to do with this? Focus on the differences, leave out unnecessary claims. Feature owners should document critical differences between API's as I initially suggested at the beginning of this issue. This information is not something that can be derived from an automated reflection process but requires intimate knowledge and expertise of the API problem domain. |
It is there at the level of the classes and CLR/JIT. However, when code is compiled to native/C++ using the .NET Native pipeline AppDomains are not supported. Can you use them? Technically yes, however not supported in all cases (so bad for library authors), not in UWP, and don't ask for help if it doesn't work.
Less unnecessary and more not clear really. What they're talking about is that CAS and the like work as long as you play nice. Start using Reflection, Dynamic Code, Emit, or just mess with the raw memory and it does nothing. |
What do you mean? AppDomains API surface is somewhat present, but it is mostly no-op. AppDomains concept does not exist in CoreCLR and won't come back in future.
The architecture itself is problematic. Implementing something like that comes with lots of baggage. If you truly need it, you should stay on Desktop. Bringing it to CoreCLR would be many man-years initial cost plus huge tax and ongoing cost. For little value as only a few customers use and even they can typically replace it with other technologies.
Here are some details. I will include them in the article, good feedback about missing context.
Just got updated text from experts on CAS. Will update it shortly.
This particular doc also explains background and motivation on purpose -- many customers and developers want that. For pure list of differences, you can wait for the tooling and its HTML form I mentioned above.
Agreed, in the form of the tool mentioned above, which will tell you what is different. It is on our backlog to create that information post-ZBB. |
Motivated by issue #8598. CAS & Transparency info provided by @morganbr AppDomains consulted with @weshaggard
|
Documentation updated. The work for per-API differences is tracked in dotnet/corefx#18405. Do we need to track anything else or can we close this issue? |
|
Thanks for valuable feedback to make our docs better @clrjunkie! |
|
Your welcome @karelz
I suggest you remove the reference to "sockets" as an "alternative" to an "RPC framework" in the document. It's a bit more complicated than making a "sample" ... :) (Both .NET Remoting and WCF are written on top of sockets..) |
|
If we remove Sockets, then there is no alternative left. That doesn't sound like a good option to me ... BTW: .NET Remoting in Desktop is not built on top of |
|
No no ... an RPC framework is a completly different and higher level of abstraction than the sockets API... suggesting that sockets is an alternative to RPC is like suggesting that a bare bone engine is an alternative to a car ... All the components you mentioned are written over the Sockets API including those Native "OS libraries" (FYI System.net.sockets is simply a managed wrapper for the O/S Socket API) |
Correct, our replacement for the 'weird car' (.NET Remoting) is the car engine (IPC / |
|
The last loose end - discussion about alternatives/replacements of .NET Remoting is now tracked in dotnet/corefx#18394. |
|
The wording is simple: There is currently no RPC support in .NET Core Suggesting sockets as alternative is simply way out of context |
@karelz is not suggesting sockets as an alternative but building your own thing based on Sockets.
|
Different wording, same problem. For all intents and purposes "building your own thing based on sockets" as an "alternative" to an RPC framework is not an alternative. Same as saying we don't provide a web server but you have sockets so your "alternative" is building your own web server... By this logic "building your own thing based on sockets" is an "alternative" to any communication facility that's not part of .NET Core, which IMHO is ridiculous. |
Motivated by issue #8598. CAS & Transparency info provided by @morganbr AppDomains consulted with @weshaggard
|
@clrjunkie don't forget that there are users of .NET Remoting who are using only subset of features, maybe used copy-pasted code from StackOverflow just to communicate between 2 machines easily. For those, Sockets might be a reasonable replacement. I think it is fair to state that Sockets are good replacement for cross-machine communication and basic RPC. It is not a good replacement for very involved RPC - for that, we have some 3rd party suggestions tracked in https://github.com/dotnet/corefx/issues/18394#issuecomment-294257909, feel free to suggest more alternatives there. |
|
@karelz It’s not a matter of black and white but rather not making sweeping claims. .NET Remoting is first and foremost an RPC technology ".NET remoting enables you to build widely distributed applications easily, whether application components are all on one computer or spread out across the entire world." https://msdn.microsoft.com/en-us/library/kwdt6w2k(v=vs.71).aspx There is proxy, method call forwarding, object lifetime management, books... Telling customers to build their own thing on top of sockets as an “alternative” to .NET Remoting strongly suggests misunderstanding of the effort involved. As for “problematic architecture” I personally worked on a distributed system sold for hundreds of the thousands of dollars using .NET Remoting for communicating between client and server and there was no problem in that area. (Quite frankly, my problems started with its successor WCF and its church of followers). Sure, .NET Remoting has it's limitations like a proprietary protocol and today there are more efficient serialization methods (which you are probably considering), but point being there was no problem back then and there is no problem today. I can assume some users may have used this technology for simple inter-process communication to avoid the complexity of stream handling (e.g Sockets/Pipes) So to address this type of scenario it may be appropriate to suggest sockets but you need to stay specific on the scenario you are suggesting an alternative to. |
Motivated by issue #8598. CAS & Transparency info provided by @morganbr AppDomains consulted with @weshaggard
ghost
locked as resolved and limited conversation to collaborators
Provide a table highlighting all major changes in technology (api, specification etc.) between .NET Framework and .NET Core.
Something like:
The text was updated successfully, but these errors were encountered: