We Keep Coding

What is the .NET 5 way of working with the Windows Shell? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 months ago.
Improve this question
I recently moved some of my software projects to .NET 5. I use the Microsoft WindowsAPICodePack to work with the Windows Shell, but this library is getting old and does not seem to be maintained anymore. Also, it's compiled for .NET Framework 4.7 or 4.8 and might be incompatible with .NET 5. So what is the 'proper' (as in best, modern) way to work with the Windows Shell from a .NET 5 app. For example, I use the old API code pack to get a user's libraries, get file icons etc. I noticed there is the namespace Windows.Storage which seems to have some or maybe all of this functionality, but it seems to be more targeted to UWP (maybe that doesn't matter much for a .NET 5 project?). Or do I need to look into WinRT? Any ideas?

The package WinCopies.WindowsAPICodePack.Shell was updated to 2.1.0, which brings .Net Core 3.1 and .Net 5.0 support:
So add the package
<PackageReference Include="WinCopies.WindowsAPICodePack.Shell" Version="2.1.0" />
and target your app as net5 and use the API like you did with the original package from Microsoft.

So what is the 'proper' (as in best, modern) way to work with the Windows Shell from a .NET 5 app
Officially, I don't think there is one. That is, it's undefined.
I note that C# and .NET really don't present the best developer UX for working with COM - it's a shame that in 2020 the best language for consuming COM is still VB6 and the best language for writing for COM is C++.
Though remember that WinMD and C++/CX is about modernising COM and it's the basis for WinRT and UWP - so I expect that most of the older shell functionality will be exposed through there which should be easier to consume than using COM interfaces directly. I also note that a lot of UWP's APIs are now available to non-sandboxed applications as well.
Someone did ask Microsoft to include the port in the now open-source WinForms project, but it was declined as being out-of-scope. (boooo!)
I use the Microsoft WindowsAPICodePack to work with the Windows Shell, but this library is getting old and does not seem to be maintained anymore. Also, it's compiled for .NET Framework 4.7 or 4.8 and might be incompatible with .NET 5.
Indeed. I don't believe it will work as-is, however the WindowsAPICodePack is a very thin wrapper over Win32's Shell COM interfaces, so it should be straightforward to dump the assembly using ILSpy and recompile it for .NET Standard 2.0 (so you can continue to use it in .NET Core, .NET 5 and .NET Framework projects).

Should i use Chromium Embedded Framework or .net for my desktop apps? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I see a lot of applications made with HTML for UI in Chromium Embedded Framework and I don't understand why they don't use XAML like WPF or something similar.
Should I use Chromium Embedded Framework over this? At the same time this uses C++ which is limiting because I only know C#.

tl;dr
Writing client apps in HTML/Javascript is good for cross-platform support.
Details
WPF is a good framework for developing rich client-side applications for Windows. This limitation is important. Developing client-side code in .NET, especially with a framework that's so tied to a single OS, ties you to one specific operating system. The example apps you bring, Steam and Spotify, are both cross-platform apps that have clients for Windows, MacOS and Linux and even browser-based web apps.
It makes sense, when you aim for cross-platform support, to share as much code as you can. There's no point in writing the same login flow, the same network access code, the same logic again and again, once in C# for Windows, in Swift for MacOS and in, say, Python/Qt on Linux. You want to find a common, shared platform that only needs minor modifications on each platform. HTTP/JS using a browser-based app framework (CEF, Electron or whatever) makes sense.

I use CEFSharp because I know a few JavaScript libraries that I really like for graphs (D3), charts (HighCharts), and datagrids (ag-Grid), and I wanted to use them in a desktop application. You say the Chromium Embedded Frameword (CEF) uses C++, and that is true, but you can use CEFSharp to work with it in C#. The cool part is that I can leverage the knowledge I already have with those JavaScript libraries and apply it when creating a desktop application.
I did not use XAML, WPF, etc. because I don't know them well, nor could I find the libraries I wanted to use.
The desktop application I created using CEFSharp and ag-Grid: EtwViewer

Developing for Windows 7 and above [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I want to make an Windows Desktop Application for Windows 7 and above.
Can someone tell me how can I start? I have tried searching on Google for developing apps for Windows; all I’ve found so far is UWP (Universal Windows Platform) which I believe works for Windows 10 and above. I have even checked the Microsoft docs and all they are telling is about Windows 10 apps, not a word about versions below it.
Can someone tell me if I make an app for Windows 10 will it work with earlier versions too? As the main requirement is developing for Windows 7.
I have been doing coding for 3-4 years so I know coding. I just want to start from right path. Please guide me.

Jason is right to a point, UWP is the modern way, but I would actually recommend WPF which was designed to replace Windows Forms.
It uses modern techniques and methods with C# like Caml for the UI layout, MVVM, View Model bindings etc, and it's all transferable skills into UWP and Xamarin mobile apps. As an aside Xamarin Forms are looking to build out WPF apps in future releases for true cross platform apps so it's a good framework to learn for Windows desktop.
Start here - https://learn.microsoft.com/en-us/dotnet/framework/wpf/getting-started/walkthrough-my-first-wpf-desktop-application

You are right that UWP is for Windows 10 and above, so I would stay away from that in your case.
What you should start with is a simple basic Windows Form development in C#.
Download and install Visual Studio 2017 Community Edition from here: https://www.visualstudio.com/downloads/
Then I suggest looking for tutorials online for Windows Form apps in C# which can guide you through it.
Here are a couple that could help.
http://www.guru99.com/c-windows-forms-application.html
https://www.youtube.com/watch?v=yGHzNunW8M8
There are more but they are for older VS Studio versions, but the principals are the same even if the UI is a bit different.
The DotNet Framework takes away a bit the dependency upon a specific windows version. As longer as your windows version can run the DotNet Framework version you are targetting (compiling for) then it will work in most cases.
Best to first find out which DotNet framework version is installed on your target PC and then build for that, or upgrade it.
It might look a bit different on different windows version, so if you are compiling on a different platform to what you are running on then it is best to make sure that you do testing on your target platform.
This shows how to change your target DotNet version in Visual Studio: https://www.youtube.com/watch?v=E36kiGWfGCQ

C# game development after XNA [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I am a game developer who made games in .Net languages with XNA for the past four versions of it. Unfortunately now there's this news: http://www.gamasutra.com/view/news/185894/Its_official_XNA_is_dead.php#.UQ3yiehQCh8
I am surveying the ecosystem of game engines, looking for something that supports coding in Visual Studio (I use F# heavily, believe it or not!) and I am having trouble finding something that is high quality, still alive, and high performance to replace XNA. Unity for example misses the mark because it only allows for scripting in MonoDevelop, while I want a more developer friendly experience.
So what is a good replacement for XNA?

If you want to leverage on XNA API, you should bet on MonoGame. It is a compatible XNA API that is targeting to run on several platforms (including several non Windows platforms using OpenGL). The development is very active, MonoGame is recently getting a full 3D stack that is starting to work on Windows Metro app (thanks to SharpDX). You can have a look at the latest develop3d branch.

There is nothing awesome like XNA. I don't get it why MS is throwing XNA away. It is the only System that works with the XBox 360. You can try Engines or Wrappers like Tao, SlimDx or something else. But XNA was the best System for rapid game development.
I'am now switched to Java + LWJGL.

I don't know when you checked last time, but Unity does in fact support coding in Visual Studio. You just have to select it as editor in preferences.

Imo if your going to be a game dev and you want complete control and want to port, and furthermore want to use C#.
OpenTK is probably the way to go. It supports up to OpenGL 3.0 and is compatible with mono, meaning you can port to PC, OSX, Linux, Android, and IOS. Ironically, about the only thing you can't do with it is xbox 360/1 and windows phone. But imo, If your looking to make games on phones Android and IOS is more than 90% of the market so go that route...
http://www.opentk.com/
Downside:
This project doesn't appear to have been updating since 2010, but it's very stable and feature packed up to open gl 3.0. But if you want to go farther with it you'll eventually need to update it yourself, but it's open source and under the GPL so you can.
OpenTK also has OpenAL included in it and handles graphics and sound.

Try looking at Axiom (.NET port of OGRE) and Delta Engine.
Edit: if you're looking for lower-level graphics libraries, try OpenTK or SlimDX.

Also, if you wish to get something similar with XNA, you can use SharpDX and SharpDX toolkit that provides pretty XNA-similar interface.
Look here
Download SharpDX from theirs site (choose 'SharpDX-Full-2.4.0.exe', it has samples inside the archive), unpack it and run SharpDXToolkitSamples.sln

No one has mentioned DirectXTK? I believe this is the direct successor to XNA which is being develop on / with Windows 8. Some More info from Shawn Hargreaves here.
Of course if you are interested in cross platform development checkout MonoGame as some have suggested.

Have you tried Tao Framework, Allegro and SlimDX

SharpDX allows you to make full use of DirectX from managed code, and it is currently very active, even with support for WinRT.

Unity 4.2 allows coding in Visual Studio for Windows 8 or RT. From what I understand 4.3+ will allow coding for Windows Phone 8 through Visual Studio. Though not the ideal substitute for XNA, still a viable one. As far as XBOX 360 or other platforms aside Windows 8 and Phone 8, I'm not sure if VS can be your IDE, but Microsoft is making a major push with Unity3D, check out there promotion for devkits for XBOX One. They are practically giving them away to Indie Developers:
http://techcrunch.com/2013/11/05/unity-game-engine-goes-free-for-indie-xbox-one-developers/
That's thousands of dollars of free software and hardware for indie developers. Another step closer to democratizing the game development process, and assisting indie studios.

Differences between Java and C# and .NET [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Apologies in advance for the possible flame thread, but that's not what I'm going for.
I've only ever done serious development in Linux using C and C++, and I'm looking to take the plunge into Windows. I've been doing some reading and asking around, and it seems to me that .NET with C# is the way to go for developing commercial user-oriented business applications for Windows.
A big consideration for me is the integration of the user interface into the desktop, since this is what the user ultimately interacts with. Is it possible to recreate the look of the Office 2007 GUI in Java, for example, or is this only possible with .NET?
I'm also concerned about portability. In the future, I may want to port the application to Linux. I know about the mono project, but I'm wondering if it wouldn't be better to go with Java.
In short, what are the trade offs between Java and C# when developing commercial, user-oriented business applications primarily intended for Windows?

The most important bit is in "primarily intended for Windows".
If you only need to work on Windows, C# is likely to be a much better bet than Java. There's a better variety of visual styles which blend in well with Windows. It also makes interoperating with native code (e.g. bits of the Win32 API or COM libraries) easier than Java. Personally I prefer it as a language, but that's a different matter.
If you need to run on other platforms, I'd seriously consider Java. While Mono has quite a lot of momentum, it doesn't have the same degree of compatibility with .NET as Java does on the various platforms it supports.
So basically, weigh up the "may want to port" aspect very carefully - it's the driving factor in the decision, from my point of view. Once you've decided to do a port, it doesn't matter much if 90% of your customers are on Windows - it'll still need to work, and work well, for the remaining 10%.

First off, whether or not your GUI will look good on windows will depend more on your skill with GUI design than it will on your choice of language or toolkit.
Windows Forms doesn't really give you full access to the Windows GUI functionality using the documented API. You'll have to make calls to native API functions or at least use windows-specific messages to achieve some effects. Also, I don't think there is a built-in way to access the Office 2007-style ribbon control. You'll need a 3rd party component for that.
A lot of .Net apps rely on 3rd party widget sets to achieve nice looking GUIs. Be warned that these frequently rely on P/Invoke or other windows-specific functionaly and thus don't work on mono. So if you really want a cross platform GUI, .Net is not the best choice.
You can also do .Net GUIs in Windows Presentation Foundation, but again this is not supported in mono.
GTK# works well on Unix and windows, though it looks slightly less native on Windows.
Java Swing is very cross platform and is looks pretty good with a platform native look and feel. You could download Netbeans to see it in action.
SWT is an alternate toolkit for Java that has slightly less cross-platform compatibility than Swing, but is still popular nonetheless. Eclipse uses this toolkit, so download that to see it in use.

Since you have an expirence with C++, you can go with C++ plus Qt for GUI. It's a good cross platform GUI library, and you can recompile the code to work in Windows, Mac, and Linux with consistent look.
Sure you can make nice interfaces with it, but maybe not as cool as MS Office interface (Microsoft blend).
You may consider it as an option.
http://www.qtsoftware.com/products/
Examples
http://www.qtsoftware.com/qt-in-use

If application is primarily for Windows - use .NET.
If you're serious about porting later - avoid use of P/Invoke, .NET above 2.0 features and 3rd party toolkits with rich GUI (which aren't running on Mono)
There are present nice and commercial .NET cross-platform apps including nice http://www.codicesoftware.com/xpfront.aspx
plastic scm UI http://www.plasticscm.com/screenshots/gui27/visual/brexplorer04.png
and many others - http://www.mono-project.com/Companies_Using_Mono
Also many developers prefer VS IDE over Eclipse and C# over Java. But if your application primarily Windows - I bet it's better to use .NET. ESPECIALLY if GUI integration is main concern, because making Java applications look like native Windows still painful. Under .NET there are LOTS of controls for Ribbon interface (inluding native one). Try to find same for Java with proper look and you'll understand what I mean
With Mono (if you will keep the main rules) most of the time you won't have a problem of porting and embedding Mono itself inside your application.