Window example? - Githubissues

yhojann-cl commented 8 years ago

There is an example to create a form.

using System;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;

namespace DemoApplication
{
    public class Program
    {
        public static void Main(string[] args)
        {
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
            Application.Run(new Form1());
        }
    }

    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }
    }
}

The propject.son

{
    "version": "1.0.0-*",
    "compilationOptions": {
        "emitEntryPoint": true
    },

    "dependencies": {
        "Microsoft.NETCore.Runtime": "1.0.1-beta-*",
        "System.Runtime": "4.0.21-beta-*",
        "System.ComponentModel": "4.0.1-beta-*",
        "System.Threading.Tasks": "4.0.11-beta-*",
        "System.Windows.Forms": "4.0.0.0",
        "System.Data": "4.0.0.0",
        "System.Drawing": "4.0.0.0",
        "System.Text": "4.0.0.0"
    },

    "frameworks": {
        "dnxcore50": { }
    }
}

To restore, dependencies not found:

me@machine:~/dnet$ dotnet restore
Microsoft .NET Development Utility CoreClr-x64-1.0.0-rc1-16048

  CACHE https://api.nuget.org/v3/index.json
Restoring packages for /home/me/dnet/project.json
  CACHE https://api.nuget.org/v3-flatcontainer/microsoft.netcore.runtime/index.json
  CACHE https://api.nuget.org/v3-flatcontainer/system.runtime/index.json
  CACHE https://api.nuget.org/v3-flatcontainer/system.componentmodel/index.json
  CACHE https://api.nuget.org/v3-flatcontainer/system.threading.tasks/index.json
  GET https://api.nuget.org/v3-flatcontainer/system.windows.forms/index.json
  GET https://api.nuget.org/v3-flatcontainer/system.data/index.json
  GET https://api.nuget.org/v3-flatcontainer/system.drawing/index.json
  GET https://api.nuget.org/v3-flatcontainer/system.text/index.json
  NotFound https://api.nuget.org/v3-flatcontainer/system.data/index.json 1435ms
  NotFound https://api.nuget.org/v3-flatcontainer/system.text/index.json 1434ms
  NotFound https://api.nuget.org/v3-flatcontainer/system.drawing/index.json 1435ms
  NotFound https://api.nuget.org/v3-flatcontainer/system.windows.forms/index.json 1498ms
Unable to locate Dependency System.Data >= 4.0.0
Unable to locate Dependency System.Drawing >= 4.0.0
Unable to locate Dependency System.Windows.Forms >= 4.0.0
Unable to locate Dependency System.Text >= 4.0.0
Writing lock file /home/me/dnet/project.lock.json
Restore complete, 1999ms elapsed

NuGet Config files used:
    /home/me/.config/NuGet/NuGet.Config

Feeds used:
    https://api.nuget.org/v3-flatcontainer/

Errors in /home/whk/Escritorio/dnet/project.json
    Unable to locate Dependency System.Data >= 4.0.0
    Unable to locate Dependency System.Drawing >= 4.0.0
    Unable to locate Dependency System.Windows.Forms >= 4.0.0
    Unable to locate Dependency System.Text >= 4.0.0

justinmchase commented 8 years ago

Basically those missing dependencies are actually missing. You can see what is in the repo here:

http://www.nuget.org/packages?q=Windows.Forms

Also, I don't think they're going to be porting Windows forms to this new system. I don't know if anything has been announced but I would imagine that some team in microsoft is working on it secretly right now.

joshfree commented 8 years ago

There are no plans to bring application platforms (winforms, wpf, etc) to .NET Core at this time. Closing out this issue. Thank you.

mwpowellhtx commented 6 years ago

This is a pretty serious oversight, IMO.

poiprotocol commented 6 years ago

The .NET Core team announced today that WPF support will be coming in .NET Core 3, but it appears it will not be cross platform:

Support for Windows desktop will be added as a set of “Windows Desktop Packs”, which will only work on Windows.

https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/

justinmchase commented 6 years ago

Thanks for the link.

But I gotta say that seems like an epic fail. In the first paragraph it says "... and enjoy all the benefits that .NET Core has to offer."

Yet it's windows desktop only. I just don't get it. They need a cross platform desktop UI not a windows only one. If I wanted a windows only platform I'd just use actual .NET.

