This question already has answers here:
C# for embedded systems? [closed]
(11 answers)
Closed 8 years ago.
As I'm learning C# and my budding interest in embedded devices, I wondered If I can use C# in an embedded environment. How is C# going to help us in the realm of the Internet Of Things.
Note: The only question I found that resemble this is this one: C# for embedded devices
But this question has been asked 3 years ago. Obviously many things have changed since then.
Yes, there are at least three ways:
Through the .Net Micro Framework, however .Net MF is supported on a limited range of architectures, has a footprint of around 300Kb, and is not a hard real-time OS - thus precluding it form a large section of embedded applications. Although originally a Microsoft product, it is now an open source project.
The .NET Compact Framework running on Windows Embedded CE or Windows Mobile.
Through Mono running on embedded Linux.
C# requires a runtime environment that is not insubstantial which is its biggest barrier to embedded deployment in many applications. However if you have a platform with resources in the order of 4Mb ROM, and 1Mb RAM, or sufficient to support CE or Linux, then it is entirely possible. For high volumes or high value products, with complex UI and connectivity requirements it may make sense, but for simple applications it may be hardly worth the resource overhead and hardware cost.
Related
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.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I am trying to get more processing power out of my grid.
I am using all cpus/cores, is it possible to utilize the GPU with C#.
Anyone know any libraries or got any sample code?
[Edit OCT 2017 as even this answer gets quite old]
Most of these answers are quite old, so I thought I'd give an updated summary of where I think each project is:
GPU.Net (TidePowerd) - I tried this 6 months ago or so, and did get it working though it took a little bit of work. Converts C# kernel code to cuda at compile time. Unfortunately their website has been down and their github hasn't been updated for a couple of years, which might indicate the project is dead....
Cudafy - Open source and very easy to use. Converts C# kernel code to cuda at runtime (with ability to serialize and cache). Can easily run the same kernel code on the CPU (mostly for debugging). Supports multiple GPUs. More examples available than others here. The boilerplate code referred to by other answers is minimal, and in my case at least helped with my understanding of how the code works. Cuda/Nvidia only though. Unfortunately, it seems that they didn't update their solutions for a couple of years too (latest commit in 2015 -- support of cuda 7.0).
Hybridizer. Commercial solution compiling C# to CUDA. Provides a free community edition on visual studio marketplace and samples on github.
AleaGPU Commercial solution with a free community edition for consumer GPUS. See Daniel's comments for details.
Brahma - runs LINQ expressions via OpenCL (so supports AMD too). Not much documentation / examples. Last update in 2011.
C$ - last development was over 10 years ago...
Microsoft Accelerator - similarly doesn't look like it is being actively developed any longer.
some others (C++ AMP, OpenTK -- dead/Cloo) - many of these are just bindings - ie enable you to call the GPU from C#, but your kernel code (code which is actually run on the GPU) needs to be written in C or OpenCL, meaning you must use (and learn) another language.
As I said, I would recommend Cudafy over all the others - if it could run on OpenCL as well as Cuda it would be perfect.
EDIT SEP 2013
Cudafy now allows you to compile for both CUDA and OpenCL, so will run the same C# code on on all GPUs. This sounds fantastic, though I haven't tested the OpenCL compiling yet.
Microsoft Research Accelerator was a .NET GP GPU library.
I found Brahma... It also has a GPGPU provider that allows methods to run on the GPU... Thanks for the question... Learnt something new today. :)
Here's another one: CUDAfy. It sounds like GPU.Net, in that something as simple as a method-attribute can cause the entire method to run on the GPU. But unlike GPU.Net, CUDAfy is free and open-source.
GPU.Net appears to require no boilerplate code, though (According to their docs, it's "injected automatically by the build-tool"), while CUDAfy does.
Here is an example of building an application with CUDAfy.
Could I recommend XNA Game Studio as a possible avenue for exploration? It is obviously geared up for writing games, but gives you managed access to your graphics card and much better access to capability enumeration functions and shader development than was previously available in, say, Managed DirectX. There are also ways of combining WinForms and XNA into hybrid applications:
http://www.ziggyware.com/news.php?readmore=866
You'll have to put some effort into learning shader programming (XNA supports HLSL), but this may be a simpler approach than learning a vendor-specific solution such as nVidia's CUDA. The advantage is that you can program in a 100% managed environment. Here are some HLSL links:
http://www.ziggyware.com/weblinks.php?cat_id=9
The GPGPU site is also a recommended destination for general purpose GPU programming:
http://gpgpu.org/
Best of luck!
How about http://www.tidepowerd.com/ GPU.NET ?
Well this is a pretty old question, and since it's been asked things have changed a lot.
Another option for using .Net to write GPU code, which no one has mentioned in answers in Alea GPU. It covers C#, F# and VB.
Professional GPU software development environment for .NET and Mono.
Truly cross-platform
In F# official site, Alea is the first option for using F# in GPGPU programming.
To get to know this framework I suggest take a look at its comprehensive list of examples.
In addition to Brahma, take a look at C$ (pronounced "C Bucks"). From their CodePlex site:
The aim of [C$] is creating a unified language and system for seamless parallel programming on modern GPU's and CPU's.
It's based on C#, evaluated lazily, and targets multiple accelerator models:
Currently the list of
intended architectures includes GPU,
Multi-core CPU, Multi-GPU (SLI,
CrossFire), and Multi-GPU + Multi-CPU
Hybrid Architecture.
There's a new Microsoft solution in town - C++ AMP (intro here).
Use from C# would be via P/Invoke, as demoed here for desktop apps, and here for (don't-call-it) Metro apps.
Edit: I should note that C++ AMP has an open specification, which means it's not necessarily just for the MS compiler, or just for Windows.
Edit: Apparently, the technology is now in "maintenance mode," meaning they're fixing bugs, but not actively developing.
If your GPUs are all the same brand, you might be able to get GPGPU support from the vendor, either through Nvidia's CUDA or ATI's Stream. AFAIK, they provide DLLs, which you could use through P/Invoke.
CenterSpace Software has GPU-powered computation in their NMath libraries you can add to C# project. It's a commercial product.
Managed DirectX somehow, might work
WPF also uses the GPU and you can add custom shaders using HLSL.
A Series on GPU-based Effects for WPF (Greg Schechter's Blog)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
UPDATE:
1 - New C# application exposes NamedPipeServerStream(System.IO.Pipes) on .Net framework.
2 - Legacy VB6 needs to communicate with the C# NamedPipeServerStream.
3 - Until now VB6 resides in a system without .Net framework. But, going forward both C# and legacy application will be on a computer which has .Net installed.
3 - Can VB6 talk to the C# pipe server using CallNamedPipe() and is this approach hassle free in maintenance of the communication betwen the applications?
Any resources I can look into or other approaches ?
Old question:
I have a legacy VB 6.0 application which needs to communicate with a newer C# application using .Net NamedPipes.
Currently, the legacy VB6 application sits on a system without .Net.
When I install .Net framework and the C# NamedPipeServer application on that system, how can the legacy VB6 program communicate with the C# application over NamedPipes ?
Please let me know.
Thanks in advance.
I have worked with a VB6 application which needed data from a set of WCF services.
The easiest way to achieve this is to put the logic to communicate with remote systems in a .Net assembly which exposes operations via COM and call that assembly from your VB6 code.
See https://msdn.microsoft.com/en-us/library/system.runtime.interopservices.comvisibleattribute(v=vs.100).aspx as a starting point.
If you are using System.IO.Pipes for this then thankfully you don't have to deal with the cruft and interoperabiity nightmare known as WCF.
To write a nice pipe client in VB6 requires a control or class written in C++ in order to manage the async I/O and raise events. Otherwise you will probably have to use a Timer to poll for input, but it is all fairly straightforward API I/O then.
I don't know of any cheap or free ActiveX DLL or OCX generally available today, and I doubt Microsoft ever produced one. But the Timer-driven polling approach should have plenty of examples out there to get you started. And it spares you the terrible inefficiency, stops and sputters, and giant memory footprint of saddling your VB6 program with all the overhead of using .Net Interop.
But that is always an option.
This question already has answers here:
Running .net based application without .NET Framework
(13 answers)
Closed 9 years ago.
I created a windows application using c#.net, and i converted it into .exe
can i run this application on another system without installing .net framework?
please clear my doubt.
Thanks
C# apllications are not handled by the operating System. Its CLR(inside framework) (Common Language Runtime) who takes care about running the C# apps and also about all memory management, resource allocation, de-allocation etc. It creates a virtual layer over the OS while running the application. So you need the .NET-framework!
Its not about C#. Its about weather you want to develop managed or unmanaged applications. C# is the choice for developing managed applications which run on .NET Framework.
If you want to avoid that , you can go to Visual C++ (without .NET) development using Visual Studio.
However, .NET framework comes pre-installed with latest Os like Win 7 these days.
This question already has answers here:
What Are Some Good .NET Profilers?
(30 answers)
Closed 9 years ago.
I am currently working on a C#/XAML application, I need to do performance profiling to figure out XAML bottlenecks. Any good profilers/tools available?
Visual Studio (Performance tools) download and How to do.
RedGate Ants Profiler
Telerik JustTrace
The last 2 are good ones, and not free
PerfView is free tool that is used by the CLR performance team. It is specifically designed for profiling the performance of .NET applications and can do both CPU and memory (managed heap) investigations. A plus is that it doesn't require running an install on a machine to collect performance data. There is an awesome series of videos by Vance Morrison on using the tool.
what app are you developing, WPF, Silverlight or win8? Basiclly the profile tool inside Visual Studio is enough to figure out the bottlenecks.
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.