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.
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'm trying to eliminate (or at least minimize) startup/warmup times for my .NET applications. I'm not really sure on how to do this even though it's a common concern.
There's a ton of questions about slow startup of .NET applications. These are easily explained by pool recycles, worker process startup, dynamic compilation of .aspx files, JIT etc. In addition, there are more things that may need to be initialized within the application such as EntityFramework and application caches.
I've found alot of different solutions such as:
ASP.NET Precompilation
IIS 8 Application Initialization (and for IIS 7.5)
Auto-Start ASP.NET Applications
However, I'm not entirely satisfied with any of the solutions above. Furthermore I'm deploying my applications to Azure Websites (in most cases) so I have limited access to the IIS.
I know that there are some custom "warmup scripts" that uses various methods for sending requests to the application (e.g. wget/curl). My idea is to create a "Warmup.aspx" page in each of my ASP.NET applications. Then I have a warmup service that sends an HTTP GET to the Warmup.aspx of each site every ... 5 minutes. This service could be a WorkerRole in Azure or a Windows Service in an on-premise installation. Warmup.aspx will will then do the following:
Send an HTTP GET to each .aspx-file within the application (to
dynamically compile the page)
This could be avoided by precompiling the .aspx pages using aspnet_compiler.exe
Send a query to the database to
initialize EntityFramework
Initialize application caches etc
So, my final question is whether there are better alternatives than my "Warmup.aspx" script? And is it a good approach or do you recommend some other method? I would really like some official method that would handle the above criteria.
Any and all suggestions are welcome, thanks!
Did you try this IIS Auto-Start feature described here ?
https://www.simple-talk.com/blogs/2013/03/05/speeding-up-your-application-with-the-iis-auto-start-feature/
You could have two instances of the site. When you need to deploy a new version, and therefore suffer a startup cycle, remove one instance out of load balancer rotation, deploy and start it, set it in and do the same for instance 2. A rolling deployment.
I haven't put up a web site/app yet, so please excuse my ignorance.
Eloquera looks like a great object database, but the embedded (in-process) mode is not meant to be used for a web app. I have to therefore somehow run the server exe on the server to use it.
When I use the server on my comp it first needs to be allowed through the firewall, as one would expect.
I am wondering if I could somehow run the server.exe in the same process as the web app and still have it be a tcp/ip server accepting multiple connections.
Or perhaps there are normal ways of dealing with this situation on typical "retail" web hosts?
In Short: I believe I am trying to embedd a tcp "server.exe" into an asp.net web application
Seems like the usual thing to do in this situation would be to get a dedicated server, or, more realistically in my case, a VPS (I did say I was learning!).This really pushes up the costs and hassle. No shared hosting that I can see offers Eloquera DB.
So, it seems that my only option would be a low-end VPS.
It's disappointing that I can't use embedded (desktop mode) eloquera in an asp.net web app, but I understand that this is to do with the nature of web apps.
My web site needs to initiate long-running workflows in which activities could pause for some large amount of time. Specifically, an activity will send the user an email containing a URL to follow and the workflow should not then continue until the user has visited that URL and performed an action there.
How can I host the workflow in such a way that my web site can interact with it as described? I am restricted to Windows 2003 Server and so AppFabric is not an available option for me.
All the text in the books is around either short-running workflows that exist in the lifetime of a web page or are using WF 3.0 which isn't what I want to use, so aren't relevant.
Many thanks,
Steve.
We have managed to do this & works well. You have to use the persistence to load/unload the workflow. However in retrospect, it would have been MUCH better to have hosted the workflow within a windows service & to communicate with it using wcf.
The persistence is quite buggy & some things just don't work well, like timed activities. It also makes your web app huge as you have to have all that workflow code in it.
WF 4.0 might be better, but I still think hosting the workflow in a separate service is the way to go.