How many years will it take them to do the thing they should have done on day one? Craziness.

yhojann-cl commented 6 years ago

If the .NET Core works 100% only on Windows, what is difference between .NET and .NET Core?, the .NET Core is Cross platform but the components works only on windows.

mwpowellhtx commented 6 years ago

WPF only? And then on Windows only? No WinForms? I tend to agree. Epic fail.

justinmchase commented 6 years ago

@WHK102 .NET Core is cross platform I believe. It can run on windows, linux, osx. But what they're talking about is making some kind of windows only UI thing that will allow you to load .NET core libraries. So you could have some underlying shared components that run in both places but they would have to be UI-less. Like maybe some networking library. You'll be able to build your UI but pull in all the core libraries people are building and sharing.

This sounds ok but its really disappointing that they aren't going all the way and making the UI components also cross platform to osx and linux as well.

mwpowellhtx commented 6 years ago

@justinmchase @WHK102 Precisely.

I have to pause and recollect the motivation of this rabbit hole into which Microsoft dove. Wasn't it motivated by the divergence of web based stacks? That is to say, MVC versus WebAPI, request, response, server hosting, etc, etc? Likely that more than et cetera, I gather. Is that accurate?

Over promised deliveries and scope snafus notwithstanding, perhaps it is justified, or perhaps not; I can certainly appreciate needing to align otherwise divergences in a code base having experienced domain specific forks along these lines myself.

However, clearly their priorities did not include support for "desktop applications", never mind across platforms. But I'm happy to be proven incorrect in this case. Which kind of leaves a vast chunk of the Microsoft based developers hanging in a lurch.

justinmchase commented 6 years ago

@mwpowellhtx I used to work for Microsoft but I no longer have have any special insider information. However, I can speculate and from my experience (purely my opinions below, not microsofts).

There is currently a tension between the younger teams who believe in and push open source and cross platform technologies and some of the older, bigger teams, especially the Windows team, who want to create Windows only platforms.

The older bigger teams have a lot of influence, top down, on the developer division and so they are able to exert pressure on bigger picture projects like this. In this case you can see that there is a desire for the existing windows only platforms to begin to adopt .NET core and so this is essentially their migration strategy. Its entirely possible that they, as stated earlier in this thread, have secret projects to create OSX and Linux UI platforms but I don't know if thats true but if I had to guess as of now I suspect they don't.

In my opinion, I guess its fine to do what they're doing but if I was Microsoft I would also be looking to build a non-XAML based cross platform UI system instead. If they have the resources to do both then I guess go for it but if not then I would scrap the windows only effort and focus on the cross platform one. I would also make the new cross platform UI to not be XAML based but look to make a superior technology. Evolve away from XML completely frankly. Because trying to give a lateral "upgrade" path for people already making windows only apps is not a real big market in my opinion. I think they should instead be looking to compete with Electron, as that is bleeding Microsoft platform technologies the most right now.

I do have one other insight to share and that has to do with the history of .NET, XAML and their relationship with Windows. Its interesting to note that XAML was originally created by shifting a lot of developer resources away from IE and onto the WPF team, this was why IE6 sat stagnant for a long time, the developers were gone! What they then made was the windows presentation foundation for what later became known as Longhorn, which ended up being a pretty large disaster. Longhorn largely failed because in they attempted to rewrite the windows shell using .NET and WPF. At the time (and still frankly) WPF had lots of really bad memory leaks, memory consumption issues, GC issues and a variety of other bugs and performance issues. This is why Longhorn was scrapped and what they ended up doing is to straight up reverting the Windows codebase back to several years to pre-longhorn and then subsequently worked overtime for another 3 years to crank out the gem known as Vista. Some people don't remember Vista fondly but frankly it was a hurculean effort and genuine evolution considering the prior turmoil that caused it. Or, it could have been worse.

So ever since Longhorn the Windows team has had an extremely bitter attitude towards .NET. I don't think its completely fair as they essentially went all in on a brand new technology and .NET has done a lot of evolving since then but nonetheless that sentiment remains among some of the now top players in Microsoft. So effectively there is a sentiment that some of the largest disasters in Microsoft history (IE's fall from grace and multiple "bad" versions of Windows) are, essentially, totally the fault of gambling on .NET and losing (from their perspective). And that sentiment can sometimes show in decisions like this.

