I have been given a task where I have to write some code for an ASP.NET website that also uses a webservice.
The webservice works fine on the webserver, but when i run in debug mode in Visual Studio, I get an access not allowed when calling one of the methods (ip 127.0.0.1).
I need to run in debug mode to look at what the code does...
What to do from here ?
Do I need to do some changes in the host file.
Do I need to install IIS on my PC instead of using the VS local webserver (cassini)
Cassini web server does not allow remote connections. You could use Fiddler to forward traffic on localhost to another port on the same machine for some given requests.
By far the easiest solution is to install IIS on your local machine and run it from there.
Cassini is fine for development and getting something running up very quickl.
But never us it to test things that will go into production on a "real" IIS.
Yes, Microsoft says its completely the same, but running on your localmachine also IIS gives you exactly the same environment as you will have on any live hosting environment.
Sure, its a little bit more work, but developing this way reduces errors and artefacts which may steal you some time.
Related
I was witching and had my first few ASP.NET Razor Pages projects, debugging locally, publishing after, and everything went fine.
But now I temporarily took over a project from somebody with health issues, can not ask him things at the moment, maybe next month.
The projects run on two physical servers, five IIS-applications running, like API, Video-Handling, IndentityServer and a "WEB" for the user-interface. Endpoints defined in the "appsettings", I get it.
I changed some minor things at the User-Interface (WEB-Application), published it directly on the server and everything went fine. Pfff..
But... now I want to make some bigger changes and test them locally before publishing, but still using other unchanged IIS servers on the two servers, which do the "heavy-lifting". So I put some breakpoints like always, run "Debug" on Rider, express IIS server starts successfully, but I noticed the application redirects to the project on the remote server and then of course does not meet my breakpoints anymore, it is just running the old version on the server. Now I am missing something..., looked at several configuration files, how can I configure it, when it starts with the local IIS express server instead of the remote server? I want to stay on the local IIS express server, since I want to test the changes of course.
Hope I explained my issue well enough, did not know how to tell exactly.
Greetings to all!
I'm using the built in web server in Visual Studio to test some pags but I wanted to be able to connect to it from other machines to test out browsers on different platforms. I was wondering if it was possible to configure that server to listen to an external interface or if I have to throw this over to IIS. I've turned off the windows firewall so that shouldn't be an issue.
Not with the default ASP.NET Development Web Server. You could probably use Cassini if you don't want to use IIS.
I would use SVN and setup a test server to automatically have the SVN updated on the tested server.
What I have done in the past is setup a SVN repository and add my sites into it. And on the test server setup a running copy of the repository and have a scheduled task automatically update it every 5mins. This works great since I dont have to worry about ftping or any thing. Works great since I use VisualSVN and Commenting my changes is easy.
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.
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.
Im testing an ASP.NEt site. When I execute it, it starts the ASP.NET Development Server and opens up a page.
Now I want to test it in the intranet I have.
Can I use this server or I need to configure IIS in this machine?
Do I need to configure something for it to work?
I've changed the localhost to the correct IP and I opened up the firewall.
Thanks
Yes you can! And you don't need IIS
Just use a simple Java TCP tunnel. Download this Java app & just tunnel the traffic back.
http://jcbserver.uwaterloo.ca/cs436/software/tgui/tcpTunnelGUI.shtml
In command prompt, you'd then run the java app like this... Let's assume you want external access on port 80 and your standard debug environment runs on port 1088...
java -jar tunnel.jar 80 localhost 1088
(Also answered here: Accessing asp. net development server external to VM)
No, you can't. It's set up so it only works on localhost, and I couldn't find any workarounds to make it work.
But, here's what I've been doing - I created the website on a specific port in IIS and opened that port up so it's visible on the network. I pointed that IIS website to my website's root folder (the one with web.config in it). Then I continued to use the ASP.NET Development server on that local machine while developing - both IIS and the ASP.NET Development Server can access the files at the same time (unless you're doing something wacky).
Let me know if there's a challenge with running IIS on your machine and I'll update my answer.
I realize this isn't a direct answer to your question, but an alternative to debugging using the ASP development server is to attach to the IIS process: How do I attach the debugger to IIS instead of ASP.NET Development Server?
Nope, stupidly (IMHO) there's no way to get the default ASP.net development server to serve pages to IPs other than localhost. What I did was to use UltiDev Cassini which is very quick to set up and is basically a version of the ASP.net development server compiled by UltiDev, and it will serve pages to any IP address.
Just for those who don't want/cant set up IIS for whatever reason...
Use fiddler or similar on your host - set your browser on the client VM to use the proxy then just use localhost:dev_port as usual on the client.
All requests from the client goto the proxy on your dev machine which routes to localhost on the dev machine and the ASP.net dev server thinks the request is from your dev machine!
You can recompile Cassini to get it to work - there's a fairly easy to remove check for localhost in there. Or, I'm pretty sure Ultidev's Cassini doesn't have this restriction. Both of these are easier to setup than IIS.
But, yeah, the builtin WebDev.WebServer doesn't work....Hmm, unless you run something like AnalogX's Proxy on your dev box and point it to the WebDev port. That should work (though I haven't tried it, it should take < 2 mins to setup).
You can use Cassini to expose your web apps externally. You just need to proxy the connection. I wrote a simple program to do this that you can run in another VS instance. Just change the port to match the port Cassini is using.
https://gist.github.com/945649
You can do port redirection using SOAP Toolkit 3.0
Once installed, go to My Programs > Microsoft Soap Toolkit 3 > Trace Utility
Once Trace Utility opened, go to File > New > Formatted Trace
In the dialog insert your ASP .NET Development Server port in Forward To Destination Port field.
It's only a workaround for testing purposes
I believe the built in ASP.NET server only works on localhost. You'll have to use IIS.
Compile all you website in Debug mode, then create the website and publish it in IIS (make sure you can view it from other machine). Then attach the VS2010 Debugger to the process with the AppPool of your website (the process is called w3wp.exe when IIS>v5 and aspnet_wp.exe when IIS<5).
If you make some changes, just replace the package contents on the physical path of the website, and there you go again.