Can WampServer be used successfully in production? - networking

Can WampServer be used successfully in production? Is this a bad idea?
So everyone knows, and I don't see how this mattered, we've paid for a windows dedicated box and we have existing IIS apps. We just wanted to use a PHP based CMS which installs easier on apache (since it has some dependencies). So, as the title indicated, windows, apache, php, and mysql are requirements.
Additionally, I'm talking specifically of the WampServer flavor of WAMP.


If you're not going onto the internet, there isn't any reason really not to. Of course you'd have to look at all the normal caveats - backups etc.
Instead of using an already made one, why not try to do your own? It would be a good learning experience and really they aren't that hard to get working together.


WAMP is approriate for production of an Intranet. We developed a solution with FLEX (front END) /PHP/MYSQL (BACKEND) and it's been working very well for a year now. You just have to secure the Server on which WAMP runs. WAMP is just a tool for configuring APACHE/PHP/MYSQL on a Windows plateform with ease.


WampServer themselves says they are not appropriate for production, only for development. Security issues, load balancing, etc., are definitely part of it... plus, deploying Apache on Windows is just a nightmare.
Use LAMP. Alternatively, use IIS... if you're going to deploy a Windows production server (don't), use IIS.


LAMP is more stable, but i have wamp running intranet-sites succesfully in two organisations with over a 1000 users.


I don't see why not, but why use Apache on Windows when you can quite easily install PHP on IIS?


I love how the only guy who answered the actual question by paying attention to the fact that the OP was asking about the all in one product that is WampServer has a -1 rating. To reiterate what he said though, yes it would be a bad idea to use it in a production environment.


I'm using WAMP over Windows Server 2003 as a production server for an Intranet. accesing MySQL and SQL Server toghether.
We are not too many users, but I had no problem so far.
Easy configuration, easy maintenance, posibility to autenticate domain users in Apache...
Perhaps with heavy load environments it's not so good, but for me is the perfect sollution by now.


YES, it can be used in production under condition that you install the secure WAMP distro. And yes it can run on Internet and not just intranet.
Here is a link to a secure WAMP for production where you can customize the security level and other settings to suit production environment.
http://securewamp.org/en/
Windows and WAMP can be successfully used in production even on high traffic websites however you will need to make changes and switch from mod_php to FCGID.


Why not just use LAMP? PHP code is portable. I used WAMP for development, LAMP for production.
WAMP would probably work for production, but why not just use LAMP?

Related

Different between WAMP and web hosting?

I have planned to learn WordPress. I just want to know what will be core difference between functionality and features if I install it on WAMP that is local host and a web server?
My preference was WAMP but I am not yet sure.

When doing web development on your local machine using a localhost, there are a few things you need to be aware of.
You need to ensure that it is same as the versions of the products on your actual web server or close to it (MySql, Apache, Php, etc.)
You need to be aware of the urls you use compared to the urls when deployed to the server (in Wordpress, you need to edit the main web urls in your mysql dump file before uploading to your webhosting)
WAMP actually is easy to configure, other alternative is XAMPP for local development
Wordpress updates a lot and usually so is there requirements, so in order for wordpress functions to work properly, your local server must be updated to their requirements or at least close to it

asp.net MVC 5 hosting setup

Note: because there is no windows hosting that satisfies me at the moment, I'm developing my application in PHP and host them on a linux VPS.
Since Windows Server 2016 supports Docker and you are able to create .net 4.5 images, I thought why not review my applications and hosting plans.
Because I'm not a fan of hosting websites directly on a VPS with IIS (setup and configuration seems clumsy), I thought this "infrastructure" seems ideal for me.
A Windows 2016 VPS
A Linux based VPS
For each asp.net application, create a docker image based on microsoft/iis. This means that for the application, there is nothing left to be configured, right? This application will run on the Windows 2016 server.
On the Linux VPS, I will have nginx configured to have all the configuration for SSL certificates and optimizations. Nginx will have proxies that point to the Windows 2016 VPS on specific ports for the different applications.
I think this architecture has scaling possibilities, less configuration on the Windows VPS, more room for improvement? It should even be possible to do this with Ansible if I'm not wrong.
I only need hosting, nothing related to email, ftp, ... That's why I'm not using shared and/or cloud hosting.
Does this architecture seem fine?
Am I missing something?
Would you still just use a Windows VPS for hosting asp.net applications, even if this architecture is possible?
Does this all seem possible with Ansible? I only have basic experience with it.

