We have a simple Visual Studio solution containing 2 projects:
A.) Simple ASP.Net website
B.) RESTful web service hosted in another ASP.Net application
We want to simply start the projects in Debug mode (F5) and have A consume data from B through Ajax. We do not have the possibility to configure IIS on all development machines (because some of them are on the client's side). The problem might be that JavaScript needs to be in the same domain as the URL it posts to.
Is there any way we can use Visual Studio 2010 Development Server to start both applications simultaneously in debug mode on the same port?
If this is not possible, what is the next best thing you can recommend?
We solved this problem by installing IIS on the development workstation.
In each Visual Studio project, on the Web property page, select Use Local IIS Web server.
Do not check Use IIS Express. The Project URLs will be set to http:localhost/<projectname> (note: in the same domain). You’ll be prompted to Create a Virtual Directory for each. Each will be assigned to the default IIS app pool. Open the Internet Information Services (IIS) Manager. Click Application Pools on the left pane. On the right pane add another integrated application pool. For one of the applications, open the Advanced Settings... In the properties view select the app pool you just created as the application pool. The applications should be debuggable in parallel because each Application Pool spawns a new operating system process to which a separate debugger can be attached.
Yo won't be able to host different apps on the same port within a Cassini instance, there are tools that might be useful but I would leave Cassini host them on different ports which is its regular behavior.
Options are (not tested):
UltiDev
Cassini Extesion
By the way, not sure if you know this, but to start both projects go to Set startup projects, there's an option on the Solution context menu.
Related
I have developed a ASP.Net MVC 4 application with Visual Web Developer Express 2010. It was successfully published/deployed to a remote server A (development server) using the Web Developer's built-in publishing tool and it works perfectly on it IIS 7.0 with the web deployment component.
Now I want to deploy it to another remote server B (production server). This one sits in an isolated environment and does not have Internet access! Even if server B is a replica of server A, its IIS 7.0 does not have the web deployment tool component installed. So the built-in publishing tool does not work for the web deployment option.
I then tried to publish it using the File System option. I copied the exported files to a new folder on IIS on server B. The folder was configured the same way as its counterpart on server A. I tried the URL on server B and it just gave me directory/files listing on the browser instead of the welcome page of the application.
Has anybody got the experience or tips to solve the issue? Thanks.
Cheers,
Alex
edit:
because it a MVC site, the default document doesn't apply. check the following steps:
IIS Extension Less URLs are enabled and allowed.
ASP.NET 4.0 is installed and registered. C:\Windows\Microsoft.NET\Framework\<version> and then aspnet_regiis -i (this will typically force IIS to use the MVC infrastructure instead of using the default document methodology)
Ensure App Pool is in 4.0 Integrated mode.
Ensue that the IIS Advanced Settings for the website are showing the right root folder path.
I have an asp.net mvc 4 web application , and I use the visual studio publish feature, to publish my web application to the localhost iis. But currently if I type the web application URL it will not work unless I open the VS and run the application. so can anyone adive how I can publish my web application on IIS so users can access the web application event if the VS is not running .
Thanks
Publishing a website to your Inetpub\wwwroot is not recommended on a standard computer, you will need to host your application on a server. Windows server has no limit on the amount of connections allowed to your webpage, whereas your computer can only handle a maximum of 10 connections.
if you want your solution to work outside of VS but still on your computer, you will have to create a virtual directory within IIS or within VS (then VS will do it in IIS for you).
Right click on your project, go to the "web" tab, there is an option there to host it within IIS and a button that creates the virtual directory for you.
Also check that you then have an application pool set up and running the correct version of .NET (depending on the framework you created the application in)
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
On my Windows XP desktop, I have a fairly simple ASP.NET targetting .net 4 in Visual Studio 2010. I can run it on my local host by ctrl + F5, it works all fine.
I have a Windows Server 2003, that I can access via mstsc, but also via Explorer. When I go to the publish section of my build properties, i see 4 publish methods :
Web Deploy, FTP, File System, FPSE
I have already installed IIS 6 successfully on the Windows Server, and given all authorizations for everything I could so far (to get things to work in the first place, will check on that later).
How should I proceed to publish to that remote machine ? Should I target a specific folder ? Do I need to setup things in IIS 6 for that site first ? Or will it all get settled from te properties I have in Visual Studio ?
Thank you guys,
J.
Personally I've always plumped for a manual deployment; that is I create the Web Site in IIS creating an appropriate AppPool and targeting the correct .NET version to utilise. From there simply copy (xcopy if you will) the appropriate files over, e.g. DLL and all supporting pages such as ASPX, CSS and associated images. In most situations where I have direct / RDP access this is what I run with.
That said, this can be automated from Visual Studio and this can be useful for those situations where you're maintaining an awful lot of sites on a regular basis. With IIS 6 and Visual Studio, this was achieved by installing FrontPage Extensions on the server then utilising the Publish option.
For VS2010 it seems this has been streamlined using the IIS Web Deploy module and configuring the Studio to publish in this manner that looks mildly quick...
HTH
I've never used the Web Deploy feature in 2010, so I can't really tell you about its merits or drawbacks. I've read that it works much better with IIS7 than IIS6. If you have direct access to the IIS root folder on the server (typically c:\inetpub\wwwroot) through a network share I would recommend doing the file system deployment. FPSE works as well if you have to publish to the server through a remote URL, but there are some security issues with FPSE that make enabling it on your web server a less than ideal choice.
Once the files have been deployed, all that should be left is to configure the website as an application inside of IIS.
Remote in to the web server and open IIS
Right-click Default Web Site and choose properties (if you've deployed to a subfolder in the root, then locate that folder and choose those properties instead
Switch to the Home Directory tab (Just 'Directory' for a subfolder)
Look for the Application Settings section and click the button that says Create
Optional: Select an app pool if you have created a custom one from the default
That should enable IIS to execute your .aspx files inside of your application. Once you've successfully configured the app for the first time, you can just keep publishing your app to the same location over and over without having to reconfigure it.
I have several web application projects in one solution.
When I start debugging one of those web applications I noticed that the ASP.NET Development Server starts for all web applications in my solution.
How can I determine to just one ASP.NET Development Server to be started?
Is this even possible?
I don't want to have my system tray filled with icons of all my web applications.
Thanks!
Duplicate: Why do VS2008 spawn one Cassini for each web-site/application when going into debug mode?
This might work for you, I have a similar issue since there are several web remoting projects in my solution. What I did was set up virtual directories for each in IIS then just right-click the each project and select properties. On the Web tab I then set the server to use when debugging to IIS. This causes Visual Studio to use the single instance of IIS instead of opening a dozen separate web development servers for each project. When you debug, attach to w3wp.exe processes.
As far as I am aware you can't stop this behaviour and is by design.
This because of the way that VS attaches its debugger to target processes. i.e. you couldn't have two instances of VS attaching to the same process. Hence multiple instances of the cassini web server, one for each VS session.