So when Microsoft went to make their new metro apps for windows 8/10, they almost didn't even support XAML apps but only C++ and javascript. It was only the passion of the developer community that pushed it over the edge and let it in. I personally think that the .net developer community is the most vibrant and passionate one they have and if they were to create a cross platform desktop UI library it would spark a bit of a revolution. I mean right now everyone is moving towards Electron because, really, what else are you going to do? And while Electron is awesome there are some legit complaints and also there is some real complexity around native modules and such as well as some rendering performance limitations. Anyway the point is if they were to try to compete in that market they could legitimately make a dent, probably take over, and it would really be interesting to see.

Perhaps its a lack of vision, or perhaps they're actually doing it secretly right now but I suspect the truth is that the leadership, at some of the highest levels, is still stuck in the same mindset of windows desktop domination and it is prohibiting them from making correct decisions. I believe its likely that we will have to wait for some of the new guard to slowly take over before we can see these kinds of bold bigger moves.

masums commented 6 years ago

This is really strange behavior. Core evolved to be cross, universal. But Microsoft again disappointing a large community. What is the reason behind WinForm only for windows?

poiprotocol commented 6 years ago

The MS blog post provides some status and rationale. It really is worth reading in its entirety. But here is a key snippet:

Support for Windows desktop will be added as a set of “Windows Desktop Packs”, which will only work on Windows. .NET Core isn’t changing architecturally with this new version. We’ll continue to offer a great cross-platform product, focused on the cloud. We have lots of improvements planned for those scenarios that we’ll share later.

From a 1000-meter view, you can think of WPF as a rich layer over DirectX and Windows Forms as thinner layer over GDI Plus. WPF and Windows Forms do a great job of exposing and exercising much of the desktop application functionality in Windows. It’s the C# code in Windows Forms and WPF that we’ll include as a set of libraries with .NET Core 3. Windows functionality, like GDI Plus and DirectX, will remain in Windows.

mwpowellhtx commented 6 years ago

@poiprotocol Well, this is at least semi-not bad news, if it's accurate, and we don't see more scheduling snafus. .NET Core/Standard is what now? 2.1? 2.2? By at least "conventional" versioning standards. The natural next question is, "when"?

uffebjorklund commented 6 years ago

I would question the decision to even support wpf, winforms etc. .NET Core is awesome, dont screw things up by adding things like wpf. If you consider desktop client support I would go for creating a new option (not anything like wpf) and make it cross platform!

mwpowellhtx commented 6 years ago

Yeah, well, don't screw things up by not providing any sort of migration path for WinForms, WPF, etc.

charlesroddie commented 6 years ago

There is a lot of misunderstanding here, and among desktop .Net developers at large. Developers have a vision - wave a magic wand and my WPF code will run everywhere. But this is not thought through at all.

Of course when they crated a cross-platform .Net runtime, it could not include Windows-specific bits. This is called .Net Core.

Of course they are allowing .Net Core in WPF. It doesn't make sense to maintain multiple versions of .Net. .Net Core is better than the .Net Framework already. They just need to take out the Windows-specific elements and put it in a separate library for use in WPF.

Of course .Net Core is not going to have GUI components built in, let alone the whole of WPF. Many of the systems it must run on don't even have GUIs.

Of course WPF is windows-only. Any operating system has to have a UI framework. A cross platform framework would be built on top of WPF or UWP.

You can take WPF and emulate it on other platforms. But: 1. It is technically hard. 2. It is only be feasible on desktop platforms, so only allows you to run on 7% more systems (mainly macs). 3. The results would not be great on those systems. This is not a project that deserves serious investment.

The right approach:

Allow .Net code to run on all platforms, desktop and mobile (.Net Core and mono, eventually just .Net Core), and create UIs on each platform (WPF/UWP/Xamarin.Mac/Xamarin.iOS/Xamarin.Android). This is mostly done already in case you had not noticed.
Create an abstraction layer for people who want to do the UI code once. This is also mostly done already, by Xamarin.Forms, although desktop support is more recent and so is not at the same level as mobile support.