I don't see anything wrong in your proposal. Remember you can use ansible inside the Linux image's Dockerfile. Maybe you can find that it is an overkill but it should work.
Probably you will find some problems linking your Linux / Windows containers. But I don't see anything short stopping.
Go ahead and post your results. Also if you encounter some walls just ask here and we will try to help.
Regards

because there is no windows hosting that satisfies me at the moment, I'm developing my application in PHP and host them on a linux VPS.
Would you mind telling us a bit about your requirement of Windows Hosting?
For each asp.net http://asp.net/ application, create a docker image based on microsoft/iis. This means that for the application, there is nothing left to be configured, right?
Once fully functional pre-configured image is prepared, you don't have to perform any other changes to your main image. The main image is only modified when you want to update any application in the image or looking to make any changes or update Windows OS.
Does this architecture seem fine?
NGINX reverse proxy works with IIS backend, so, this proposed architecture is achievable. Initial setup of connecting Linux VPS NGINX web server to individual Windows docker image is slightly complex. If you are successful doing that, the next challenge will be adding subsequent dockers to Windows Hyper-V. Here, I don't see actual purpose of using Docker images to host ASP.Net http://asp.net/ applications, when you can easily deploy pre-installed VMs through Windows HyperVisor.
As far as Ansible is concerned, I don't have much idea about this product, but as seen on their website Ansible can automate the dockers.

As an ASP.NET Web Developer using Visual Studio, should I have IIS installed?

We do ASP.NET Development using Visual Studio.
A discussion point we've just had is whether or not our developers should have IIS installed.
With the ASP.NET Development Server you can run your web apps without IIS. Once you're happy with everything you can then deploy it to a test server running IIS and then onto Live.
In my opinion, all developers should also have IIS installed on their own machines as that will eventually be the end platform for the application.
The arguments are basically if the developer should have as close to "live" an environment as possible, or if the developer should only have the tools they require and not be cluttered with other things.
None of this is missions critical and I'm sure everyone will have a differing opinion. I'm just interested to hear some of them!
Robin

I'm going to say unequivocally yes. IIS and Cassini are not the same and not exposing your code to production conditions can cause you problems. Better to get yourself in the habit as early as possible.
(obviously you can replace "IIS" with "Apache" or whatever your webserver tech is)

I would say that you don't need to have IIS installed, but that you should test on IIS at some point.
The Development Web Server has two "issues":
it only works for local requests
ALL requests are passed through ASP.net
Especially the second point can really open ways to shoot you in the foot. "Why can people access SuperSecretPicture.jpg? I have a Handler in my Web.config that blocks that!".
But if you know about those limitations, then I find that the Development Web Server is better to start with since you can first focus on your code and then about your environment, but YMMV.

The bottom line is if your application is served by IIS, you should be testing on IIS. If that means IIS on your local machine or a dev server is up to you.

What harm can it do having it installed? At least if you have it installed you can choose to use it or not. The day you need to debug a webservice call from an externally hosted application you don't want to be messing around installing it.

Depends - are you running server versions of windows for you dev boxes?
Because, e.g. the XP version of IIS is different from 2000/2003 server, so you'll get a different experience. Similarly, if you develop on Vista but plan to deploy on 2003, it won't be a "complete" experience.

