5 ms·

But presumably only the Core 3.0 WCF/Winforms "most things work, but in all likelihood your million+ line of code app will have all sorts of little things that

But presumably only the Core 3.0 WCF/Winforms "most things work, but in all likelihood your million+ line of code app will have all sorts of little things that won't work". Presumably if you are using any of the following heavily in your applications, you will never be able to run on .NET 5 without major porting effort (I.E. reworking everything to avoid these): * Remoting * C++/CLI or Managed-C++ * App domains * code access security * ASP.Net Web Forms * Exposing registered COM interfaces from .NET code for access from Win32 code. * WCF Servers (Technically, nothing prevents somebody from porting this, since WCF is basically pure managed code, and its tricky Proxy related code is already ported as part of the client code. It is just that Microsoft has no plans to bother with this.) Will SQL Server upgrade its .NET support for .net 5? (Potentially breaking compatibility with certain currently supported use cases)? I'm guessing IIS Managed modules will never upgrade beyond .NET 4.X.

wvenable 7y ago
It's not like they have to re-implement all the code for these things; the majority of this code can just be moved over as-is from .Net framework to .Net core on Windows with minimal modification. I'd be surprised if the goal isn't 100% compatibility. If Microsoft can get Linux applications to run on Windows, they can probably get .Net applications to run on .Net.
- jsmith45 7y ago
  Remoting/app domains/Code access security were ripped out of the .NET Core codebase, and there is really not much of a chance of them returning. The CoreFX codebase has systematically removed all the code needed for things to safely work with those features, and re-implementing them would be unfeasible. As for webforms. Well, the whole hosting model for IIS worker processes was based on appdomains. Further, w3wp.exe has special code for loading and integrating with the Framework, enabling managed modules. This is the whole System.Web.dll concept. Microsoft really does not seem to want to put in much effort to fix that. Since Microsoft always recomended hosting WCF services in IIS, which therefore relied on the whole System.Web.dll mess which I think is a large part of the reason thy don't want to port that. That said, other than replacing XML configuration, self-hosted WCF services should be pretty easy for them to port.
  - merb 7y ago
    app domains basically now have a better alternative with Application Parts or for the heavy lifting AssemblyLoadContext (https://docs.microsoft.com/de-de/dotnet/core/tutorials/creating-app-with-plugin-support https://docs.microsoft.com/de-de/dotnet/core/tutorials/creat...)
    - jsmith45 7y ago
      AssemblyLoadContext with assembly unloading is not at all compatible with .NET Framework 4.X, which can be a pain if you want to gradually migrate stuff. Also it does not have anywhere near the same level of isolation, which is part of what System.Web.dll was using them for. Would it be possible to it in a system.Web.dll port? Certainly, but you would be changing the semantics enough that some applications would notice the difference, and probably not in a good way.
      - merb 7y ago
        yeah I mean unloading is not even that good without a .net core 3.0 preview. I think that in 5-10 years new stuff will emerge based on AssemblyLoadContext, maybe even some kind of OSGi just a little bit easier. Some examples are really promising and AssemblyLoadContext does not have the same problems as Java solutions. (duplicate Class Files, etc...) the only thing that is missing is some kind of security related stuff.
  - wvenable 7y ago
    > As for webforms. Well, the whole hosting model for IIS worker processes was based on appdomains. But I wonder if you could just stub that out with a mock AppDomain object in C# to keep the API the same. Is there actually anything that's truly dependent on it being an actual "AppDomain"?
scarface74 7y ago
I would think that COM as an escape hatch for interoperability would survive the heat death of the universe. Shouldn’t it be possible to wrap a Windows .Net Core app with a COM interface and register that for use in an old Framework app or vice versa?
- pjmlp 7y ago
  COM has been the future of Windows APIs since Vista. Every Windows API that isn't exposed to .NET since Vista, does require COM interoperability.
  - scarface74 7y ago
    Not really. You don’t use COM to access Windows API’s. P/Invoke is a completely separate method than COM. https://stackoverflow.com/questions/3138003/what-is-the-difference-between-pinvoke-and-com-interop https://stackoverflow.com/questions/3138003/what-is-the-diff... COM and C interop have always been separate and COM has been around since 1993. In fact, the native Win32 APIs use C style null terminated byte or double byte character arrays for strings. COM uses BSTR types - double byte arrays where the first two bytes are the length.
    - pjmlp 7y ago
      I see you haven't done much WinRT/UWP.
      - scarface74 7y ago
        You said that: Every Windows API that isn't exposed to .NET since Vista, does require COM interoperability You did not say “if you are using WinRT/UWP”. Also you said “since Vista”. WinRT was released with Windows 8, UWP was released with Windows 10. Also P/invoke is supported in WinRT https://stackoverflow.com/questions/8881335/pinvoke-in-metro-apps-with-windows-8-winrt https://stackoverflow.com/questions/8881335/pinvoke-in-metro... So no, you are not required to use COM for Windows API even with WinRT.
GordonS 7y ago
> C++/CLI or Managed-C++ Work is ongoing on this for .NET Core, or at least it was very recently. I certainly hope it will make it into .NET 5. App domains were never used beyond a few edge cases. For most of your other examples, I haven't personally used then for at least 5+ years.

wvenable 7y ago

It's not like they have to re-implement all the code for these things; the majority of this code can just be moved over as-is from .Net framework to .Net core on Windows with minimal modification. I'd be surprised if the goal isn't 100% compatibility. If Microsoft can get Linux applications to run on Windows, they can probably get .Net applications to run on .Net.

jsmith45 7y ago
Remoting/app domains/Code access security were ripped out of the .NET Core codebase, and there is really not much of a chance of them returning. The CoreFX codebase has systematically removed all the code needed for things to safely work with those features, and re-implementing them would be unfeasible. As for webforms. Well, the whole hosting model for IIS worker processes was based on appdomains. Further, w3wp.exe has special code for loading and integrating with the Framework, enabling managed modules. This is the whole System.Web.dll concept. Microsoft really does not seem to want to put in much effort to fix that. Since Microsoft always recomended hosting WCF services in IIS, which therefore relied on the whole System.Web.dll mess which I think is a large part of the reason thy don't want to port that. That said, other than replacing XML configuration, self-hosted WCF services should be pretty easy for them to port.
- merb 7y ago
  app domains basically now have a better alternative with Application Parts or for the heavy lifting AssemblyLoadContext (https://docs.microsoft.com/de-de/dotnet/core/tutorials/creating-app-with-plugin-support https://docs.microsoft.com/de-de/dotnet/core/tutorials/creat...)
  - jsmith45 7y ago
    AssemblyLoadContext with assembly unloading is not at all compatible with .NET Framework 4.X, which can be a pain if you want to gradually migrate stuff. Also it does not have anywhere near the same level of isolation, which is part of what System.Web.dll was using them for. Would it be possible to it in a system.Web.dll port? Certainly, but you would be changing the semantics enough that some applications would notice the difference, and probably not in a good way.
    - merb 7y ago
      yeah I mean unloading is not even that good without a .net core 3.0 preview. I think that in 5-10 years new stuff will emerge based on AssemblyLoadContext, maybe even some kind of OSGi just a little bit easier. Some examples are really promising and AssemblyLoadContext does not have the same problems as Java solutions. (duplicate Class Files, etc...) the only thing that is missing is some kind of security related stuff.
- wvenable 7y ago
  > As for webforms. Well, the whole hosting model for IIS worker processes was based on appdomains. But I wonder if you could just stub that out with a mock AppDomain object in C# to keep the API the same. Is there actually anything that's truly dependent on it being an actual "AppDomain"?

scarface74 7y ago

I would think that COM as an escape hatch for interoperability would survive the heat death of the universe. Shouldn’t it be possible to wrap a Windows .Net Core app with a COM interface and register that for use in an old Framework app or vice versa?

pjmlp 7y ago
COM has been the future of Windows APIs since Vista. Every Windows API that isn't exposed to .NET since Vista, does require COM interoperability.
- scarface74 7y ago
  Not really. You don’t use COM to access Windows API’s. P/Invoke is a completely separate method than COM. https://stackoverflow.com/questions/3138003/what-is-the-difference-between-pinvoke-and-com-interop https://stackoverflow.com/questions/3138003/what-is-the-diff... COM and C interop have always been separate and COM has been around since 1993. In fact, the native Win32 APIs use C style null terminated byte or double byte character arrays for strings. COM uses BSTR types - double byte arrays where the first two bytes are the length.
  - pjmlp 7y ago
    I see you haven't done much WinRT/UWP.
    - scarface74 7y ago
      You said that: Every Windows API that isn't exposed to .NET since Vista, does require COM interoperability You did not say “if you are using WinRT/UWP”. Also you said “since Vista”. WinRT was released with Windows 8, UWP was released with Windows 10. Also P/invoke is supported in WinRT https://stackoverflow.com/questions/8881335/pinvoke-in-metro-apps-with-windows-8-winrt https://stackoverflow.com/questions/8881335/pinvoke-in-metro... So no, you are not required to use COM for Windows API even with WinRT.

GordonS 7y ago

> C++/CLI or Managed-C++ Work is ongoing on this for .NET Core, or at least it was very recently. I certainly hope it will make it into .NET 5. App domains were never used beyond a few edge cases. For most of your other examples, I haven't personally used then for at least 5+ years.