So if you want cross-platform .Net apps for mobile or desktop, follow Xamarin. If you want to create cross-platform apps for desktop only using platform-independent abstractions, contribute to Xamarin.Forms by using it, testing it, and writing and extending components for it.

mwpowellhtx commented 6 years ago

@charlesroddie To clarify a few expectations.

let's assume WinForms/WPF can incorporate Core/Standard bits. Fair enough; targeting what runtime(s)? Framework 4.6.2, for instance? Could be. But I think what most folks, including myself, perhaps badly informed, are expecting, is a Core/Standard comprehension.
you are also assuming calls for a WinForms/WPF port into "native" Standard/Core, so to speak, is to the exclusion of other delivery modes, i.e. console applications, services, etc. I cannot speak for others, but that assertion is utterly FALSE, on EVERY level.
I don't know how you can say that many systems do not have GUI's. GUIs are indeed dominant across most platforms in the desktop world. Even most modern *nix platforms have SOME sort of GUI comprehension, when you take into consideration Linux flavors, Ubuntu, Mint, etc. So, this is not a tall expectation by any means. Even if it is a shim to something like Gtk, Qt, or whatever. Make SOMETHING happen toward these ends.
some of us might like to run a GUI cross-plat, but are not willing to buy into the Xamarin cost of doing business.

Still, epic fail, IMO. Planning is in the wind, discussion concerning v2.2 of Core/Standard. With a weak promise of WinForms/WPF comprehension coming in, let's say, v3.x, to be accurate. Until it happens, this will continue to be the criticism, at least for my part.

charlesroddie commented 6 years ago

@mwpowellhtx let's assume WinForms/WPF can incorporate Core/Standard bits. Fair enough; targeting what runtime(s)? Framework 4.6.2, for instance?

You will in future be able to use WPF targeting .Net Core as a runtime instead of .Net Framework. You can already use .Net Standard libraries. Both runtimes support .Net Standard 2.0.

you are also assuming calls for a WinForms/WPF port into "native" Standard/Core, so to speak, is to the exclusion of other delivery modes... GUIs are indeed dominant across most platforms in the desktop world.

.Net core does/will run across mobile devices and desktops, which have UIs, and servers, most of which don't. It would be similarly crazy to put "send a text message" inside .Net core as it would be to put "display a ribbon" in there.

some of us might like to run a GUI cross-plat, but are not willing to buy into the Xamarin cost of doing business.

Of course I would be happy to see an approach with lower costs. I assume this refers to performance or reliability? Unfortunately the community commentary about what Microsoft should do instead has not come up with a better approach, and has just ignored the serious problems posed by the current multitude of operating systems and platform types, expecting some sort of magic.

With a weak promise of WinForms/WPF comprehension coming in, let's say, v3.x, to be accurate. Until it happens, this will continue to be the criticism, at least for my part.

The ability of WPF projects to use .Net Core has very little relationship to cross platform development. It's a convenience for WPF developers, who can take advantage of developments and performance improvements in .Net Core, and for Microsoft which can stop developing .Net Framework and focus on .Net Core.

mwpowellhtx commented 6 years ago

@charlesroddie Good points. It will be interesting to see how it goes.

justinmchase commented 6 years ago

Listen, its completely within the realm and resources of Microsoft to make a cross-platform desktop UI system. GitHub made one for crying out loud, called Electron. Video game makers do it over and over again all the time as well. Its not really that hard to do, frankly.

You make an abstraction over OpenGL and DirectX like every game engine ever made and layer a logical UI system over it. .NET core is already cross platform and that is the real hard part, adding in an graphics library is not really that bad. Heck, they could probably just use SDL and boom-done it.

Lets be clear here, the reason why they're still dinking around with Windows only UI platforms is because the upper management is still holding onto a fantasy that developers will voluntarily lock themselves into Windows by adopting them. Meanwhile marketshare continues to dwindle. Making a good .NET based cross platform desktop UI is what developers want, its what they've been wanting and needing for the past 10 years. This is, however, at odds with Microsoft upper level strategy. And that is because their upper level strategists are dinosaurs still holding onto the glory years and too busy fighting each other. That's what it all really boils down to.