We have IIS installed on our local machines at our work for development purposes. We need to test the web applications against IIS, but neither do we want to release it to our live server, or to our test server as that requires a lot of work. Instead, we just host it locally and everytime we modify a file through Visual Studio we can then instantly see the changes without having to go through a file copying process.
I don't think it's a bad thing at all, as long as everything's secure you'll be fine.

Ideally your test server should mirror your production server. That should go without saying. In my opinion, your dev environment should come as close as possible, while fulfilling your needs first (I prefer to keep the dev environment as self-sustaining as possible, in case I am disconnected from the network).
I have no problem using the dev server for development, and IIS (locally or remote, as the case may be) for testing - but it depends on the project requirements too. I prefer to host web services on the local IIS server, for example. YMMV.

We develop on laptops using virtual machines. This way, if the virtual OS crashes (or the host OS, for that matter) you just copy your vpc back over from the network (where we have backups) and you are good to go. also, it makes it WAY easier to run a "standard" development platform wich is as close to production as possible.
For us, we HAVE to have IIS installed, as we are developing Sharepoint '07 webparts.

What are the (dis)advantages of using Cassini instead of IIS?

I've found that on some occasions I can edit the source while debugging. Are there any other advantages of using the Visual Studio built-in webserver instead of a virtual directory in IIS?
I'm using Windows XP on my development environment, and a local instance of IIS 5. I work on several projects, so I use multiple virtual directories to manage all the different sites.
Are there any disadvantages?

The built-in web server for Visual Studio is called Cassini and here are a few of its limitations...
It can host only one ASP.NET
application per port.
It does not support HTTPS.
It does not support authentication.
It responds only to localhost
requests.
It is slow startup compared to IIS

All the previous responses are great answers - here's one gottcha with Cassini that might require IIS on the destkop.
Cassini runs in the context of the developer, not as the IIS user (IUSR_, IWAM, or in WinXP x64, the w3wp process). This can be a bit painful if you've got a web site that is accessing external files or creating temp files. It is most evident when your developer is running as an Admin of their desktop.
When you move to the server IIS, something that you would have had access to in Cassini doesn't work the same. CACLing with the IIS_WPG usually is all it takes to fix, but if your developer is not thinking about this, they will quickly get quite frustrated with their deploy.

Cassini does not support virtual directories.

It looks like a third option is coming soon:
IIS Express.

Another disadvantage I've run into is on a Forms authenticated website using custom IPrincipal/IIdentity. Cassini will switch the AppDomains without warning (or notice).
Check this blog post for more.The headache on this made me drop Cassini and stick with IIS.

The Visual Studio web server is less forgiving about // in the path.
It will refuse to serve a link like
http://localhost:52632/main//images/logo.jpg where IIS will do.
That's pretty obscure, but it means we have a lot of fixing to do to get rid of all the // occurrences.

The built-in server works well for larger corporations that don't want to give developers any administrator access on their own machines to configure IIS.

There's a bug in the way the built-in server handles HTTPModules - there is a workaround, but I hate having to put in code that'll never be needed in production.

You need to have Visual Studio running to use it (under normal circumstances)
It only responds to localhost, so you can't give the link http://simon-laptop:37473/app1 to a friend to view your site over the network
Big disadvantage: it's harder to get fiddler working, because localhost traffic isn't sent through the proxy.
Using http://ipv4.fiddler:37473 is the best way to get Fiddler working with it.

You cant use virtual directories :(

Cassini also does not support ASP Classic pages. This is only an issue for legacy projects where old ASP Classic pages still exist (like our web application at work).

The built-in server means the developer doesn't have to know how to set up IIS to test their site.
You could argue this is a disadvantage, and that a Windows developer should know at least that much IIS. Or you could argue that a developer who isn't a system administrator shouldn't be messing around with the web server at all.

If you 'web reference' the URL for web services that are on the built-in webserver, the port might change. Unless you have set a "Specific port" mentioned in menu Project → Properties options page.
This is something I've gotten used to now. I always set a specific port. Now when sometimes the webserver crashes (I've had that happen), I simply change the port number, and all is well. I reckon restarting will also fix this.

