I've created a small application for internal use with asp.net web forms. I don't have a server to deploy it, but would like others in the office to have intranet access. Just a handful of people will have access (2-6). It is not a public-facing application.
I saw the following instructions on this site to deploy an asp.net mvc application to a desktop computer-using IIS 7.
1.Install IIS from the standard windows components.
2.Put your code in the root directory of the default created web site.
3.Be sure the firewall is allowed the 80th port.
Would the procedure be the same for my asp.net web forms application--or is there something inherently different (between web forms and mvc) that makes this impossible?
Thank you for your help!
The instructions would stay more or less the same. The process can be a little more complicated than what you've described in the steps above, but it's a good starting point.
In addition to making sure port 80 is open, you'll probably need to assign an IP address for the site too. See the illustration below:
It should work exactly the same.
One thing you'll need to check is that the ASP.NET framework version the default web site created by IIS7 is using is the same as the version your code was created in. To do this; goto IIS -> Application Pools -> DefaultAppPool then check the .Net Framework version.
Bar that; as long as the physical path of the Site inside IIS is pointing to the correct folder it will work the same as MVC would
Related
I am trying to host an ASP.NET Web API 2 project on IIS 10, and I keep getting a page saying Service Endpoint not found.
The project I am using for testing is the sample ProductsApp project here Getting Started with ASP.NET Web API 2. If I run the project in debug, then the page shows up as expected while it is being hosted through VS2012 IIS express at localhost:54170
I am then publishing that project to file using VS2012.
After publishing to file, then I made a new site on IIS 10 at localhost:8080 and point the physical path to the folder that I published the ProductsApp project to.
At this point if I go to browse the site it comes up with a page that all it says is Service Endpoint not found.
I've changed my DefaultAppPool Identity to LocalSystem, so I don't think it's a permissions issue.
How do I get the site to show up like it does when I'm debugging from VS2012, but from IIS 10?
I wasted so much time yesterday trying to figure this out, but this morning with a little fiddling I found my answer which I'm surprised I wasn't able to find anywhere else I looked.
To fix my problem this is all I had to do.
Instead of hosting the ASP.NET content as its own site I just needed to add an application to my default web site with the physical path pointing to the folder that was published from VS2012.
This is obviously my first time using ASP.NET, so I didn't have any of the ASP.NET features installed in IIS. I went to Turn Windows features on or off -> Internet Information Services -> World Wide Web Services -> Application Development Features, then selected all of the ASP folders (ASP, ASP.NET 3.5, ASP.NET 4.6). Edit: Looking back at this, all that was required was turning on the feature ASP.NET 4.6. At the time I didn't know what I was looking for, so I tried to nuke the problem by installing everything with "ASP" in the name.
The DefaultAppPool Identity didn't need to change to LocalSystem, so I changed it back to ApplicationPoolIdentity.
Now I have the ASP.NET site up and running on my localhost.
I have a web project which works fine on my local development machine.
I copied the project to our UAT server, setup a virtual directory pointing to the project and configured it to run on .NET Framework 4.0. I even added the Default.aspx page to the Documents tab. I configured Directory Security to use Windows Authentication.
When i try to access any web page within this application, IIS responds with a blank page. I looked through the event logs and don't see any errors anywhere.
Can someone please help me understand what's going on and how to remedy this?
Thanks in advance!
If you're just seeing a white page with no errors in the event log, it sounds like it could be a problem with the application rather than the hosting environment.
However, there are a few things you could try to doing to troubleshoot this.
Check folder permissions. Try allowing "Everyone" access on your webroot folder and see if that makes any difference.
Confirm that the IIS path is set up correctly but putting a text file in your webroot folder, and then browsing to it and verifying that it's contents are displayed.
Create a basic test.aspx page without any script, just a "Hello World" bit of text, and try browsing to it. Confirm that it displays the correct content.
Edit web.config and turn off custom errors
Try re-registering the ASP.NET extensions with IIS using aspnet_iis (details here)
Hopefully, one of these tests will be able to give you some kind of detailed error message or more insight into the cause of the problem.
For IIS 6.0 on Windows Server 2003, after the install of .NET Framework 4.0, the process of creating Web Sites or Virtual Directories that run under .NET Framework 4.0 is as follows:
Create a new application pool.
Applications running under different
frameworks can't be hosted in the
same application pool, i.e. create
an application pool perf framework.
Next, if you are creating a local
intranet site or virtual directory,
ensure that you don't have "dots" in
the application name. Browsers
confuse the dots to be external web
sites, forcing them to run under
internet zone as appose to the
intranet zone.
Once you create your web site or
virtual directory, make sure that it
runs under an application pool
dedicated for .NET 4.0 applications.
Ensure that when creating your
website or virtual directory, you
click on the ASP.NET tab and select
version 4.0 from the drop down.
Then you may configure as per
normal, with any other additional
settings you may require.
Hope this helps someone experiencing similar issues. Took a while to figure out.
I am trying to deploy the Bugtracker.NET tool (http://ifdefined.com/bugtrackernet.html), which is a normal ASP.NET 2.0 application, into the default web site of an IIS which already has Sharepoint installed in it. The OS is Windows Server 2008 R2, IIS 7.5 and Sharepoint Services 3.0.
The question is that when I execute the application, I get a NullReferenceException because HttpContext.Current.Session is null, and I think that this could be due to a problem with the configuration of the web site, as the application runs perfect in web sites with no Sharepoint installed.
I already know that Sharepoint customizes the web site with handles, modules and so on, that all applications in the web site inherit, modifying their behavior. I have already given to the ASP.NET application Full trust level, enabled Anonymous authentication and InProc session state, but I am still getting that HttpContext.Current.Session is null. Even changing the app pool from Wss3AppPool to DefaultAppPool does not succeed.
Maybe someone could tell me which settings do I need to tweak in the web site in order to avoid this exception.
Many thanks in advance.
José Antonio Arroba
You need to look into Managed Paths and excluding the path to your bugtrackernet app.
However why do you HAVE to use the default web application?
Why not keep your life simple and setup a new IIS web application on a separate host header or subdomain and host your app there.
e.g.
http://bugtracker.yourdomain/
or just
http://bugtracker/
I'm developing a web site in a high-security environment. For example, we use CAC cards to authenticate users over SSL.
The site is a mix of VB.NET and C# on .NET 3.5 with some AJAX. The AJAX parts are now calling web services for things like Cascading Drop Down Lists.
We've been running VS2008 configured on our local PCs to use IIS instead of the default server (Cassini). However, some security policies were rolled out to the desktops over the weekend and, suddenly, we're not allowed to run IIS on our PCs anymore.
I already have some of our IT people trying to appeal for waivers for developers. In the meantime, I need to find a way to keep developing.
If I turn off the SSL requirement to the 'secure' part of the application (locally, my PC only) I can serve up some of the pages (using Cassini) when I hit "F5", but pages with web services just bring up "server application unavailable".
I need to be able to add some more functions into the existing web services, among other things, so the ability to single-step through the code is still a necessity.
I'm sure someone who is limited to using Cassini has found a way to Build/Debug pages in VS2008 when webservices are involved.
Thanks in advance.
EDIT: As it turns out, some links had "HTTPS://" hard-coded in them (I inherited these). Changing the link to "~\folder\page.aspx" allowed Cassini to properly serve things up.
Note that using Cassini is the default for VS2k8, even for Web Services. Try starting a new HelloWorld web service project and confirm if you can debug it.
OK So that worked. Then change the debugging options of your real project back to using Cassini rather than IIS. I wouldn't move the project (although backing it up might not be a bad idea) as you might be able to get IIS working again.
EDIT: So your actual problem wasn't to do with web services, just hard-coded URLs. (We have similar problem where much of the site works where ever the root of the website is, but some places, such as "main menu" links, expect the root to be the root of the webserver.)
You proabbly need to contact your IT department and have them open up something on the network so you can call the services - a port on a firewall, for instance.
Currently our dev team set up all the websites they're working on in IIS on their local machine. We're thinking of switching to using the built in ASP.NET development server instead.
Is this a good idea? What are the pros / cons of using the ASP.NET dev Server? Are there any gotchas we should be aware of?
Thanks.
NB: Running on Win XP / IIS 5 / VS2005
Edit:
Didn't realise it was called Cassini.. More answers for Cassini v IIS here.
There is nothing that the ASP.NET Dev WebService can do that IIS can't (You can set breakpoints etc, just attach the VS debugger to the ASP.NET runtime).
However, the ASP.NET Dev WebService does not represent a true production environment, and as such you can get caught by gotchas that you wouldn't expect when you deploy to production.
Because of that, I mandate that all development is done using IIS on a local machine. It doesn't take much work to configure a site in IIS.
It's a very good idea. Here are some reasons for:
You no longer need admin access to your machine for web development (it can still be helpful).
It's much easier to test a quick change and continue work, and faster iteration cycles are good.
It can simplify setup and deployment of your development environments.
The XP version of IIS has limitation that are not present in the Server version that Cassini side-steps.
The only argument I know against is that there are a couple very rare edge cases where the Cassini built-in server doesn't exactly mimic IIS because you're using odd port numbers. I doubt you'll ever run into them, and using Cassini as the primary dev environment does not preclude developers from also having access to IIS on the machine. In fact, my preferred setup is Cassini first for most small work, then deploy to my local IIS for more in-depth testing before moving code back to the shared source repository.
[Edit]
Forgot about url re-writing. You do need IIS for that. And an example of a limitation of the built-in XP IIS is that you are limited to one site in XP (can have multiple applications, but that's a different thing).
I had to switch (back) to IIS for one project, because I needed to set some virtual directories which is not possible on the ASP.NET Development Web Server.
As I stated here: https://stackoverflow.com/questions/103785/what-are-the-disadvantages-of-using-cassini-instead-of-iis your developers need to be aware that Cassini runs as the local user, which is typically an admin account for developers. The development will be able to access any file or resource that their account can, which is quite different from what they will see on an IIS 6 server.
The other thing that's a pretty big gotcha is debugging web services is much easier using IIS and vdirs rather than separate Cassini instances.
I know at one point I had an issue with Authentication not working as expected on Cassini (built in development server)
Also, if you need to test things like ISAPI plugins (a re-writer for example) I'm not sure how that's done on Cassini.
The constantly changing port is also rather disconcerting to me. Also, for each web project in your solution it fires up another instance of a Casini server, and each one takes anywhere from 20 to 50 MB of memory.
I use IIS all the time, it's pretty easy to setup, and you guys are already doing that...
I've used both methods and I prefer having IIS locally vs. using the built-in server. At very least you're more consistent with the final deployment setup.
Also, when using IIS 5.1, be sure to get JetStat IIS Admin, it adds functionality that is disabled out of the box on IIS 5, such as being able to setup multiple sites.
I have run into the following limitations with the asp.net dev server:
does not support virtual dirs. If you need them in your app, IIS seems to be your only choice
Classic asp pages dont run in dev server. So if you have a mixed web app (like I have at my client right now), IIS seems to be the solution
If you need an admin UI to configure settings, IIS works better
Of course IIS requires that you be a local admin.
Another distinction I noticed is that Cassini runs as a 32-bit process and you have no control over it, whereas you can control the application pool of your IIS app to disallow 32-bit (assuming your IIS is running on a 64-bit server). This becomes especially important if your web application is going to call APIs in 64-bit processes such as SharePoint Foundation/Server 2010. When you debug your web app with Cassini as your debug server, you'll get "The Web application at url could not be found. Verify that you have typed the URL correctly" type errors when instantiating objects. If you debug using IIS with the app running in an app pool that runs as 64-bit with an identity that allows access to sharepoint database then you'll be able to debug properly.
In VS12 the development server is way slow, takes a few seconds to download a 2kbyte file. This did not happen in vs10. When you have a bunch of jquery files and css this is a real problem. Also every page requeries all the css/js files. Very very slow regression testing.
The main issue I've run into with the dev server is SerializationExceptions with custom security principals stored on the thread context. Details here.