Xamarin and XAML were fine experiments. They learned from it, that's fine, its time to evolve past it. Throw a team of game and tool makers together, don't be shackled to the past, make something actually good. It will pay off.

dasMulli commented 6 years ago

Reg. electron: There are already some apps out there using electron in combination with .net core - e.g. https://catlight.io

A lot of popular modern applications are built around electron, even MS products like VS Code.

I'm not sure that trying to compete with Electron makes more sense than trying to use it as a platform. There is so much experimental and proof-of-concept work going on with running Xamarin.Forms on the web via WebAssembly (+ upcoming DOM APIs for WebAssembly), or making ASP.NET Core / Razor run on WebAssembly (Blazor project), all of which would leverage the effort that continuously goes into Browsers and Browser-based shells. That also allows to instantly share components used in web applications with native apps, even if it is just a React/Angular/* framework calling to a .net core backend running locally. I don't really think that adding another platform trying to compete with the shift towards web technologies as cross-platform UI stack is worth the engineering effort.

On the other hand, allowing existing desktop applications to run on CoreCLR and make use of the deployment strategies introduced by .NET Core (side-by-side / self-contained) makes sense since it likely is a low engineering effort (still significant but low compared to creating a new UI stack) to port existing WinForms / XAML code to .NET Core while acknowledging that its use of Windows-only APIs restricts its use to Windows. But that instantly gives maintained existing Applications the chance to make use of new features both from .NET Core but also long stating issues in the desktop frameworks that can't really be solved without a few breaking changes so they can never be fixed in an update to .NET Framework (high-DPI support and "XAML Islands" is being mentioned frequently for this).

charlesroddie commented 6 years ago

Its completely within the realm and resources of Microsoft to make a cross-platform desktop UI system.

Yes but there is no business case for this. You are talking about desktop-only development (a niche already), where Mac usage is critical enough to warrant an abstraction layer (a much smaller niche: hobbyist apps, design apps?), but which don't need tailored design. The intersection of these requirements is approximately zero.

GitHub made one for crying out loud, called Electron.

This is not a desktop platform. It is both desktop and mobile. It's also terrible.

the reason why they're still dinking around with Windows only UI platforms

Any serious desktop or mobile OS has a UI platform. Windows has one. iOS has one. Android has one. Mac has one. A cross-platform UI system has to sit on top of native UI systems.