If you do hobby work at home using XP Home, you can't install IIS locally.

When you use IIS in Vista or Windows 7 with UAC enabled, you must run Visual Studio with administrative rights. If you do this, you can't drag an drop from your shell to Visual Studio (even if you run an instance of explorer.exe as administrator).
For this reason I use Cassini for most projects.

FYI, Windows XP 64-bit comes with IIS 6.

This is an old thread started 2 years ago. I just stumbled upon UtilDev Cassini while googling. Looks promising to me. At least it has the ability to run multiple sites simultaneously. That feature is really useful for me, because I work on 2 different sites and have to continuously switch between them using IIS.

Here's a reason for a third way: although UWS Pro is probably closer to IIS than Cassini (although inspired by Cassini and is from the vendor of the UltiDev Cassini fork), its main purpose is to be redistributable along with ASP.NET applications.

Cassini is meant to be a lightweight test webserver. The idea is that a developer does not need to have IIS installed and configured to test his/her application.
Use IIS if you are familiar with it and you have it set up and your box can handle it. Cassini is not meant to be a replacement.

I often take the best of both worlds and create an application in IIS, and use the built-in web server for more efficient debugging.

The built-in server isn't as configurable, and it runs on an odd port, so if you're counting on specific behavior it can be troublesome.

Install IISAdmin, and you can setup separate sites in IIS 5, instead of using virtual directories.

The built-in webserver is a little less robust than IIS, but requires no setup so it is just a tradeoff.
You may not always want your development projects exposed on your IIS server (even your local IIS server) so the built-in server is good for that.
However, if your application is going to access resources outside of the norm for a web app then you may want to debug frequently in IIS so that your app will run with restricted permissions and you can see where the pain points will be.

One difference I've found is that the development server handles uploading files differently than IIS does. You can't trap the error if the file being uploaded is bigger than your Max_File_Size setting. The page just dies and returns a 500.

Another dis-advantage is that it sends every request through the gloabal asax file which includes all requests for images and stylesheets. This means if you have code in there which does things with the file names, such as a look up, then the auxillary files willget processed too.

Also via IIS, you don't have to worry about automatically remembering and setting a stupid port number in your localhost url. That's something funky directly relied upon with Cassini...big pain in the ass. Who wants to remember some abritrary port number. Just run the damn site in IIS..plain and simple.

We've also seen some issues with Visual Studio built-in server regarding some third-party controls which put their scripts in the \aspnet_client folder.
Since the folder isn't there when you're not running under IIS, the controls didn't work. It seems a lot simpler to always work with IIS and avoid strange problems.

If your project resides in the IIS directory you can still edit code. It just depends if it has been published or not.
You will run into so many issues on the Cassini vs. IIS when you are debugging certain permission based scenarios, like Kerberos and NTLM authentication as well as issues like server compression, etc. All in all, the Cassini is still okay to develop with, but make sure you do extensive testing when publishing to IIS.

xampp with asp (not aspx)

is it possible to use xampp (apache 2) with asp (it works with aspx, but i want to use "normal" asp). With kind regard, JSMB

Thanks, I "solved" this with using quickwebserver. http://www.pablosoftwaresolutions.com/
Now I can use classic ASP with XP home edition (and of course it's not free :-( ;-))

From a slightly dated page:
Do Microsoft Activer Server Pages (ASP) work with XAMPP?
No! And Perl:ASP in the Perl Add-on is not the same! Unfortunately no free implementation for the Apache is available.
Edit: However it may be possible to run mod_proxy on Apache. mod_proxy is a reverse proxy which should allow you to transparently relay requests to IIS. I haven't done this with either Apache or IIS, so I can't advise you here.

You mean "Classic ASP"? As far as I know, ASP for windows is only possible with IIS. For linux (apache) it was possible with chillisoft and the like, but it's probably not free, nor available anymore...

Resources