Is there any way I use a desktop application based on forms on a server through an asp.net web page client side?
I believe that you will be blocked by antivirus/antimalware solutions (even those from Microsoft).
You could start an aplication from browser IF using a kind of Plug-In, but in the last years that is exactly the way of malwares and viruses to damage computers. And because of it, evey security application (and even UAC and browsers themselves) are not allowing that kind of action.
You may risk put your solution into a plug-in and it be confused with viruses/malwares.
Related
I am exploring the current news for ASP.NET WinForms with .NET 4.6.
The resources I am currently looking at is this Video overview by Microsoft Program Manager Pranav Rastogi and an article on DotNetCurry. Besides the information, that I will require Windows 10 Preview, I can not decipher, what this really means to me as a WebForms developer.
To use HTTP/2 will I...
need to make some changes in a config file?
need to change something in the page / master page?
use a different programming model when it comes to serve resources?
Of course, IIS will need to be configured, but this does not affect me as developer.
Is there actually something I need / can do as developer to support HTTP/2?
Note: If someone sees this as a better fit on Programmers or other SE site, please move.
Basically, HTTP/2 is seemless for web services. The basic functions, request/response multiplexing and header compression, are defined at the network protocol level. That means it can be seen as the matter of web browsers and web servers.
But for the new features like HTTP/2 server push and stream priority/dependency, it needs to be considered for developers. To use those features, web browsers and web servers should provide APIs.
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.
Basically I have an asp.net application which is installed on clients servers to work alongside an existing desktop application. What can I do to stop a client copying the files and installing somewhere else and running it so they can't stop paying but continue to use the system?
The only 100% way I know that you can use is to have a call to some webservice you control to validate every time the application starts or in any other event you want. Still, clients could decompile it and patch it to remove the check although this is unlikely.
However, I wouldn't worry about validating this as much as I would if I had to have this kind of lock in place. If you believe your clients are doing this they are not good clients to start working with.
Is there a way to make a desktop application easily interfaceable via Web ? Meaning, can you have a way to interface with a single desktop application as if you were remote desktop'd into the machine but not? I am looking at doing this in ASP.NET or Silverlight.
I'm not sure if this is exactly what you are looking for...
If you were able to create your entire application UI in Silverlight and host it properly (in IIS or whatever) it would then be accessible from anywhere on the web. If you needed the perception of a real desktop app when running locally, you could then just make some simple app (WinForms, WPF, whatever) which contains a web browser control that could also load up the hosted Silverlight app (and just be a transparent browser). Depending on what the application is doing, you would obviously need some sort of service layer (probably in WCF) do to all of the heavy lifting and data access.
I guess the main question would be: can you accomplish everything your application needs to do in Silverlight? Since Silverlight is meant to run in a browser, it can be very limiting.
There are many solutions based on plugins. Some of the popular ones:
Citrix
Spoon
If you're ok with plugins, but only if they're common ones (flash, java), there are various solutions:
http://www.wizhelp.com/flashlight-vnc/
http://www.tightvnc.com/doc/java/README.txt (bundled java applet with TightVNC)
If you don't want plugins at all, there's an experimental HTML5/javascript VNC viewer:
http://guacamole.sourceforge.net/
I don't understand the purpose of the WPF browser appliction. Is it simply another way of serving information through a browser, or is it not intended to be used for external deployment?
WPF Browser applications allow you to create very rich, application style UI's deployable via the web, using coding languages windows developers already likely have in their toolset. The downsides are that the users must must have .net installed, and use IE to access the application, considerably limiting the size and scope of your audience. WPF browser applications are very similar to Java applications in that they run in a virtual machine on the client. As it runs on the client, all data access and communication with the server must be done through WCF or web services.
With ASP.NET you have considerably more cross browser compatibility and support, giving you access to a much larger audience, with the possible downside of learning new libraries and the ASP.NET programming model. ASP.NET also provides a rich data access model and data control support. Silverlight is another interesting option based on .NET and WPF, as it is supported by a wide variety of browsers and provides similar rich user interface experiences. It can als be run out of the browser, disconnected if neccesary.
** Update based on Comment Request ***
The big advantage to Silverlight out of browser, is that you get most of the Rich, windows application style functionality, with a web deployable model and tiny install (4-6MB). Silverlight also supports an auto update feature which is VERY nice if you have a large user base.
Microsoft's Official description (propaganda :) )here
Silverlight Out Of Browser
Enables users to place their favorite Silverlight applications directly onto their PC and Mac, with links on the desktop and start menu—all without the need to download an additional runtime or browser plug-in. Further, the new experience enables Silverlight applications to work whether the computer is connected to the Internet or not—a radical improvement to the traditional Web experience. Features include:
Safe and secure. Leveraging the security features of the .NET Framework, Silverlight applications run inside a secure sandbox with persistent isolated storage. These applications have most of the same security restrictions as traditional web apps and so can be trusted without security warnings or prompts, minimizing user interruptions.
Smooth installation. Because Silverlight applications are stored in a local cache and do not require extra privileges to run, the installation process is quick and efficient.
Auto-update. Upon launch, Silverlight applications can check for new versions on the server, and automatically update if one is found.
Internet connectivity detection. Silverlight applications can now detect whether they have Internet connectivity and can react intelligently including caching a users’ data until their connection is restored.
A WPF browser application is a client side technology, rather than ASP(.NET) which is server-side. It is definitely not meant to replace it.
Using a WPF browser application one can provide a rich client inside the browser. However, this will only work when the whole .NET framework is installed. Another similar technology is Silverlight, which uses a very small (the installer about 5-6 MiB) framework, and is available to multiple platforms. It includes a small subset of .NET framework.
You can use it in external deployment considering the above requirements.
The following portion of the above selected comment is wrong:
and use IE to access the application,
considerably limiting the size and
scope of your audience
WPF in the browser (aka XBAP) is works just from FireFox (Mozilla) and Google Chrome. It was true about 2 years ago, but not today.
You could use XAML in silverlight, if thats what you are looking for.
Plus the RIA Application templates makes development quite neat.