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.
Related
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
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
Say I coded some application in C# using visual studio. Is there anyway I can take this application and embed it into a website so folks can use it from a website in the same way I would use it from my desktop?
If you coded a console application - no.
If you coded a winforms application - no.
If you coded a WPF application - yes
Two options:
Migrate it to silver light and it will only work on browsers which can install the silver light plug in. keep in mind that silver light is being disbanded by Microsoft, so it is not considered a recommended practice anymore even by MS. also consider that not everyone would agree to install silver light plugin for their browser.
You can also migrate your WPF to become a browser application - but this will require the client machine to have .Net installed on it - so this is like a replacement solution to what once was achieved by ActiveX technology.
Main difference between those two options is that the 1st one is cross-platform/cross-browser solution and the 2nd one is not.. however this might change in the future as .net is becoming available to Linux too..
If you coded ASP.Net - it is already designed for developing web applications.
I'm not sure what exactly you are trying to achieve but I think the WPF/Browser APP is what you looking for, you can read more about it in How to: Create a New WPF Browser Application Project
Edit:
I thought I'd mention if you have a Console or Winform app that people wish to use remotely (ie via a web browser) don't forget they can use Remote Desktop to access the application. Many large enterprises do this using Citrix. Often this is more practical when the cost of rewriting legacy applications is not feasible.
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 8 years ago.
Improve this question
What are the possible ways to convert a windows form application (c# , .net) to a cross platform project?
My GOAL is have a project that can run in both Linux base os and windows.
I really like .net but it's not compatible with all OS (for example Linux) because of .Net Framework installation.
what is your suggestions?
As #paqogomez pointed out, IronPython does not take away the need for some sort of .net since, as it's stated on the website http://ironpython.net/ : "IronPython is an excellent addition to the .NET Framework, providing Python developers with the power of the .NET framework."
Since your goal is to run your existing winforms-c#-application on both, windows and linux, you might get away by just using mono (http://www.mono-project.com/).
If this doesn't work out (please refer to http://mono-project.com/Compatibility for compatability issues), you could manually rewrite your existing C# application in pure python. But then, it might well be possible to use any other unmanaged, managed or scripted language which can be used on both systems and which is either easier to translate manually or for which even automated translators exist (however, I don't know if there are any for C#).
Thinking about the last point, I did a quick websearch for "c# cross compiler" which shows some esoteric results which might be interesting for you depending on your project type.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I have little experience in C#.NET, but have years in Delphi. Any Delphi + .NET people out there that can provide me some guidance?
Here's the scoop:
I am going to be in charge of a overhaul of the codebase (200,000 lines+). We're going to be creating a full n-tier architecture, with the front end being Silverlight. We chose Silverlight as the front end because it can be deployed in a browser as well as an application with minimal effort, from my research.
I have not been able to find a clear comparison between Remobjects SDK and WCF. The few threads I encountered mention the issues with WCF, such as response times, large overhead, and somewhat snotty responses from MS.
This question is more for the backend. Our current codebase is in Delphi. Is it worth keeping the backend in Delphi, if at all possible? The debate is between using WCF if moving to .NET, or using Remobjects SDK (.NET and Delphi flavours simultaneously) if sticking with Delphi.
Pros of Delphi backend + Silverlight frontend:
Existing codebase: Less time during migration
Existing Knowledge: Developers familiar with our codebase are already familiar with Delphi
Easy Deployment: The single exe/dll deployment is difficult to ignore!
Cadence: The Remobjects SDK has been solid for years
Cons of Delphi Remobjects SDK backend + Silverlight + Remobjects SDK frontend:
Technology: Is it even possible for Remobjects .NET to communicate with Remobjects Delphi with Session functionality?
Knowledge: Other that our few developers, the knowledge of delphi is very thin in our city area.
Project code re-use: We would need to re-develop classes in C# as well as Delphi for use in Silverlight.
Cost: Additional cost in licensing
Future: hard to say when Delphi will collapse
Now for the WCF .NET..
Pros of WCF .NET backend + Silverlight frontend:
Project code re-use: A class can be used in both the backend and frontend
Technology: Its already proven
Knowledge: Our city area loves .NET, so there is lots of talent available to hire.
Future: Everyone knows that MS is making tons of money off .NET and VS 2010. This adds some stability to the .NET architecture.
Cons of WCF .NET backend + Silverlight frontend:
Existing Codebase: Our entire codebase would need to be redone, aside from class structure references.
Deployment: I myself have not deployed a WCF application, but I know its more complicated than Delphi.
Cadence: Microsoft is notorious for changing the game as soon as the industry settles. Happened to COM, when will it for .NET?
What would be the ideal situation? After writing this all out, its looking like C# backend is the winner, due to the lower costs and higher chance of a stable future. Whichever backend we use now will be the method of choice for all projects in the future.
What are your experiences with implementing your WCF n-tier application?
Are there clear any clear and concise books / articles that outline WCF's usage, and best practices when designing your application?
Is there a better solution than WCF in this situation?
Sound off your thoughts!
Joel on Software has a pretty good article about rewriting from scratch (http://joelonsoftware.com/articles/fog0000000069.html). I'm not sure if that completely applies to your situation, but the gist of his article is don't rewrite, ever. You have years of work and bug fixes already in that code, and rewriting it in another language simply won't be able to cover all of those fixes. My recommendation would be to find a good way to interface your Delphi back-end with the new Silverlight front-end. That being said, I've never done any interfacing with Delphi, so you're on your own from there.
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 years ago.
Improve this question
I am getting a headache with standard socket class of .NET framework.
Could anybody recommend an efficient open source C# sockets (TCP + UDP) library for handling socket messages?
Use Kerry Jiang's SuperSocket library or Akka.NET
SuperSocket nuget package has over 100k downloads; note that 2.0+ is for .NET Core, whereas 1.6 is for .NET Framework 4.8 and below
SuperSocket.ClientEngine.Core has over 700k downloads
Akka (for .NET) has over 1.2M downloads, and has a special Akka.NET.Test
In a sense this is cheating because it postpones the decision of using sockets to the last moment
"Akka" started out as a Java/Scala project and was later to .NET
Therefore, you should Google search for "Akka.NET" instead of just "Akka"
In general, you probably want to construct your Network IO with some solution for back pressure, which you can do with Akka Async Streams in C# 8.
RSocket is a new library built by ex-Netflix engineer Robert Roeser.
Similar to Akka Streams in that it provides a way to handle backpressure.
Separately, in terms of using message queuing libraries instead of socket libraries:
EasyNetQ nuget package has over 4M downloads
NetMQ nuget package has over 600k downloads
ZeroMQ nuget package has over 80k downloads
I've used this in a real world project and it works fine, but it's a binding wrapper around a C dll
NetMQ is great for simple socket communication. It handles the reconstruction of messages and much of the messy details. It's meant for message communications as in a messaging system, but it would work great for simple sockets. Take a look at Request-Response. Sockets are one of the areas where you do often end up with framework on top of framework, regardless, let NetMQ handle the nitty gritty.
Take a look at WCF which is included in .NET.
I made sample application in for console/win app based C# WCF/TCP socket server/client here
https://github.com/evaldsurtans/wcf-sample-server-client
The .NET framework is already a library for handling tcp and udp. It simplifies the process greatly over the base winsock apis. So you want a library that sits on top of the library? Maybe you would then want another library on top of that? And another on top of that one?
My point is, you're likely not going to find anything simpler than what the .net framework already provides. Sockets are a complex topic, and requires that you provide a great deal of implementation yourself.
What a library is often useful for is implementing some already established protocol (like SMTP or FTP), or maybe even giving you more tools to create your own protocol.