We are planning on replacing a legacy "server" app (a Windows form app with, although it does not really need it, a GUI representation (showing status messages)) with a simplified service of some sort. The server/service responds to requests for data and sends said data. Will a legacy (.NET CF 1.0) app, which cannot be updated to a newer technology (because the handheld devices on which they run don't have room for the more recent/larger .NET Compact Framework runtime) be able to access "newfangled" services such as an asp.net RESTful web service? If not, what are some other options? Or, if there are better options even with that being feasible, what might y'all suggest?
No, the older .Net "Service references" don't understand newer formats/protocols.
But, at the end of the day, it's all just a bunch of auto-generated code mapping "objects" to XML.
SUGGESTION:
Just parse the XML directly.
If in doubt, play with your target service using SoapUI
Unless you've got a really complicated schema, that's probably the easiest to program - and most memory efficient - solution.
IMHO...
Related
Recently I built MEF WCF service, hosted on IIS 8, which receives the command, performs long background process with SAP ECC and Local DB, then returns the status. So user interface input and output is only the string.
In Internet there are many blog post about WCF Dead and that it's better to use WEB API, and in the future ASP.NET Core, which is even better...
My question is, is there the sense to update the project to ASP.Net Web Api or wait to ASP.Net Core, or it's better to use another technics for this type of work?
Having more people talking about a technology does not means another similar one is completely dead; as an example look here to find about incoming WCF implementation for .Net Core.
Of course, this is a subset, as for Web API, MVC or Entity Framework are not uspporting today all features that their Full 4.x versions do.
Short answer: you can keep you WCF implmentation and come back later.
Longuest answer: look at what features WCF for .NET Core contains (especially for bindings) to see if porting would be easy, or if you need alreday to tihnk about moving to something else.
I'm brand new to C#/.NET
Why does ASP.NET have so many different choices of projcets? (Web Application, Web API, Web Site, MVC ect). I just want to listen on a tcp port, and a way to send a response. If there are libraries to help me do routine stuff like constructing the HTTP request, parsing the header, ect - then cool. But I don't want a super opinionated framework that tries to do everything under the sun.
Why do I need IIS at all?
Addressing your points in reverse order, first - why do I need IIS?
The answer is, maybe you don't. If you are doing a simple listener that won't be exposed to the public internet, then you don't need it.
If you are doing a web application that needs to scale, be robust and easy to manage then it can help you with:
Logging
Operating in a multi-server environment for scale/high availability
Handling multiple requests in an isolated way
Serving multiple applications from the same host with sandboxing to ensure each application has guaranteed resources (memory, CPU)
Application lifecycle management
IP address restrictions
support for FTP, CGI, WebDAV
URL rewriting
Response header manipulation
Failed request tracing
Protection against some DoS exploits like slow HTTP attacks
Etc.
In short, it is an industrial strength, real world web server that will keep your application up reliably in a hostile world and scale as your application grows. it is certainly overkill for some cases if you don't need this kind of scale/high availability/management capability. In those cases you have the option to self host ASP.Net in a Windows Service or even a console app. This might sound complicated, but it has been made pretty simple by OWIN - Open Web Interface for .Net. This is an abstraction of the interface used by Asp.Net to communicate with its hosting server.
There is a very good tutorial on how to self host web API in a console app here
http://www.asp.net/web-api/overview/hosting-aspnet-web-api/use-owin-to-self-host-web-api
It does exactly what you ask for in your comment:
You create a console app project
You add references to the right assemblies (the tutorial uses NuGet to download the assembly packages)
You code up your web operation logic
You compile
You run the resulting exe
That's it!
On your second point about ASP.Net - it is a framework that has gone through a lot of evolution trying to keep up with very rapid changes in the web development world. This meant it got a bit bloated and lost some of its coherence, but recently the developers have been focussed on making it more lightweight, more modular and simpler. Scott Guthrie summarises it in his blog:
http://weblogs.asp.net/scottgu/introducing-asp-net-5
Why does ASP.NET have so many different choices of projcets? (Web Application, Web API, Web Site, MVC ect). I just want to listen on a tcp port, and a way to send a response. etc...
Because each project has its own purpose.
If you want to just listen on a TCP port then you could go learn Microsoft's Katana OWIN (but I highly doubt if this is what you want).
Katana OWIN
Briefly going through each projects purpose:
"Web Application" actually opens up another window and lets you choose from the following:
Web API is for exposing RESTful services or JSON data.
Web Forms is for making web pages that use Web Form components.
(A bit like Windows Forms, but Web)
MVC is for making Model-View-Controller web applications. This is where you build components with a separation of concerns. Model for data. View for what the user sees. Controller for controlling how your page behaves.
Why do I need IIS at all?
IIS is for serving .NET applications.
Without it, it would be quite hard to serve .NET applications.
I'll start with 2 then move on to your first question. IIS will run whatever the .NET web service you need, be it a monstrous WCF service, an ASP.NET application or the most basic http handler.
To my knowledge, ISS is the most straightforward way to use .NET web services. If you are used to PHP, it's basically LAMP or WAMP for .NET, which means it is sort of necessary. There are alternatives, as Mike Goodwin points out, but I have to admit I am not familiar with those third parties. Since replacing a layer for another doesnt mean much, I would stick to the "normal" procedure.
Since you dont want the framework to do a truckload of operations for you, your best bet might be along those lines:
Create a basic ASP.NET projet
Remove the default ASP.Net page because it seems you dont want it
Add a Generic Handler to your project. This will result in a myFile.ashx, which handles http requests and let you build any response you want
Of course, if you dont want to bother with IIS configurations, you'll need someone to setup an URL on IIS and map it against your handler repository.
EDIT:
"Abstraction layers" would be the very definition of frameworks, for good or ill, so you're stucked with it.
Now, since you have a low level background a not-so-intrusive way to work with the .NET web services would probably be the three steps I suggested earlier. You are still stucked with IIS though, in order handles the communications (i.e. manages sockets/requests). That's the way the framework works.
STILL, THERE IS HOPE. If you have complete control over your server (which is not my case, some other IT team manages the web servers), you certainly could build a windows service that listens to some socket and work the requests accordingly. It is a most unusal solution if you want to serve web pages, but would work rather well if you only want to push some data through http requests. If you go down this path, I suggest you take a look at the System.Net namespaces, you'll find some classes like "Socket" there. Combined with a console application or a windows service, you could work something out.
One of my coworkers is former microcontroller designer, I know exactly what kind of feeling you have towards the .NET framework. You'll go through some frustrations at times, but most of the time there are work arrounds. Feel free to request more details if you need some.
I have a Delphi Application with a Client-Server Architecture. Now, I want to write a Web-application for this Delphi Client-Server Application.
To write a this Web App I don't want to use Delphi - I want to use a "modern" Web Architecture like a PHP Framework, ASP.NET, Ruby on Rails etc.
So far i came to one possible Solution with RemObjects (http://www.remobjects.com/ro/) and ASP.NET:
In this approach the Delphi Application communicates with an ASP.NET WebServer over RemObjects where the Delphi Application is the REM Objects Server and the ASP.NET App is the Client.
My questions are:
Is this approach really a good idea and if not why?
What are other possible approaches to solve this problem?
Thank you for your help.
Edit:
Thank you for your answers so far!
How about establishing a neutral link like a Database?
You need a two-way messaging / inter process communication solution. Typically SOAP, REST and other web services (RemObjects) are synchronous, request-response style communication.
A messaging middleware can be implemented in a way which totally decouples the applications so that you can restart any part of the system (for example for maintenance and update installation) without disturbing the others.
Popular open source products in this field are for example Apache ActiveMQ, Open Message Queue and RabbitMQ, which offer cross-platform/cross language clients.
An alternative could be SOAP, or a RESTful connection.
R/O is faster than SOAP, for sure, and well integrated to both sides (Delphi and C#).
And, since you are already using R/O between Delphi client and Server, it will be the first option to consider.
IMHO any RESTful connection between Delphi Server and a C# client may do the work also. And will probably be faster, so is to be considered only in a second phase, if you find any performance or stability problem with a R/O connection.
I have to write an app for iPad that would take data from SQL Server and post it to the iPad. I looked up on this over the Internet and found that i have to write a web service to expose the data from SQL server using ASP.NET. I did an app previously in android that would take data from my dropbox a/c and display it to the user. I made use of the drop-box api available. I was wondering if anything like that exists for SQL? Also, i have to code in Obj-C for the iPad, so how will
i write ASP.NET code? I have more doubts.
Thanks in advance.
There are many options for web services. If you are developing in ASP.NET and don't want to invest to much time in just accessing the data I would suggest some software that will help you generate the source code.
WSSF (Web Service Software Factory) is software that will assist you in creating a SOAP web service and it generates source code for you. I do recommend however working through a tutorial first before just jumping into using this. WSSF uses visual studio as well.
Once you have a web service that packages your SQL data for communication through http requests. You will need to parse the data communicated in Objective-C. For this you'll find SudzC to be very helpful.
SudzC generates all the source code for accessing your web service in Objective-C, given the WSDL.xml file of your web service (a file that lays out the design of your web service).
Although these software will save you a lot of coding, I wish I could tell you that this will be a short and easy process. However this is vary rarely the case, developing this will take you a couple of days.
I do know that people often use RESTful web services when dealing with the iOS enviroment, although I do not have the same kind of experience with them as I do SOAP web services. I hope that this information is helpful to you.
I've done this. The best way is to use .NET 3.5 or higher to create a WCF (Windows Communication Foundation) project. These projects will let you communicate with your mobile application using REST or SOAP. They also let you send data in XML or JSON format. You will then need to create a REST or SOAP client in your IPad application to communicate with the server.
Use OData. See Creating an OData API for StackOverflow including XML and JSON in 30 minutes for how to publish your SQL Server data as an OData service. See Consuming OData using Objective-C for how to consume the OData service from your iPhone app.
I have a need to explore VOIP integration into a .Net application. It would be incredibly helpful if the toolset was usable via ASP.Net (version 2.0 or higher), and provided the developer the option to allow interaction on the client either embedded within the web browser or external to the client web browser. It should be compatible at a minimum with Internet Explorer, but would be better if browser independence were an option.
I don't really understand your question -- what are you trying to DO with VoIP? Since you mentioned ASP.NET I'm guessing you mean some kind of server app? If you explain more about what you want to do, we can give you better advice.
You could check out Microsoft's Speech stuff: http://www.microsoft.com/speech/speech2007/default.mspx. As I understand it, Speech Server was moved into being part of OCS. I remember that it supported using .NET 3.0's Workflow Foundation as well as some multi-modal stuff with ASP.NET.
FreeSWITCH is a flexible VoIP system that works for both large-scale server implementations as well as embedded scenarios (say as an ActiveX softphone). There is full .NET and Mono support via mod_managed. (This allows you to create voice applications in FreeSWITCH using any .NET language.) There's also an XML-based API that allows you to send and receive events to control a remote FS server. You could use this from ASP.NET. FreeSWITCH is very active in #freeswitch#irc.freenode.net so you can get a lot of advice there.