a good .NET based cross platform desktop UI is what developers want... [Microsoft's] upper level strategists are dinosaurs still holding onto the glory years

As everyone knows Microsoft lost out in mobile. Windows is just as dominant as ever in desktops. A cross-platform framework that is desktop-only is not solving any serious business problem.

Xamarin ... fine, its time to evolve past it. ... You make an abstraction over OpenGL and DirectX like every game engine ever made and layer a logical UI system over it.

I assume your suggestion is to evolve Xamarin to use platform-independent graphics rendering. That's not too hard; you can implement SkiaSharp as a target platform effectively. You would still need native controls in a lot of places (e.g. phone calls, media playback). And you can implement this piecemeal, one control at a time, as an option for developers. So really this is a much less dramatic suggestion than it sounds. And some of the work is ongoing in Xamarin.Forms. Slowly because there is some demand for this approach but not much.

justinmchase commented 6 years ago

A cross-platform framework that is desktop-only is not solving any serious business problem.

I believe this is untrue. I know there are a ton of cross platform desktop applications, despite the web. Companies like Skype and Spotify for example. And I know a lot of businesses still develop internal desktop applications designed specifically to use their internal software as well. And of course there are games, which use game engines such as Unity, Unreal or other tools and still most definitely count as cross platform desktop applications. Lets not forget VR also. As Chrome is currently pulling HMD apis into chrome and preparing to release them into an upcoming version of electron and Microsoft has no entry into this market at all. Moving last on VR could be strategically very bad.

It is both desktop and mobile.

This is also untrue, it is desktop only right now. There are others tools which are mobile so maybe you're thinking of one of those? When you say "its also terrible" it must be that you're thinking of a different platform because you were mistaken about the mobile aspect of it and it is actually pretty dang good. It has weaknesses though, but it is far from terrible.

You say there is no use-case for it but frankly there have been a number of really good desktop apps all targeting electron in the last couple years, Slack and VS Code for example (more). Apps like Spotify and Steam use the same technical technique even though they were made independently and prior to Electron by their respective companies. Native app abstraction, embedded web browser for the core logic of the app.

It makes sense for a range of applications which would target desktops. I know we're increasingly browser-centric but there remains a substantial number of relevant desktop apps which would benefit from a single cross-platform solution. I can think of a number of applications, even Microsoft applications which have struggled to be cross platform desktop apps and never even landed on Linux (cough Office cough) that could easily be Electron apps.

Windows is just as dominant as ever in desktops.

This is also untrue. Statistics from various sources show their desktop market share shrinking as much as 8% over the last 5 years. Source. This is a downward trend that will likely continue. Microsoft itself has begun to shift strategies on Windows, becoming more Cloud/Azure-centric. There is a reason why the new CEO was selected from their cloud division rather than their desktop division. This is when Windows 10 will be the last version of Windows, sounds dramatic but the point is that they will just continually improve it and incrementally update it rather than cut whole new versions. The price of Windows is cheaper than ever. None of these things are bad for users, its all good. Its just that they're less dominant and really what users want is the ability to use the apps that they need to do their work on various desktop platforms.

I assume your suggestion is to evolve Xamarin to use platform-independent graphics rendering.

No, I would not invest any more resources into Xamarin. I would let it fade away as well as XAML. Unity would be a much better partner to invest in. I would either work with them on making some plugins to make desktop application creation easier or just take a page out of their book and make a new tool that had similar underlying technology but was more focused on desktop applications.

charlesroddie commented 6 years ago

Skype and Spotify

Yes these are large enough that they need Mac support. At that level you probably wouldn't want to use an abstraction layer but can afford to maintain a second UI. This can be done easily already in .Net. E.g. WPF app and a Xamarin.Mac app sharing backend, model, viewmodel, with just one view for each.

businesses still develop internal desktop applications designed specifically to use their internal software

Extremely rare that these need to cover Macs.

game engines ... Lets not forget VR also.

These are not desktop frameworks. Cross platform desktop development, i.e. adding Mac, is of very little relevance. These are very cross platform and need to cover consoles, VR systems, and phones in addition to PCs. VR is certainly not tied to desktop platforms and has minimal need for desktop-specific features.

[Electron] is desktop only right now.

OK sorry about that, my mistake. I still maintain it is a terrible platform: it fills a need to get desktop apps out if already have web tech. But the performance and memory usage are appalling.

Microsoft applications ... Office ... could easily be Electron apps.

Microsoft does use Electron for some new Office apps, to the detriment of users. E.g. Teams consumes more than 10x the memory of other Office apps that do a lot more, and is sluggish even on powerful desktop PCs.

Unity would be a much better partner to invest in.

Unity's technology is not relevant to creating standard desktop apps.

dotus-git commented 6 years ago

@charlesroddie - It's refreshing to see someone who understands how absurd the notion of it being Microsoft's onus to develop WPF x-plat truly is.

justinmchase commented 6 years ago

I just want to point out that Microsoft just acquired Electron through their purchase of GitHub. So now they do have an xplat ui system. I predict we'll see that grow in importance.

mwpowellhtx commented 6 years ago

@justinmchase The acquisition isn't done yet; they have through the end of the year for all their ducks to fall in a row, or something like that.

justinmchase commented 5 years ago

More relevant news: https://blogs.windows.com/windowsexperience/2018/12/06/microsoft-edge-making-the-web-better-through-more-open-source-collaboration/

This may have an affect on the technology used for non .net Windows Store Apps.

Depechie commented 5 years ago

Just as reference, there is actually a cross platform effort based on UWP XAML outside of Microsoft: https://platform.uno/ If you still like XAML as UI markup, this lib works very wel... ( web, desktop and mobile )

yhojann-cl commented 5 years ago

Just as reference, there is actually a cross platform effort based on UWP XAML outside of Microsoft: https://platform.uno/ If you still like XAML as UI markup, this lib works very wel... ( web, desktop and mobile )

Official platforms supported are Windows, Mac, Android, iOS, but not Linux. https://nwjs.io/ is a better alternative but without .net core or c#.

dotnet / core

Window example? #43

The right approach: