This is a more flexible solution, because you don't have to build a DLL beforehand (allowing you to call just about any VI), and is also easier when dealing with VI's that have complex types (arrays of clusters, etc).
The downside is that the ActiveX Server requires a full version of LabVIEW installed on the machine, and the performance is slightly below that of the DLL method. This is because the calls to the VIs are done out-of-process. You have to pay for the marshalling of data back and forth between ASP.NET's worker process and the LabVIEW executable.
So, just like everything else, it's a tradeoff. Generally I recommend the DLL approach unless you need
1. Ability to call arbitrary VIs
2. Call VIs with complex data types (clusters, waveforms, etc)
There are several examples that ship with LabVIEW on how to use the interface (see examples/comm), and .NET provides a very easy way to import ActiveX controls (look for LabVIEW <version> Type Library in the list of COM references inside VS.NET).
But, I told you all of that just so that I could tell you this...
If you try to create an instance of the LabVIEW ActiveX Server interface inside ASP.NET, by default you'll get an Access Denied error. This is because the user account that ASP.NET runs under (machinename/ASPNET) does not have permission to launch LabVIEW as a DCOM server. But have no fear, you can change that through a handy tool. This does increase the threat surface area of your website because a hacker could potentially launch LabVIEW and run VIs via your website.
Unfortunately, while the steps to get it running are simple, the associated security discussion is not. To keep the posts simple, I'll break it up into a few different ones.